Skip to content
WorakornKoonawootrittriron
Back to blog
Network security

NIST SP 800-61r3 incident response: a phase-by-phase checklist

NIST SP 800-61r3 recasts incident response as a CSF 2.0 profile. What changed from r2, plus the questions to ask before, during and after an incident.

Intermediate10 min read

On this page
  1. Why the update matters
  2. Before: preparation (Govern, Identify, Protect)
  3. Detect and analyse: triage questions
  4. Contain, eradicate, recover: decisions that trade speed for evidence
  5. Communicate: who needs to know, when, and in what words
  6. After: lessons learned that actually change something
  7. Using CISA's playbooks as a reference structure

Most of us learned incident response as a four-step circle: prepare; detect and analyse; contain, eradicate and recover; then hold a post-incident review. That circle came from NIST's Computer Security Incident Handling Guide, SP 800-61 Revision 2, published in August 2012. In April 2025 NIST replaced it with SP 800-61 Revision 3, and the new version looks quite different. It is no longer a handling guide at all. It is a CSF 2.0 Community Profile: incident response described in the vocabulary of the NIST Cybersecurity Framework 2.0.

I like checklists because they still work at 3 a.m., when nobody is at their best. So this post does two things. First, it explains briefly what changed and why. Then it walks through each phase as a short list of questions you can copy into your own runbook and adapt. The questions are my wording. The ideas behind them come from the NIST profile and from CISA's public playbooks, and I link to the exact source for each point.

Why the update matters

NIST gives a candid reason for dropping the old circle. In 2012, it says, incidents were relatively rare and narrow, and response was usually finished within a day or two. Today incidents happen often, do far more damage, and recovery "often takes weeks or months" (SP 800-61r3, section 2.1). A separate team that springs into action now and then, and writes its lessons up at the very end, no longer matches reality.

The new model uses the six functions of CSF 2.0, which NIST released on 26 February 2024 with a new Govern function added to the original five:

CSF 2.0 function Role in the r3 model Old r2 phase it maps to
Govern, Identify, Protect Preparation (broader risk management that also supports response) Preparation
Detect Incident response Detection & Analysis
Respond, Recover Incident response Containment, Eradication & Recovery
Identify: Improvement (ID.IM) Lessons learned, fed into every function Post-Incident Activity (and part of the detection and response phases)

That mapping is NIST's own (Table 1 in the PDF). The big idea is the middle layer: lessons learned are not a final phase any more. Lessons from any function go into Improvement and come back out to all of them, and NIST says they should often be shared "as soon as they are identified, not delayed until after recovery concludes" (SP 800-61r3).

The r3 model: Detect, Respond and Recover on top, Improvement in the middle, preparation underneath. A lesson can drop back into preparation at any time.

Two more changes are worth knowing about:

  • Less procedure, more pointers. NIST says the details of how to respond change too often to keep in one static document. For implementation details, NIST points readers to its Incident Response project page and to mappings in its online Cybersecurity and Privacy Reference Tool (CPRT).
  • NIST doesn't force its own model on you. The document says plainly that organisations should use whichever life-cycle model suits them best. What matters is that incident response is considered throughout risk management.

So if your runbook still says "Phase 1 to Phase 4", you don't need to throw it away. But it is worth checking whether lessons learned only flow back at the end.

Before: preparation (Govern, Identify, Protect)

In the profile, most preparation rows are about general risk management, but a few are directly about incidents. These are the questions I would ask while things are quiet:

People and authority

  • Is there an incident response policy, and does it say who may disconnect, confiscate or shut down systems? (NIST lists exactly that as a key policy element.)
  • Do we know who the incident lead is for a given incident? NIST suggests designating one per incident (RS.MA-01).
  • Are legal, public affairs, human resources, facilities and asset owners on the contact list, not only the security team? NIST names all of these as incident response roles.
  • If a provider (an MSSP, a cloud or internet provider) does part of the work, does the contract say what they may do on our behalf and what they may not?

Visibility

  • Do we have current, automatically updated inventories of hardware, software and services, plus an inventory of our data and where it lives (ID.AM-07)? Responders use them to judge impact and to find other assets that may be targeted (ID.AM).
  • Are logs generated and collected centrally? NIST calls logs "particularly important" for detection, response and recovery (PR.PS-04), and CISA's playbook asks for logs to be collected centrally.
  • Do we know what "normal" looks like? CISA's playbook asks defenders to define baselines before an incident, so that deviations stand out.

Plans that will actually run

  • Are backups created, protected and tested (PR.DS-11)? CISA's ransomware guidance repeats this: keep offline, encrypted backups and test them regularly.
  • Is the business continuity plan synchronised with the incident response plan (ID.IM-04)?
  • Do we have an out-of-band way to talk if email or chat is compromised? CISA recommends separate channels such as phone bridges, and warns against notifying users of compromised machines by email.
  • Have we exercised any of this? Tabletops and tests are a source of improvements in their own right (ID.IM-02).

Detect and analyse: triage questions

NIST's Detect function covers monitoring and adverse event analysis, ending in a decision: is this an incident or not? The profile is realistic about volume. It says organisations should rely on technical tools to filter event data down to something a human can review (DE.AE).

When an alert or a report arrives, I'd work through these:

  • Is it real? Do a preliminary review to verify that an incident has occurred, then estimate severity and urgency (RS.MA-02). CISA adds a useful check: deconflict with authorised activity. Is this just an administrator using remote tools for updates?
  • Does it meet our incident criteria? Declare an incident when the analysed activity meets defined criteria, and account for known false positives (DE.AE-08).
  • How bad, and how urgent? NIST says incidents should not be handled first come, first served. Prioritise on factors such as asset criticality, functional and data impact, the stage of the activity, the threat actor, and recoverability (RS.MA).
  • What type is it? Data breach, ransomware, account takeover, denial of service (RS.MA-03).
  • How far has it gone? Look for indicators of compromise and persistence on the targeted assets and on other likely targets. NIST warns that a superficial look leads to underestimating the incident (RS.AN-08).

CISA's playbook has a list of key questions that I find very practical. Paraphrased: how did the attacker get in, and how do they still get in? Are they exploiting vulnerabilities? How do they keep command and control, and do they have persistence? Which accounts are compromised, at what privilege level? Is lateral movement happening, and has data left the network?

Evidence handling

  • Are we writing down every action, with time, and protecting those records? NIST asks that the integrity and provenance of investigation records be preserved, and access limited to authorised people (RS.AN-06).
  • Are we collecting data before it disappears? CISA suggests memory and disk images when an endpoint needs forensic analysis, and a detailed log for all evidence.
  • Even if nobody will prosecute, are we treating collected data as evidence? NIST notes that formal chain of custody may not be used for every incident, but the data is still evidence (RS.AN-07).

Contain, eradicate, recover: decisions that trade speed for evidence

This is where the hardest judgment calls live. NIST says every response strategy decision has trade-offs, especially between returning to normal quickly and observing the attacker or investigating more thoroughly (RS.MA-03). CISA's playbook puts the same tension another way: be as complete as possible in finding the attacker's activity, while weighing the risk of letting them stay until the full scope is known.

Containment stops the spread at a boundary first; recovery then restores the hosts inside, one at a time, before the fence comes down.

Containment

  • What will this containment action break for the business, and for how long? CISA asks you to weigh mission impact, duration, resources, effectiveness, and the effect on evidence.
  • Is this an emergency workaround to remove within hours, a temporary one to remove within two weeks, or a permanent fix? NIST suggests thinking about the duration of each measure (RS.MI).
  • Have we captured forensic images before we wipe or isolate anything we may need later?
  • Are we about to tip off the attacker? CISA advises avoiding actions that reveal the response, for example submitting samples to a public analysis service.
  • Are we tempted to watch the attacker in a sandbox? NIST says to discuss that with legal first, because the delay can be dangerous (RS.MI).
  • If a host must go offline, are we disconnecting it from the network rather than powering it off? CISA's ransomware guide says to power down only if hosts can't be disconnected by other means, because shutting down loses infection artifacts and evidence held in volatile memory.

Eradication

  • Have we accounted for every means of persistent access before we start? CISA warns that attackers often hold several backdoors and can return to "clean" areas.
  • Have we found all affected hosts and services, so that every exploited weakness gets fixed (RS.MI-02)?
  • Are credentials, keys and service account secrets being rotated where compromise is suspected?

Recovery

  • Have we checked backups and other restoration assets for compromise and corruption before using them (RC.RP-03)?
  • Are services being restored in the right order, confirmed with system owners, and watched afterwards (RC.RP-04)?
  • Is the root cause fixed before a restored system goes back into production (RC.RP-05)?
  • What are our criteria for declaring recovery finished (RC.RP-06)?

Communicate: who needs to know, when, and in what words

NIST splits incident communication into four kinds, and keeping them apart helps a lot (RS.CO):

  1. Coordination: among the people actually working the incident.
  2. Notification: formally telling affected customers, staff, partners or regulators.
  3. Public communication: for example answering the media.
  4. Information sharing: usually voluntary, such as sharing observed techniques with a sector ISAC.

Questions for each incident:

  • Does our procedure say what must be reported to whom, and when, including the first notification and regular updates (RS.CO-02)?
  • Which notification laws and contracts apply to us? NIST points out that this area changes often, and that obligations depend on your sectors and on where you and your customers are.
  • Who is approved to contact law enforcement and regulators? NIST ties this to the plan and management approval.
  • Is senior leadership getting regular status updates on major incidents (RS.CO-03 and RC.CO-03)?
  • Does public messaging explain what is being done to recover and to prevent a repeat (RC.CO-04)?

After: lessons learned that actually change something

The old model's lessons-learned meeting is still there. NIST mentions follow-up reports and "lessons learned" meetings as a common source of improvements (ID.IM-03). The difference is what happens to the output. Improvements can go into the incident response plan itself, or into the rest of the security programme, such as attacker techniques that nothing currently blocks or detects.

  • Did we write an after-action report covering the incident, the response, the recovery and the lessons (RC.RP-06)?
  • Does every lesson have an owner and a target function? (Govern: policy. Identify: inventory. Protect: a control. Detect: a new detection.)
  • Did we add detections for the techniques that worked, and close the blind spots? CISA's post-incident step says exactly this.
  • Did past incidents feed into the next review of risk strategy (GV.OV-01)?
  • Did we share a lesson during the incident when it couldn't wait? The r3 model expects that.

Using CISA's playbooks as a reference structure

If you want a fuller template, the CISA Cybersecurity Incident & Vulnerability Response Playbooks are public and well organised. They were written under section 6 of Executive Order 14028 for US federal civilian agencies, so parts of them (reporting to CISA, major-incident definitions) won't apply to you. The structure still travels well. There is an incident response playbook with preparation, detection and analysis, containment, eradication and recovery, post-incident and coordination sections, plus a vulnerability response playbook and checklist appendices. NIST's r3 itself points to these playbooks as examples. Note that the CISA document (published November 2021) still follows the r2 phases, which is fine: the mapping table above translates between the two.

For ransomware specifically, StopRansomware.gov and its #StopRansomware Guide include a response checklist from CISA, MS-ISAC, NSA and the FBI.

My suggestion: take the questions above, delete the ones that don't fit, add your own contacts and tools, and run a one-hour tabletop with them. The first time through, the gaps you find are the most useful output. And under r3, writing those gaps down straight away is part of the lifecycle.

Sources

Keep reading

Related posts

Back to blog