NIST Incident Response Framework: SP 800-61 Rev. 3 Explained

The four-phase incident response lifecycle — Preparation, Detection and Analysis, Containment/Eradication/Recovery, Post-Incident Activity — was the standard. Every incident response plan template, every CSIRT training program, every audit checklist was organized around those four boxes. The source was NIST SP 800-61 Rev. 2, published in 2012.

That document is now officially withdrawn.

On April 3, 2025, NIST released SP 800-61 Revision 3 and simultaneously withdrew Rev. 2. The replacement is fundamentally different in structure, scope, and philosophy. If your incident response program was built using Rev. 2 as a baseline, there are specific things you need to update — and some of them go deeper than a document refresh.

TL;DR

• NIST finalized SP 800-61 Rev. 3 on April 3, 2025, simultaneously withdrawing the 2012 Rev. 2. The four-phase lifecycle is gone.
• Rev. 3 restructures incident response around the six functions of NIST CSF 2.0: Govern, Identify, Protect, Detect, Respond, and Recover.
• The framework is now principles-based rather than prescriptive — NIST explicitly says technology changes too fast for step-by-step procedures to remain current.
• Key new emphases: incident-type-specific playbooks, SIEM/SOAR integration, cyber threat intelligence (CTI), ISAC participation, and formalized incident declaration criteria.
• What to update: your IR framework documentation, playbook architecture, CSIRT governance documentation, and CSF 2.0 alignment mapping.

Why Rev. 2 Was Retired After 13 Years

SP 800-61 Rev. 2’s four-phase lifecycle wasn’t wrong — it was prescriptive in ways that don’t age well. Technology environments in 2012 were primarily on-premises. The threat landscape didn’t include cloud-native infrastructure at scale, SaaS supply chain attacks, or the industrialized ransomware-as-a-service ecosystem that defines today’s threat environment.

Rev. 2 told organizations specifically what tools to deploy, how to structure log reviews, what fields to capture in incident tickets. By 2025, those specifics were obsolete in most environments. The cloud SIEM your team runs today bears no operational resemblance to the on-premises log aggregation Rev. 2 described. Detection is now heavily automated in ways that make Rev. 2’s manual detection guidance a historical artifact.

NIST’s stated rationale was explicit: “The details of how to perform incident response activities change so often and vary so much across technologies, environments, and organizations, it is no longer feasible to capture and maintain the detailed prescriptive guidance that was in Rev. 2.”

Rev. 3’s response is to move from procedures to principles — from “here’s exactly what to do” to “here’s how incident response integrates with your broader cybersecurity risk management program.” That is a meaningful philosophical shift, and it changes how you should read and use the document.

The New Structure: CSF 2.0 Function Mapping

Instead of four phases, Rev. 3 organizes incident response recommendations across all six functions of NIST Cybersecurity Framework 2.0. The core logic: incident response isn’t a standalone process that activates when something goes wrong. It’s the activation of your entire cybersecurity program under stress. Functions that seemed purely preventive — like asset management in Identify or access controls in Protect — directly determine your incident response effectiveness.

Govern

The GOVERN function is new in CSF 2.0 (it didn’t exist in CSF 1.1). In the incident response context, Govern covers:

• Establishing IR governance: who owns incident response, what’s the authority structure, how it connects to enterprise risk management
• Maintaining an incident response policy that defines scope, severity classifications, and escalation thresholds
• Ensuring IR roles and responsibilities are documented and understood before an incident
• Integrating IR findings into the risk management cycle — post-incident findings should update the risk register, and risk appetite should inform IR prioritization

The practical implication: if you have a detailed IR plan but no executive ownership and no connection to risk governance, you’re not meeting Govern’s intent. The CSIRT team structure and chain of authority should be explicitly chartered — not improvised when the alert fires.

Identify

The IDENTIFY function sets the foundation that makes effective detection and response possible:

• Asset inventory: You cannot detect an incident on a system you don’t know exists. This is not aspirational guidance — it’s a prerequisite. Organizations without accurate asset inventories consistently struggle to scope incidents quickly.
• Vulnerability management: Understanding your attack surface informs which incident types are plausible and where to focus detection.
• Risk assessment: Threat modeling tells you which incident categories you’re most likely to face — and that should drive your playbook prioritization.
• Supply chain and third-party mapping: Your vendor dependencies affect your detection scope and your response communications. If a vendor breach triggers your incident, you need to know which systems they access.

The organizations hit hardest by the MOVEit exploitation in 2023 and the CrowdStrike content update failure in 2024 were frequently those without accurate inventories of affected systems and downstream dependencies. Identify is the function that determines whether you spend two hours or two weeks scoping an incident.

Protect

PROTECT covers the pre-incident controls that reduce likelihood and severity. Rev. 3 connects protective control failures directly to incident outcomes — rather than treating protection and response as separate domains.

Key PROTECT considerations for incident response readiness:

• Privileged access management: The Scattered Spider attacks on MGM Resorts and Caesars Entertainment in September 2023 both began with social engineering calls to IT help desks to reset MFA on privileged accounts. Strong MFA policies and help desk verification procedures are protective controls that directly determine your blast radius when social engineering succeeds.
• Backup integrity: Rev. 3 specifically highlights protecting backup infrastructure. Ransomware actors routinely target backup systems before deploying encryption. Immutable backups stored in isolated environments are the single most impactful recovery control in a ransomware scenario.
• Security awareness training: Human error remains a leading incident root cause. Awareness training is listed in PROTECT because it prevents incidents — but it also reduces incident scope when employees know how to recognize and report anomalies quickly.

Detect

The DETECT function is where Rev. 3 makes its most substantive operational contributions. The two CSF 2.0 categories that receive the most attention are DE.AE (Anomalies and Events) and preparation for RS.AN (Respond: Incident Analysis).

SIEM and SOAR integration: Rev. 3 explicitly recognizes that most organizations invest in security information and event management (SIEM) or security orchestration, automation, and response (SOAR) platforms to consolidate and analyze activity and filter alert noise. These tools should automatically escalate only events requiring human judgment — the challenge isn’t generating alerts, it’s managing signal-to-noise ratio at scale.

Cyber threat intelligence (CTI): Rev. 3 emphasizes integrating threat intelligence into detection to contextualize events. A detected anomaly has very different risk implications if CTI indicates your sector is currently being targeted by the threat actor whose TTPs match what you’re seeing. Raw telemetry without threat context produces analyst fatigue; threat-contextualized telemetry produces prioritized response.

ISAC participation: Rev. 3 explicitly recommends participating in information-sharing communities suited to your sector. For financial services organizations, the FS-ISAC provides early warnings on threat actors targeting the sector, shared indicators of compromise, and peer response coordination. Health-ISAC serves healthcare organizations. MS-ISAC serves state, local, tribal, and territorial governments. Participation gives your detection team threat context that internal telemetry alone cannot provide.

Incident categorization: Rev. 3 recommends defining incident categories upfront — ransomware, insider threat, credential compromise, data exfiltration, third-party breach — so that when detection fires, the category determination immediately routes to the correct playbook.

Respond

The RESPOND function covers execution during an active incident. Rev. 3’s key contributions:

Incident declaration criteria: Rather than leaving “this is an incident” to in-the-moment judgment, Rev. 3 recommends defining criteria upfront — what severity level triggers formal incident declaration, what events escalate to executive notification, what triggers the incident commander role. Pre-defined criteria reduce the delay and organizational friction that consistently slows early-phase response.

Playbook architecture: This is one of Rev. 3’s clearest operational requirements. Incident-type-specific playbooks — documented step-by-step procedures for specific categories — are recommended rather than a single generic response procedure. Each playbook should include:

• Detection indicators that trigger this playbook
• Immediate containment actions and who has authority to execute them
• Evidence preservation steps required before remediation begins
• Internal notification chain with escalation thresholds
• External notification obligations with applicable regulatory deadlines
• Criteria for engaging law enforcement (FBI Cyber Division) or CISA

Building that playbook structure is one of the most concrete implementation actions practitioners can take after reading Rev. 3.

Communication and coordination: Rev. 3 expands the communication model from Rev. 2’s notification-centric approach to a broader coordination framework. Communication runs concurrently with response — not after the incident is resolved. This includes coordination with CISA, law enforcement, sector-specific regulators, insurance carriers, and peer organizations through ISACs. Getting notification mechanics documented in advance, rather than figuring them out during an incident, is the entire point.

Recover

The RECOVER function in Rev. 3 emphasizes three elements:

• Recovery planning: Documented procedures for restoring systems, verifying integrity before returning to production, and validating that the root cause has been eradicated before restoration
• Post-incident improvement: Written after-action reviews that produce documented findings, root cause analysis, and specific plan updates — not verbal debriefs that produce no institutional memory
• Recovery communications: Managing stakeholder expectations during restoration, including regulator and customer communications that must continue while technical recovery is in progress

The Three CSIRT Models

SP 800-61 describes three models for organizing incident response capability. Rev. 3 doesn’t prescribe a specific model — the right choice depends on organizational size and structure.

What Rev. 3 does require — regardless of model — is that the structure, authorities, and escalation paths are documented before an incident, and that the model is tested through exercises. An undocumented CSIRT structure is a governance gap that examiners and auditors will find.

What You Actually Need to Update

If your incident response program was built using SP 800-61 Rev. 2 as a baseline, here’s the practical update list:

IR Policy and Framework Documentation

Update all references from Rev. 2 to Rev. 3. More importantly, update the structural framing. If your policy references “the NIST four-phase lifecycle,” that language needs to be replaced with CSF 2.0 function mapping. The policy should articulate how incident response capabilities span Detect, Respond, and Recover — and how Govern, Identify, and Protect feed into IR readiness.

Playbooks by Incident Type

If you have a single incident response plan rather than incident-type-specific playbooks, this is the change Rev. 3 most clearly supports. Prioritize building playbooks for:

1. Ransomware (including isolation authority and ransom payment decision tree with OFAC sanctions screening)
2. Business email compromise
3. Data exfiltration
4. Third-party/supply chain breach
5. Insider threat

Each should include the regulatory notification decision for that incident type — because different incident types trigger different reporting clocks. The incident response plan template and the state breach notification law framework provide the regulatory notification scaffolding.

CSIRT Governance Documentation

Rev. 3’s GOVERN function emphasis means your CSIRT needs a documented charter: authority to take specific actions (network isolation, account disabling, vendor access revocation), defined escalation paths, roles and backups, and executive accountability. If your CSIRT exists informally — “the security team handles incidents” — that’s a governance gap.

CSF 2.0 Alignment Mapping

If your organization uses NIST CSF as a framework baseline (and your regulators increasingly expect you to), your incident response mapping should reference CSF 2.0 — not CSF 1.1 or the old four-phase lifecycle. Map your existing IR capabilities to the Detect, Respond, and Recover functions and their subcategories. Gaps in DE.AE (anomaly detection) and RS.AN (incident analysis) are the areas Rev. 3 most explicitly addresses.

Regulatory Notification Integration

Rev. 3 treats notification as part of a broader coordination function. Your IR documentation should include a regulatory notification decision tree that maps incident categories to applicable reporting obligations:

• OCC-supervised banks: 36 hours from discovery of a computer security incident meeting the notification threshold
• CIRCIA: 72 hours for covered critical infrastructure entities (ransomware payment: 24 hours)
• SEC: 8-K on material cybersecurity incidents within four business days of determining materiality
• State breach notification: Varies by state, from “immediately” to 30–90 days depending on jurisdiction — see the 50-state comparison

These clocks run concurrently. A single incident can trigger multiple notification obligations with different start times and deadlines.

So What?

Thirteen years is a long time in cybersecurity. The gap between what Rev. 2 described and what modern incident response actually looks like operationally had grown wide. Rev. 3 closes that gap by stopping trying to prescribe technology-specific procedures and instead defining the principles and functions that effective incident response needs to achieve.

The practical implication isn’t that you throw out your existing program. Most organizations with mature IR capabilities will find that their practices already align with Rev. 3’s principles — they just need to update the documentation and add the playbook layer.

What matters most in Rev. 3 is the integration message: incident response is not a binder that gets opened when something goes wrong. It’s a capability embedded across all six CSF 2.0 functions, from the asset inventory that enables detection scoping to the governance structure that enables rapid decision authority to the post-incident review that actually improves the program. If your IR program only functions as a reactive checklist, Rev. 3 is a good reason to change that.

The Incident Response & Breach Notification Kit includes an IRP template aligned to NIST SP 800-61 Rev. 3, incident-type-specific playbooks, a regulatory notification decision tree, and a post-incident review template.