NIST SP 800-61 and the Incident Response Lifecycle, Explained

What NIST 800-61 actually is (and is not)

It is a guide, not a mandate. Unlike NERC CIP for utilities or FDA guidance for device makers, no regulator requires compliance with SP 800-61 by name. Its force is practical: it is the shared vocabulary of incident response. Insurer questionnaires reference its lifecycle, auditors test plans against its phases, and RFPs ask vendors to evidence response procedures mapped to it.

Revision 2 frames incident handling as four phases: Preparation; Detection and Analysis; Containment, Eradication and Recovery; and Post-Incident Activity. That structure has held up because it matches what actually happens during an incident, which is why most IR plan templates, including the ones tool vendors generate, are 800-61r2 in disguise.

What Revision 3 changed

Revision 3 aligns with the NIST Cybersecurity Framework 2.0 and reframes incident response as a component of cybersecurity risk management rather than a standalone discipline. Where r2 organized around phases, r3 organizes around outcomes: communicating (who needs to know what, when), controlling (the incident-handling actions themselves), and coordinating (internal teams, third parties, regulators, and external IR providers).

It also updates the 2012 assumptions: cloud-hosted environments where evidence lives in provider logs, third-party and supply-chain incidents the organization must coordinate but does not control, and the reality that external incident response firms, breach counsel, and carriers are part of the response team, not an afterthought.

Mapping your IR plan to 800-61, the checklist

Preparation: does the plan name roles with contact paths, classify incident severity with defined criteria, and pre-authorize the decisions that cannot wait for a meeting (who may isolate a production segment, who may engage external counsel, who may engage the incident response retainer)?

Detection and analysis: does it list the detection sources you actually operate, define what makes an alert an incident, and say who establishes impact scope and how evidence is preserved while the clock runs?

Containment, eradication and recovery: does it contain environment-specific playbooks (enterprise IT, cloud, and OT where applicable) with the different containment actions each requires? Isolating a cloud workload and isolating a plant-floor PLC are different decisions with different blast radii.

Post-incident activity: does it mandate the lessons-learned review, feed findings back into detection and hardening, and set who owns the corrective actions with a deadline?

The external resources section: does it name, by name, the incident response firm, the breach counsel, the notification vendor, and the carrier panel requirements, before the incident starts the countdown?

Where 800-61 shows up in buying decisions

Cyber insurers increasingly ask how your IR plan aligns to 800-61 during underwriting, and panel-vetting criteria reference its lifecycle. When you evaluate an incident response firm, the same structure applies in reverse: ask how their engagement phases map to your plan, who holds each responsibility during a declared incident, and how their reporting feeds your post-incident activity.

A firm that cannot describe its containment decision criteria, evidence handling, or coordination with your counsel in 800-61 terms is telling you something, the framework is the lingua franca of the discipline, and fluency in it is table stakes.