NIST Special Publication 800-61 is the US National Institute of Standards and Technology’s guidance on cybersecurity incident response. Its current revision, Revision 3 from April 2025, is titled Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. It replaced Revision 2 from 2012, the long-standing Computer Security Incident Handling Guide. Organizations use it to structure incident response plans, align them with their wider security program and explain their approach to auditors, insurers and customers.
At a glance
- It is free, voluntary guidance from NIST, widely referenced in incident response plans and provider methods.
- Revision 2 described a four-phase life cycle; many plans and providers still use it.
- Revision 3 organizes incident response around the six CSF 2.0 functions: Govern, Identify, Protect, Detect, Respond and Recover.
- Revision 3 treats preparation as part of broader risk management and emphasizes continuous improvement from lessons learned.
- It gives priorities and recommendations rather than a step-by-step playbook.
What problem it solves
When an incident hits, organizations without a shared playbook lose time deciding who is in charge, who to call, what to preserve and when to notify. Response becomes improvised, evidence is lost and recovery takes longer than it needs to.
SP 800-61 gives a common structure and vocabulary for planning that work in advance. Revision 3 also addresses a broader problem: incident response is often treated as a separate activity owned by a few responders, while the decisions that matter, such as logging, backups, access control, supplier contracts and communications, sit across the whole organization. Tying incident response to the NIST Cybersecurity Framework (NIST CSF) helps connect it to governance, budgeting and board reporting.
How it works
The earlier life cycle. Revision 2 described four phases: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity, with lessons learned feeding back into preparation. Many organizations, providers and training courses still use these phases.
The CSF 2.0 model. Revision 3 maps those phases to the six CSF 2.0 functions. Govern, Identify and Protect are treated as preparation activities that are part of broader risk management. Detect, Respond and Recover are the incident response itself. Improvement, within the Identify function, collects lessons from every activity and feeds them back into all functions.
A community profile. Revision 3 is published as a CSF 2.0 Community Profile: a baseline of CSF outcomes for a shared use case. Each CSF function, category and subcategory is given a relative priority for incident response (high, medium or low) with recommendations and considerations. NIST encourages organizations to tailor these priorities to their own needs.
Roles beyond the responders. The guidance recognizes that leadership, legal, communications, IT operations and third parties such as managed service providers can have incident response responsibilities, and that these need to be defined before an incident.
Supporting resources. Rather than embedding detailed procedures, Revision 3 points to online resources mapped to CSF outcomes, and mentions playbooks as a common way to document actionable steps.
Revisions and structure
SP 800-61 has no levels or certification. The table shows how its two most recent revisions are structured, in general terms.
| Item | What it covers | How organizations use it | Typical evidence |
|---|---|---|---|
| Revision 2 (2012), now superseded | Four-phase incident handling life cycle and detailed handling guidance | Still common in existing plans and training | Incident response plan organized by phase |
| Revision 3 (2025), current | Incident response recommendations organized by CSF 2.0 functions, with priorities | Aligning the plan with a CSF-based security program | Plan and playbooks mapped to CSF outcomes |
| Preparation (Govern, Identify, Protect) | Policies, roles, asset knowledge and safeguards that support response | Part of ongoing risk management | Policies, contact lists, logging and backup evidence |
| Response (Detect, Respond, Recover) | Finding, analyzing, containing, eradicating and recovering from incidents | Run by internal teams and providers | Incident records, timelines, reports |
| Improvement | Lessons learned from all activities | After incidents and exercises | After-action reports and tracked actions |
Neither revision is something an organization is certified against. This is general information, not legal advice; contracts and regulators may set their own incident notification and reporting rules.
When it matters for buyers
- When writing or refreshing an incident response plan. Revision 3 is a current reference for structure and priorities.
- When selecting MDR, SOC or IR services. Shared vocabulary makes handoffs clearer between your team and the provider.
- When negotiating an incident response retainer. Agree how the provider’s method fits your plan before you need it.
- When an insurer, auditor or customer asks about incident response. A plan aligned with NIST guidance is easier to explain.
- When linking response to recovery. Response planning connects to contingency and disaster recovery planning.
Our incident response overview covers retainers, emergency response and planning services from specialist providers.
Questions to ask vendors
- Which revision of NIST SP 800-61 does your incident response method follow?
- How do your response phases map to our plan and to CSF 2.0 functions?
- What do you need from us during an incident: access, logs, decision makers, contacts?
- Who leads containment decisions, and what can you do without our approval?
- What reports and lessons-learned outputs do we receive after an incident?
- How often do you run tabletop exercises with customers, and is that included?
How it differs from incident response
Incident response (IR) is the practice itself: the people, processes and tools an organization uses to detect, contain and recover from security incidents. NIST SP 800-61 is one publication that gives guidance on how to organize that practice. An organization’s incident response plan may follow SP 800-61, another framework or a provider’s method; the guide is a reference for structure and priorities, not the plan itself. For keeping operations running after an incident, see NIST SP 800-34 on contingency planning.
Problems this helps with
- Our incident response plan is old and nobody has tested it
- Need to show auditors or an insurer that incident response follows a recognized guide
- Unsure how incident response fits with the rest of our security program
- Our MDR provider and internal team describe incident phases differently
