NIST SP 800-61 Rev. 3: incident response rebuilt around CSF 2.0

What it is

SP 800-61 has been the most cited incident response reference for more than a decade. Rev. 2 (2012) gave the well-known lifecycle: Preparation; Detection and Analysis; Containment, Eradication and Recovery; Post-Incident Activity. Many certification syllabuses, SOC runbooks and university courses still teach it.

Rev. 3, titled Incident Response Recommendations and Considerations for Cybersecurity Risk Management, was finalised on 3 April 2025. It is explicitly a CSF 2.0 Community Profile: it uses the Functions, Categories and Subcategories of the NIST Cybersecurity Framework 2.0 to describe what organisations should do before, during and after incidents.

Why it matters

Incidents have changed since 2012. Ransomware, cloud and SaaS compromises, supply chain attacks and identity-based intrusions involve many teams: legal, communications, IT operations, suppliers and executives, not just a security response team. Regulations such as the EU NIS2 Directive now set firm reporting deadlines. Rev. 3 reflects that response depends on preparation and governance throughout the organisation, and that recovery is a business activity, not only a technical one.

Key ideas

• Preparation is spread across Govern, Identify and Protect. Policies, roles, asset knowledge, risk assessment and protective controls all reduce how often incidents happen and how bad they get.
• Response is Detect, Respond and Recover. Detection includes continuous monitoring and adverse event analysis; Respond covers incident management, analysis, reporting, communication and mitigation; Recover covers restoration and recovery communications.
• Improvement is continuous. Lessons learned feed back into all Functions through the CSF Improvement Category, rather than being a final phase.
• Roles are broad. The guide lists responsibilities for leadership, legal, public relations, HR, physical security and third parties, as well as technical responders.
• Less detail in the PDF. Rather than freezing specific technical procedures in the text, Rev. 3 points to other resources that are updated more often.

What changed in practice

The main practical change is vocabulary and structure. Teams that describe their programme in CSF terms can now align incident response with the rest of their risk work. The removal of much of Rev. 2’s detailed handling content also means teams should keep their own playbooks, or use other sources, for technical steps such as evidence collection. Many organisations keep the four-phase model for day-to-day operations and use Rev. 3 to frame governance, metrics and reporting.

A short scenario shows the difference. A ransomware alert fires at 02:00. Under a Rev. 2 mindset, the night shift contains the host and the story begins there. Under Rev. 3, the questions start earlier and go wider: did Govern define who may approve taking a production system offline at night? Did Identify record which business service that server supports? Is there an agreed threshold for notifying the regulator? Recovery is measured by when the service is safely restored and customers informed, not only when the malware is removed.

How practitioners apply it

1. Map your current plan to CSF. Take your existing incident response plan and tag each section with CSF Categories. Gaps in Govern (who decides, who pays, who talks to regulators) are common.
2. Agree severity and reporting rules in advance, including legal deadlines and who notifies customers and authorities.
3. Prepare telemetry. Centralised logging with accurate time (see syslog and NTP) is essential for analysis.
4. Write technical playbooks for likely scenarios such as ransomware, business email compromise and lost devices. Map them to ATT&CK techniques.
5. Exercise. Run tabletop exercises with executives and technical drills with engineers at least yearly, and record improvements.

Useful metrics to agree in advance include mean time to detect, mean time to contain, mean time to restore critical services, and the proportion of incidents found internally rather than reported by outsiders. Reporting these through Govern gives leadership a factual view of whether investment in detection and recovery is working, which is exactly the integration Rev. 3 is trying to encourage.

Tip: Keep an offline copy of contacts and playbooks. During a serious incident, email, chat and the document server may be unavailable or untrusted.

Limitations and open questions

• Less hands-on guidance. Practitioners who valued Rev. 2’s checklists may find Rev. 3 abstract.
• Training lag. Many exam syllabuses still use the four-phase model, so students need to know both.
• Measuring response quality (time to detect, contain, recover) is encouraged but not standardised.
• Cloud and SaaS evidence depends heavily on what providers log and retain, which organisations must negotiate in contracts.