The Clock Only Starts at Detection

Incident response (IR) is the organized handling of a security event — determining what happened, containing it, eradicating the cause, restoring service, and learning. It is the discipline you hope never to use and the one that decides the bill: the difference between a quiet two-hour containment and a three-week extortion + media crisis is almost always the quality of the plan that existed before the click, not the skill of whoever shows up after.

The Six-Phase Lifecycle

The standard IR lifecycle (NIST SP 800-61's PHB — Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned): 1. Preparation: playbooks written, roles named, tools ready, backups tested (a backup nobody has restored is a rumor). This phase decides how the other five go. 2. Identification: an alert, a user report, an anomaly, or a threat-intel feed triggers the investigation; triage answers "real incident or false alarm?" quickly. 3. Containment: stop the bleeding now, stabilize later — disconnect the host, revoke the token, sinkhole the domain. Containment trades full forensics for speed; preserve what you can while you act. 4. Eradication: remove the attacker's foothold — kill malware, revoke all compromised credentials, patch the entry, reset the environment the attacker touched. 5. Recovery: restore from known-good backups, verify integrity (hashing lesson), re-enable services in order of importance, and watch like a hawk. 6. Lessons Learned: an honest debrief — timeline, what worked, what failed — feeding playbook updates. A review meeting that closes with "we should have detected earlier" and changes is the loop closing.

The Forensics Discipline

Forensics is the evidence half of IR: capturing and preserving what happened so you can reconstruct the attacker's actions and, if it goes to court, prove them. The rules are brutal and non-negotiable. Preserve the chain of custody (who touched that disk image, when, for what reason); acquire evidence with write-blockers and cryptographically hash everything at acquisition so integrity is provable; work from copies, never the live system; and preserve volatile data first (memory, running processes, open connections) because it evaporates with a reboot. Today's IR is cloud-native — cloud access logs, Kubernetes audit logs, and object-store version histories are often the only "crime scene" left — which is why immutability (something the logs cannot be edited after the fact) is a logging requirement (the logging/monitoring discipline deserves its own pillar; the security-headers lesson and cloud lesson cover the audit-export half).

Deciding and Communicating

IR lives on decisions made under fire: triage (is it worth waking the team?), escalation (when do lawyers and PR enter?), and legal/compliance contacts (when does the breach notification clock start — many jurisdictions require disclosure within hours-to-days of confirmation) all need a pre-agreed owner. The analyst's cardinal rule: preserve evidence through every containment action, confirm with data rather than suspicion, and let the written timeline — what was seen, by whom, at what time — be the spine of the entire incident. An org that runs the lifecycle before the crisis has a culture; an org that runs it only during the crisis has a scramble.