NIST Incident Response Lifecycle: The Complete 2026 Guide

The NIST incident response lifecycle that SP 800-61 Rev. 2 made familiar has four phases, and NIST no longer uses them. Since April 2025 the current publication, SP 800-61 Rev. 3, organizes incident response around the six Functions of the NIST Cybersecurity Framework (CSF) 2.0 instead.

The four phases did not disappear, though. Rev. 3 maps each one onto CSF Functions in its Table 1, and it lets organizations keep whichever life cycle model suits them best. This guide shows that mapping, explains the model Rev. 3 draws in its place, and gives decision rules for which version your plan should use.

A note on spelling: NIST writes “life cycle” as two words. This article uses “NIST incident response lifecycle” as the common search term for the same thing.

The four phases of the original NIST incident response lifecycle

Rev. 2, the Computer Security Incident Handling Guide of August 2012, described incident handling as four phases:

1. Preparation — building the capability to respond and reducing the number of incidents in the first place.
2. Detection and Analysis — spotting possible incidents, confirming them and working out their scope.
3. Containment, Eradication and Recovery — stopping the spread, removing the cause and restoring normal operations.
4. Post-Incident Activity — reviewing what happened and feeding lessons back into the program.

This version of the NIST incident response lifecycle is simple, easy to teach and easy to draw on a whiteboard. Its weakness is that it treats incident response as a self-contained process owned by one team. Preparation reads as something the response team does, and improvement waits until the incident is over.

Why Rev. 3 replaced the phases

Section 1.1 of Rev. 3 says its scope differs significantly from earlier versions, and that the details of how to perform incident response change too often to capture in one static publication. The Appendix C change log describes a full rewrite whose focus shifted from handling guidelines to recommendations across cybersecurity risk management.

To do that, NIST rebuilt the document as a CSF 2.0 Community Profile: 134 rows covering 6 Functions, 22 Categories and 106 Subcategories, each rated High, Medium or Low for its contribution to incident response. Our NIST 800-61 Rev 3 guide covers that structure in full. Once the document is organized by Function, the four phases have to be expressed in Function terms.

Table 1: the NIST incident response lifecycle mapped to CSF 2.0

Table 1 of Rev. 3 maps each Rev. 2 phase to the CSF 2.0 Functions that now carry its work. The third column is our reading of what each row means for your plan.

Rev. 2 phase	Rev. 3 CSF 2.0 Functions (Table 1)	What it means in practice
Preparation	Govern; Identify (all Categories); Protect	Policy, roles, risk assessment and safeguards are organization-wide work, not a response-team task
Detection and Analysis	Detect; Identify (Improvement)	Monitoring and adverse event analysis, with improvements captured as they are found
Containment, Eradication and Recovery	Respond; Recover; Identify (Improvement)	Response and restoration split into two Functions, both feeding improvement
Post-Incident Activity	Identify (Improvement)	Lessons learned become part of continuous improvement across the program

Read the table by column, not by row, because that is where the NIST incident response lifecycle changed most. The Improvement Category (ID.IM) appears against three of the four phases. In the NIST incident response lifecycle as Rev. 3 frames it, improvement is not a final step; it runs alongside detection, response and recovery.

The model Rev. 3 draws instead (Figure 2)

Figure 2 of Rev. 3 replaces the circular diagram with a layered NIST incident response lifecycle. Govern, Identify and Protect sit at the bottom as preparation; Rev. 3 is explicit that this layer supports incident response but is not incident response itself. Detect, Respond and Recover form the incident response layer. Improvement (ID.IM) sits in the middle, connecting both.

The practical message is in the improvement layer. Lessons are shared as soon as they are identified, not held until recovery ends. A detection gap found on the first day of an incident should reach the team that owns detection on that day.

Preparation: Govern, Identify and Protect

This layer holds the incident response policy (GV.PO.R1), documented roles and authorities (GV.RR-02), legal and contractual notification requirements (GV.OC-03.R1), risk assessment and threat intelligence (ID.RA), and safeguards such as tested backups (PR.DS-11). Most of these rows are Medium or Low, but seven Table 2 Subcategories are High, including ID.RA-05 and ID.RA-06.

Incident response: Detect, Respond and Recover

Every Subcategory in these three Functions is rated High. The key decision points in this layer of the NIST incident response lifecycle are:

• Declare: DE.AE-08 says incidents are declared when adverse events meet defined incident criteria, applied with known false positives in mind.
• Triage and prioritize: RS.MA-02 and RS.MA-03 validate reports, then categorize and prioritize them. RS.MA.R1 rules out first-come, first-served handling.
• Investigate: RS.AN establishes what happened, the root cause and the incident’s magnitude.
• Contain and eradicate: RS.MI-01 and RS.MI-02, with manual action allowed alongside automated measures.
• Restore: RC.RP checks backups and restored assets for indicators of compromise before use, and closes with an after-action report (RC.RP-06.R1).
• Communicate: RS.CO and RC.CO cover coordination, notification and public updates during response and recovery.

Improvement: ID.IM

Three of the four improvement Subcategories are High. ID.IM-02 covers improvements from tests and exercises, including those run with suppliers. ID.IM-03 covers improvements from running your own processes, which includes every response and recovery effort. ID.IM-04 covers establishing, maintaining and improving the incident response plan itself.

Continuous improvement replaces post-incident activity

Rev. 3 still values the lessons learned meeting. A note under ID.IM-03 describes follow-up reports and meetings held as recovery concludes, especially for major incidents, as a source of improvements. The difference is that the meeting is one input, not the only one.

Turn that into rules your team can follow:

• Open an improvement record the moment someone identifies a gap, during or after the incident. Give it an owner and a due date.
• Route each improvement to the right place. It may change the incident response program, or it may belong to another part of risk management, such as a detection rule or a safeguard.
• Run exercises and log their findings in the same register, so test results and real-incident lessons are compared side by side.
• Review plans periodically and whenever a significant improvement is identified, as ID.IM-04.R2 recommends.

Speed metrics help here. If you track time to detect and time to respond, our MTTD vs MTTR explainer covers how to define them so they measure what you intend.

Common mistakes when mapping the NIST incident response lifecycle

Teams moving from the four phases to the Functions tend to repeat the same handful of errors. Check your mapping against each one.

• Mapping Preparation to Protect alone. Table 1 maps it to Govern, every Identify Category and Protect. Policy, roles and risk assessment belong in your preparation evidence, not only technical safeguards.
• Parking improvement at the end. If ID.IM appears only against Post-Incident Activity in your mapping, you have rebuilt the old NIST incident response lifecycle under new labels.
• Cutting recovery loose from response. RS.MA-05 applies criteria for initiating recovery, and RC.RP-01 executes the recovery portion of the incident response plan once the response process initiates it. Recovery is a decision the response team triggers, not a separate IT project.
• Dropping Low-rated rows. Low means a row supports incident response indirectly. Keep it in scope and give it less effort.

A quick test for any mapping: pick one past incident and trace each decision in it to a row of the profile. Where no row fits, your NIST incident response lifecycle mapping has a gap.

Which NIST incident response lifecycle should your plan use?

Rev. 3 says organizations should use whichever life cycle model suits them best. That is a freedom, not an exemption: whatever model you pick, your evidence still has to show the outcomes in the profile. Use these rules to decide.

Your situation	Decision rule
Staff already trained on the four phases	Keep the four phases as the operating model; add a Table 1 mapping to the plan
Program already run against CSF 2.0	Organize the plan by Function so evidence lines up with your CSF profile
Auditor or customer asks for Rev. 3 alignment	Show the Function mapping and the rows you rated differently from NIST, with reasons
Small team with no formal model yet	Start with Detect, Respond and Recover; add Govern and Identify work as roles mature

Whichever NIST incident response lifecycle you choose, do not keep two parallel models. Pick one for operations and treat the other as a cross-reference table.

If you are new to the Functions themselves, our NIST Cybersecurity Framework overview explains them. The source for everything above is NIST SP 800-61 Rev. 3, Section 2.1 and Table 1.

NIST incident response lifecycle FAQ

What are the four phases of the NIST incident response lifecycle?

In Rev. 2 they were Preparation; Detection and Analysis; Containment, Eradication and Recovery; and Post-Incident Activity. Rev. 3 maps them to CSF 2.0 Functions.

Does Rev. 3 still have a NIST incident response lifecycle?

It replaces the four-phase cycle with a layered model: preparation (Govern, Identify, Protect), incident response (Detect, Respond, Recover) and improvement (ID.IM) between them.

Can I keep the four phases in my plan?

Yes. Rev. 3 says to use whichever life cycle model suits you best. Add the Table 1 mapping so auditors can trace your phases to the Functions.

Where did lessons learned go?

Into the Identify Improvement Category. Lessons are captured and shared as soon as they are found, not held until recovery ends.

Our Incident Response Toolkit provides 93 editable templates aligned to NIST SP 800-61 Rev. 3 — including the Incident Response Plan, the Lessons Learned and Post-Incident Review Procedure and the Toolkit Guide and Rev 2 to Rev 3 Transition — for $99.