Incident Response Lifecycle: NIST Phases and Updates

Last verified on Nov 8, 2026.

The incident response lifecycle is the sequence of activities an organization uses to handle an incident, from getting ready for one through learning from it. The best-known description comes from NIST SP 800-61, and the version many teams still quote is no longer current.

NIST Rev. 2: Four Phases

NIST SP 800-61 Rev. 2 (August 2012) described a circular lifecycle:

Preparation. Build the response capability and prevent incidents by securing systems.
Detection and analysis. Find signs of an incident and work out what is happening.
Containment, eradication, and recovery. Limit the damage, remove the cause, and restore service.
Post-incident activity. Hold a lessons learned review and feed improvements back into preparation.

Rev. 2 has practical advice that still holds. Containment decisions are easier when strategies are decided ahead, with criteria such as potential damage, need to preserve evidence, service availability, time and resources needed, and how long the fix will last. It also calls for a lessons learned meeting within several days of the end of a major incident, with questions like what happened and when, whether the procedures were followed and were adequate, and what indicators to watch for next time.

NIST Rev. 3: What Changed

NIST published SP 800-61 Rev. 3 in April 2025, and it supersedes Rev. 2. The model changed:

It is organized around the six CSF 2.0 Functions: Govern, Identify, Protect, Detect, Respond, and Recover.
Detect, Respond, and Recover are the incident response itself.
Govern, Identify, and Protect are broader risk management that prepares for incidents and reduces their impact. NIST says they are not part of the response itself.
Improvement runs through everything, with lessons learned fed in continuously. NIST describes the older model as suited to a time when incidents were rarer and recovery took a day or two. It says incidents now occur frequently, recovery can take weeks or months, and lessons should often be shared as soon as they are identified, not after recovery.

NIST also says organizations should use whichever lifecycle model suits them best, and that the Rev. 3 model is built on CSF 2.0 to take advantage of the resources already available for it. So the four phases are a fair way to explain the work, but when a policy or audit asks which NIST guidance you follow, the current document is Rev. 3.

Rev. 2 phase	Rev. 3 Function
Preparation	Govern, Identify, Protect (outside the response itself)
Detection and analysis	Detect
Containment, eradication, and recovery	Respond and Recover
Post-incident activity	Improvement, continuous

This mapping is an approximation drawn from the two documents, not an official crosswalk.

A Reliability View: Google's Incident Command

Google's SRE material describes how to run an incident rather than how to categorize its phases. It builds on the Incident Command System and names the three Cs: coordinate the response, communicate between responders and with the organization and the outside world, and maintain control. The practices that follow are to keep a clear line of command, designate defined roles, keep a working record of debugging and mitigation as you go, and declare incidents early and often. An incident that was not declared early can leave a team without the tools to respond quickly and in an organized way.

A Practical Walkthrough

For a reliability incident, the loop looks like this:

Detect. An alert or a user report. See alert fatigue for why the first step often fails.
Classify. Assign a level from your incident severity levels and page the on-call engineer.
Respond. Follow the runbook, assign roles, and keep a timeline.
Mitigate and recover. A rollback or canary halt is often the fastest fix. Restore service first, then find the cause.
Learn. Write the postmortem and run a root cause analysis.

Where Sazabi Fits

Sazabi, an AI-native observability and security platform, opens an issue when it finds a problem in your logs. The issue carries the agent's analysis, and you can ask follow-up questions in its thread or hand it to your coding agent. That covers the detect and analyze steps. Containment, communication, and the review remain with your team and its process. For security-minded detection, see the security issues guide.

Frequently Asked Questions

What are the phases of the incident response lifecycle?

In NIST SP 800-61 Rev. 2 (2012) there are four: preparation, detection and analysis, containment, eradication, and recovery, and post-incident activity. Rev. 3 (April 2025) supersedes it and organizes incident response around the CSF 2.0 Functions instead.

Did NIST replace the four-phase incident response model?

Yes. Rev. 3 supersedes Rev. 2 and drops the circular four-phase model. It treats Detect, Respond, and Recover as incident response itself, with Govern, Identify, and Protect as broader risk management that supports it. NIST also says organizations should use whichever model suits them best.

Is the incident response lifecycle only for security incidents?

NIST SP 800-61 is about cybersecurity incidents. The same shape of detect, respond, recover, and learn applies to reliability incidents, and Google's incident response material covers operational outages.

What happens after an incident is resolved?

Review it. NIST Rev. 2 calls for a lessons learned meeting within several days of the end of a major incident, and Rev. 3 says lessons should often be shared as soon as they are identified instead of waiting for recovery to finish.

Sources

Detect and investigate incidents with Sazabi