NIST SP 800-61 — Computer Security Incident Handling Guide — is the foundation document for incident response in U.S. federal practice, and through that influence, in most enterprise IR programs worldwide. It defines four phases that form a continuous cycle: when one incident wraps up, the lessons feed straight back into the preparation phase for the next.
Knowing the four phases is table stakes. Knowing what artifacts and decisions live in each — and which ones organizations consistently get wrong — is what separates a useful IR analyst from a checkbox-following one.
Analysis
Eradication,
Recovery
Activity
←→ Lessons learned feed Preparation for the next incident
Preparation
Everything you wish you had set up before the alert fires. Preparation is the unglamorous phase that determines whether the next three phases are productive or chaotic.
IR plan & playbooks for the categories that fit your organization. Asset inventory. Network diagrams. Out-of-band communications (Signal group, dedicated phones). Forensic toolkits on bootable media or pre-staged systems. Legal & PR pre-approvals for breach notification timelines.
Plans written for a single hypothetical, then never exercised. Tabletop exercises skipped because "we know what we'd do." Out-of-band comms not actually configured. Most IR plan failures look like: "We had a runbook, but nobody had read it."
Detection & Analysis
An alert fires (or a tip comes in). The team validates that it's real, scopes the impact, and characterizes what happened. This is where the most time is spent and where most mistakes are made.
Indicators of Compromise (IOCs) — hashes, IPs, domains, file paths. Timeline — what happened when, in chronological order. Scope assessment — which systems, accounts, data. Attribution hypothesis (when relevant) — which threat actor, with what confidence.
Confirmation bias. Once a hypothesis exists, evidence gets shoehorned into it. Scope creep undercount. "We think it's just this one box" usually means another six are involved. Tunnel vision on one attack vector while another runs in parallel.
Containment, Eradication, Recovery
Stop the bleeding (containment), remove the attacker's foothold (eradication), restore operations (recovery). These three are technically distinct phases in some frameworks; NIST groups them because the same incident commander typically owns all three.
Short-term: isolate hosts from the network; revoke credentials; block C2 domains. Long-term: deploy compensating controls while a permanent fix is engineered. Trade-off: cutting power preserves nothing forensically; leaving systems online lets the attacker continue.
Eradication: rebuild rather than clean. Reset every credential the attacker could have touched (not just the ones you saw them use). Recovery: stage restoration carefully — monitoring should be heightened during the first weeks back so re-compromise is detected immediately.
Post-Incident Activity
The phase organizations skip and then regret. After the immediate crisis passes, the team does the work that prevents repeats and improves response.
Lessons-learned meeting within 1-2 weeks of the incident closing. Written incident report with timeline, scope, IOCs, root cause, and remediation. Action items with owners and deadlines — updates to detection rules, hardening guidance, playbook revisions.
The lessons-learned meeting is most productive when it is blameless. The action items are most likely to actually happen when they have named owners, tracked dates, and are reported on in security council meetings until done. Otherwise the report goes in a folder and nothing changes.
The phases repeat
The most important property of the lifecycle is that it loops. Lessons from Post-Incident Activity feed straight back into Preparation. New playbooks get written, new detection rules get deployed, new tabletop scenarios get added. Programs that don't loop don't improve. They handle each incident as a first-time event and re-learn the same lessons.
Related frameworks
- SANS PICERL — Preparation, Identification, Containment, Eradication, Recovery, Lessons learned. Same content, different breakdown. Used heavily in SANS-trained shops.
- NIST CSF 2.0 — the broader cybersecurity framework. Respond and Recover functions in CSF correspond to phases 2–4 here.
- ITIL incident management — designed for IT outages but increasingly aligned with security IR. Sometimes runs in parallel for the operational side.
- Internal frameworks — mature organizations customize NIST 800-61 with their own playbook taxonomy, severity rubric, escalation tiers. The phases stay; the procedures get specific.
The four NIST phases are the structure every IR program builds around. Preparation determines whether the other three are competent. Detection & Analysis is where you spend the most time. Containment-Eradication-Recovery is judgment under pressure. Post-Incident is where the program improves.
Memorize the four phases. Understand what each produces and where it fails. The mature IR analyst doesn't think in terms of "what should I do now" — they think in terms of which phase they're in and what that phase requires.
References
Formatted in APA 7.
- Cichonski, P., Millar, T., Grance, T., & Scarfone, K. (2012). Computer security incident handling guide (NIST Special Publication No. 800-61, Rev. 2). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-61r2
- National Institute of Standards and Technology. (2024). Cybersecurity framework (CSF) 2.0 (NIST CSWP No. 29). https://doi.org/10.6028/NIST.CSWP.29
- SANS Institute. (n.d.). Incident handler's handbook. https://www.sans.org/white-papers/33901/