What is Incident Response?

The four phases of Rev. 2

NIST's Computer Security Incident Handling Guide, SP 800-61 Rev. 2 (August 2012), drew incident response as a loop of four phases:

1. Preparation: the team, the tools, the contact lists and the playbooks, all in place before anything happens.
2. Detection and Analysis: an alert, a user report or a tip is validated, scoped and declared an incident.
3. Containment, Eradication and Recovery: stop the spread, remove the attacker's access, restore the systems.
4. Post-Incident Activity: the lessons-learned review, which feeds back into preparation.

Most articles on incident response phases still teach this model, and most auditors still recognize it. It is no longer NIST's guidance, though: NIST withdrew Rev. 2 on April 3, 2025, the day it published Rev. 3.

What Rev. 3 changed

Rev. 3 has a new title, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, and the document explains why the model changed. When Rev. 2 was written, incidents were relatively rare, narrow in scope and usually handled within a day or two, so a separate team running a circular process made sense. Now, NIST writes, incidents happen often, do far more damage and can take weeks or months to recover from. Incident response therefore has to be part of risk management across the organization, and lessons should be shared as soon as they are identified instead of waiting until recovery ends.

The new model is built on the six functions of the NIST Cybersecurity Framework (CSF) 2.0. The definitions below are NIST's, shortened:

NIST's figure has three levels. Govern, Identify and Protect sit at the bottom as preparation: wider risk management that supports incident response without being part of it. Detect, Respond and Recover at the top are the response itself. Improvement (ID.IM) sits in the middle and takes lessons from every function at any point, not only after recovery. NIST also says each organization should use whichever lifecycle model suits it; Rev. 3 chose CSF 2.0 because so many organizations already work with it.

Old phases, new functions and the SOC analyst's part

Table 1 of Rev. 3 maps each old phase to CSF 2.0 functions. The third column is ours: where a SOC analyst does the work, with the subcategory IDs NIST attaches to each task.

Rev. 3 also defines the terms you use at the console. Containment is "preventing the expansion of an incident". Eradication is "mitigating an incident's effects", which covers removing persistence, disabling breached accounts and fixing every exploited vulnerability. Recovery ends only when its end is declared against criteria and an after-action report records the incident, the actions taken and the lessons learned (RC.RP-06). And RS.MA-04 separates two words analysts tend to use interchangeably: escalation adds resources or time, elevation brings in a higher level of management.

One incident across the functions

Simulated example generated by SOCSimulator Research. Accounts and times are invented and the address comes from a documentation range. The right-hand column is the CSF 2.0 subcategory each step falls under.

09:12  SIEM alert: m.chen signs in from 198.51.100.77, new country          DE.AE-02
09:15  Same IP in sign-ins for 3 more users in the last hour                DE.AE-03
09:18  Threat intel: 198.51.100.77 is a proxy seen in phishing campaigns    DE.AE-07
09:24  m.chen creates an inbox rule moving "invoice" mail to RSS Feeds      DE.AE-08  incident declared
09:26  Tier 1 opens the incident, sets severity, pages the IR lead          RS.MA-02, RS.MA-04
09:31  Sessions revoked, passwords reset for m.chen and the 3 users         RS.MI-01
09:40  Timeline from SigninLogs and mailbox audit; every action logged      RS.AN-03, RS.AN-06
10:05  Search all mailboxes for the same rule and the same IP               RS.AN-08
10:30  Rules deleted, attacker's MFA method removed, sender domain blocked  RS.MI-02
11:15  Users confirm normal mail flow; accounts monitored for 7 days        RC.RP-04, RC.RP-05
Day 3  Review: detection fired 12 minutes after the first sign-in; tuned    ID.IM-03

The steps overlap, as Rev. 3 expects them to. The lesson recorded on day 3 (the detection was 12 minutes late) was visible at 09:15 and could have been shared then. Containment at 09:31 began before the analysis was finished because waiting would have cost more. NIST describes that as the core trade-off of every response strategy: getting back to normal quickly against watching the attacker or investigating more thoroughly (RS.MA-03).

SANS and other models

NIST's is not the only lifecycle in use. The SANS Incident Handler's Handbook (Patrick Kral, 2012) splits the same work into six phases, and many SOC runbooks follow it. Rev. 3 leaves the choice of model to you and asks only that incident response be considered throughout risk management. If your team or your auditor still works from the Rev. 2 phases, Table 1 is the translation.

Next steps

The incident response plan template turns the Rev. 3 functions into a plan you can fill in: roles and authority, severity levels, notification deadlines and a checklist per phase. For the analyst steps inside Respond, the investigation playbooks walk through specific alerts, from brute force to impossible travel, and the SOC playbook template shows how to write your own.