NIST Retired the Four-Phase Incident Response Model. Most Runbooks Haven't Caught Up.
October 19, 2026
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
NIST's rewrite of SP 800-61 matters because it changes what "containing an incident" is supposed to mean. In April 2025, NIST retired the four-phase lifecycle that trained a generation of analysts and replaced it with a model built around the six functions of the Cybersecurity Framework 2.0, treating response as continuous risk management rather than a bounded event with a start and end date.
If your team still diagrams incident response as Preparation, Detection and Analysis, Containment and Eradication, and Post-Incident Activity, you're running a model NIST no longer endorses. That matters less for the diagram itself and more for what it signals: regulators, auditors, and insurers increasingly expect incident response to be evaluated as an ongoing capability, not a binder that gets pulled off a shelf after something breaks.
What Actually Changed in NIST SP 800-61 Revision 3?
NIST finalized Special Publication 800-61 Revision 3 in April 2025, formally superseding the 2012-era Revision 2 that most incident response training still references. The new guidance is explicit that incident response is a critical part of cybersecurity risk management and should be integrated across organizational operations, with all six CSF 2.0 functions playing a role rather than just the response-focused ones.
The structural change is the headline. NIST's own project documentation lays out the new life cycle model, noting that Govern, Identify, and Protect activities sit beneath the response itself as broader risk management work, while Detect, Respond, and Recover form the active incident response layer, with an Improvement function feeding lessons learned back into all of it continuously. That's a deliberate break from the old model, where a plan was considered complete once eradication and recovery wrapped up.
NIST was also candid about why it made this change. The agency noted that because the details of how to perform incident response activities change so often and vary so much across technologies and environments, it is no longer feasible to capture and maintain that information in a single static publication. In practice, that means the playbook your team built around the 2012 guidance was already out of date in structure, not just content.
For anyone studying toward a handler-focused credential, this is not a footnote. It changes how you should map roles, escalation paths, and post-incident reviews, since the framework now expects governance and identification work to feed directly into detection quality rather than sitting in a separate compliance document. Programs like the Certified Incident Handler certification build around exactly this kind of lifecycle thinking, which makes the CSF 2.0 alignment a direct study and practice concern, not background reading.
Why Does Attacker Speed Make the Old Model Obsolete?
Attacker behavior is the other half of why the static, phase-based model broke down. Mandiant's M-Trends 2026 report, based on more than 500,000 hours of incident response work in 2025, found that the global median dwell time rose to 14 days in 2025, up from 11 days in 2024, reversing several years of improvement.
That number alone undersells what's happening operationally. The same report found that organizations that detected intrusions internally did so in about nine days, while external notification cases took a median of 25 days, which means the gap between teams with mature detection and teams relying on a third party to tell them they've been breached is widening, not closing. A rising global median driven partly by North Korean IT worker operations and long-term espionage cases, both running a median dwell time of roughly four months, hides a more urgent story for everyone else: attackers are also moving faster at the handoff stage, with the window between initial access and handing control to a second threat group compressing from hours to seconds over the past few years.
Ransomware operators have adapted their targets to match. Mandiant's data shows operators moving beyond simple encryption-and-theft operations toward systematically denying organizations the ability to recover, specifically targeting identity services, virtualization management planes, and backup infrastructure. A four-phase model that treats recovery as the final, least-urgent step was never built for an adversary that attacks your backups before it ever touches your data.
This is also a broader industry shift than any one vendor's numbers. Infosecurity Magazine's reporting on the same dataset confirmed that the rise from 11 to 14 days was largely driven by North Korean-linked cyber espionage campaigns and IT worker incidents, which tells you the aggregate statistic can mask very different operational realities depending on your sector and threat profile. Your incident response plan needs to account for that variance, not just chase a single median number.
What This Means for How You Build and Run an IR Program
Put the regulatory shift and the attacker data together and the practical takeaway is straightforward: a plan that only activates after detection is already behind. The new NIST model asks you to treat governance, asset identification, and protective controls as inputs that determine how fast your detection function actually works, not as separate compliance exercises that happen once a year.
A few things change in day-to-day practice once you adopt that framing.
- Detection playbooks need explicit ties back to asset inventories and identity governance, since Rev 3 treats those as part of the response capability rather than prerequisites to it.
- Recovery planning has to assume backup and virtualization infrastructure are primary targets, not fallback systems, given how ransomware operators are now behaving.
- Post-incident reviews need a documented path for feeding lessons learned into training, tooling, and detection logic on a recurring basis, not just an after-action report that gets filed away.
None of this means scrapping your existing incident response plan and starting over. It means auditing it against the CSF 2.0 functions and being honest about where governance and identification work is actually feeding your detection and response capability, versus where it's sitting in a binder nobody opens between audits. Forge University's certification resource library includes curriculum breakdowns that map directly to these kinds of framework updates if you want a structured way to check your program against current guidance.
The Career Angle Nobody's Talking About Yet
Hiring managers screening for incident response roles are going to start asking candidates how they've adapted to the CSF 2.0-aligned model, the same way "can you explain containment versus eradication" used to be a standard interview question. If your only frame of reference is the retired four-phase lifecycle, that's a visible gap in an interview, not a minor detail.
This is also where certification study genuinely tracks job reality rather than just testing recall. Incident handling credentials built around current NIST guidance force you to practice mapping detection and response activities to governance and identification work, which is precisely the muscle the new framework expects you to have. If you want a study plan built around this shift rather than outdated phase diagrams, you can start training with materials that reflect the current standard instead of the one NIST withdrew.
The dwell time numbers make the stakes concrete. Fourteen days of unnoticed attacker presence, compressed to a 22-second handoff window once a second threat group gets involved, is not a gap a static, once-a-year-reviewed plan can close. It takes a team that treats identification, protection, and continuous improvement as part of the same job as detection and containment, which is exactly the shift NIST built Revision 3 to force.