NIST SP 800-61 is one of those documents that almost everyone has read and almost everyone misapplies. The four-phase incident response lifecycle — Preparation, Detection and Analysis, Containment/Eradication/Recovery, Post-Incident Activity — is right on the model. The issue is that most programmes treat the phases as discrete sequential boxes, when in reality they overlap, iterate, and feed back into each other in ways that determine whether an incident response actually contains damage or just records it.
Preparation Is Most of the Work
The single highest-leverage phase is preparation, and it is also the one most programmes underinvest in. Preparation is what turns a 2am incident from chaos into a familiar process. It includes documented runbooks for common incident types, named on-call rotations with clear escalation paths, pre-authorised containment actions (the team can isolate a host without paging legal first), tooling that exists and works, and tabletop exercises that have actually surfaced gaps. None of this is glamorous. All of it determines outcomes.
Detection Without Analysis Is Just Noise
Detection generates alerts. Analysis turns alerts into incidents. The phase NIST calls "Detection and Analysis" tends to get reduced to detection alone — which means the SOC ends up with thousands of alerts a day and no consistent process for triaging which represent real incidents. The teams that handle this well invest heavily in alert enrichment (every alert arrives with relevant context already attached), severity classification (a defined process for assigning priority, not analyst judgement alone), and a clear handoff point between SOC and IR.
Containment Decisions Are Business Decisions
Containment is where IR programmes most often run into organisational friction. The technical containment options are usually clear within minutes of identifying the incident. The decision about whether to apply them — which interrupts business operations — gets stuck waiting for people who are not in the response. Pre-authorised containment is the answer: documented criteria under which the IR team can act without further approval, ratified in advance by the relevant business stakeholders.
A scenario that comes up repeatedly: ransomware is detected on a finance workstation at 6pm. The IR runbook says isolate. The IR team isolates. The CFO has a board meeting in 90 minutes and needs a file from that machine. If pre-authorisation was not done, the next 30 minutes are spent debating whether to undo the containment. The right time to have that debate is during preparation, not during the incident.
Eradication and Recovery Are Distinct
Eradication removes the threat (the malware, the compromised account, the persistent backdoor). Recovery restores the affected systems to a known-good state and returns them to production. The mistake teams make is collapsing these into a single step — declaring the incident over once eradication is done. Without verified recovery, you do not actually know whether eradication was complete. Many incidents are reopened in the post-mortem because residual artefacts surface days later.
Post-Incident Activity Is Where the Programme Improves
- A timeline of what happened, when, and what was decided — written within days, not weeks
- A root cause analysis that goes past the proximate technical cause to the systemic gaps
- Specific, owned actions to address those gaps, with deadlines and tracking
- Updates to runbooks, detection rules, and training material based on what was learned
- A debrief that includes the people who actually responded, not just leadership summaries
The teams whose IR programmes get steadily better year over year are not the teams with the best tools. They are the teams whose post-incident activity actually changes preparation. Every incident becomes a forcing function for runbook updates, detection improvements, and process refinement. Without that feedback loop, the lifecycle is decorative — the same mistakes keep being made by the same programmes for the same reasons.