Incident Response Plans After NIST SP 800-61 Rev. 3: Roles, Priorities, Escalation and Exercises

Almost every security team has an incident response plan. Far fewer have one that people can actually follow at 3 a.m., with the CEO on the phone and half the information missing. The difference is rarely the length of the document. It is whether the plan says who decides, what counts as an incident, how incidents are ranked and when to escalate, and whether anyone has ever rehearsed it.

In April 2025 NIST published SP 800-61 Revision 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management. It supersedes Revision 2, the 2012 Computer Security Incident Handling Guide that shaped most of today's plans. This article explains what changed and turns it into a practical checklist for your own plan.

What changed: from a four-phase cycle to the whole CSF

Revision 2 described a life cycle in four phases: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. Revision 3 replaces it with a model built on the six Functions of the NIST Cybersecurity Framework (CSF) 2.0: Govern, Identify, Protect, Detect, Respond and Recover. In NIST's words, the six Functions "all play vital roles in incident response."

The new model has two layers:

• Preparation: Govern, Identify and Protect. These are not the response itself, but they prevent some incidents and prepare you to handle the ones that happen.
• Response: Detect, Respond and Recover. This is the incident response in the strict sense.

Between them sits Improvement, part of Identify. Lessons learned from every Function feed into it, not just from a post-incident meeting at the very end.

NIST also explains why the old picture no longer fits. The circular model reflected a time when incidents were treated as occasional events and response and recovery were often finished within a day or two. Today, response is a continuous activity woven into normal operations.

Who does what

A plan that only names the SOC is incomplete. Revision 3 describes roles well beyond the technical team:

• Leadership oversees incident response, allocates funding and may need to make high-impact decisions, such as shutting down a critical service.
• Legal reviews plans, policies and procedures for compliance with applicable laws, and reviews contracts with third parties.
• Public affairs handles communication with the media and, through them, the public. Having a media strategy before you need it helps.
• Third parties, such as an MSSP or a cloud provider, share responsibility. What they can and cannot do during an incident should be written into the contract.

Write these names down, with deputies. The worst moment to discover that nobody can authorize taking a server offline is during the incident.

What counts as an incident, and what comes first

Two decisions shape every response, and both belong in the plan before anything happens.

Declaring an incident

NIST recommends declaring an incident only after applying defined incident criteria to what was detected, taking known false positives into account. Without criteria, every alert becomes a debate, or worse, nothing is ever formally declared and nobody owns it. This is also where alert fatigue hurts most: the more noise reaches the team, the slower the real incidents get declared.

Prioritizing incidents

Revision 3 is blunt: because resources are limited, incidents should not be handled first-come, first-served. Triage, prioritization, escalation and recovery decisions should rest on a set of risk factors, such as:

• Criticality of the affected assets.
• Functional impact on the business.
• Recoverability: how hard it is to get back to normal.

Define these factors and a simple scale in advance, so two analysts looking at the same incident give it the same priority.

Escalation is not the same as elevation

NIST makes a useful distinction. Escalation generally means increasing the resources or the time frames assigned to an incident. Elevation means involving higher levels of management. Your plan needs triggers for both: for example, an incident on a business-critical system escalates to more responders, while one that may require public disclosure or a regulatory notification elevates to leadership and legal.

Put concrete thresholds in writing. "Escalate if needed" is not a rule; "escalate when an incident affects a production system in the payments chain" is.

Playbooks: the plan in steps

The plan sets the rules; playbooks turn them into steps. NIST describes playbooks as actionable steps or tasks for people to perform in specific scenarios. Start with the incident types you actually see most: phishing that leads to a compromised account, ransomware on an endpoint, leaked credentials, an exploited internet-facing system.

A good playbook answers, for one scenario: how to confirm it, how to contain it, who to call, what evidence to keep and when it is over. It should fit on a few pages.

Rehearse it: tabletop exercises

A plan nobody has tested is a hypothesis. NIST notes that incident response exercises and tests provide useful information for evaluating the program, and points to SP 800-84 for tabletop exercises and simulations.

You do not need to build one from scratch. CISA Tabletop Exercise Packages (CTEPs) include template scenarios, discussion questions, role templates and an after-action report template, with cyber scenarios such as ransomware, insider threats and phishing. An hour around a table with IT, legal, communications and leadership usually reveals more gaps than a year of reviewing the document.

Learn while it happens, not only afterwards

Revision 3 recommends sharing lessons learned as soon as they are identified, rather than waiting for recovery to finish. Afterwards, follow-up reports and lessons-learned meetings remain the main source of improvements, and NIST recommends an after-action report covering the incident, the response and recovery actions, and what was learned.

The most valuable lesson is often technical: the vulnerability or misconfiguration that let the attacker in. Feed it straight back into remediation, so the same weakness on similar assets is fixed too. We cover that loop in closing the loop between the SOC and vulnerability management.

Checklist for your plan

• Named roles, with deputies: leadership, legal, communications, third parties.
• Written criteria for declaring an incident.
• A priority scale based on asset criticality, functional impact and recoverability.
• Escalation and elevation triggers with concrete thresholds.
• Playbooks for your most common incident types.
• Business continuity plans synchronized with the incident response plan, as NIST recommends.
• At least one tabletop exercise a year, with an after-action report.
• A path from lessons learned to remediation.

Frequently asked questions

Is Revision 2 obsolete? NIST has formally superseded it. Its four phases still map onto the new model, so an existing plan is a starting point, not something to throw away.

Do small teams need all of this? The structure scales. A small team may cover several roles with one person, but the decisions (criteria, priorities, escalation) still need to be written down.

How often should we test? NIST does not set a fixed frequency; it asks you to review plans periodically and use exercises to evaluate the program. Test after major changes and at least on a regular schedule you can sustain.

How priorIQ.ai helps

SentinelIQ adds an AI triage layer on top of the SIEM or XDR you already run, such as Microsoft Sentinel, Splunk, Elastic, QRadar or Wazuh. It enriches and triages alerts, suppresses false positives and surfaces only confirmed incidents, so your declaration criteria are applied to signal rather than noise. Its incident history is indexed and searchable, which helps when you write the after-action report. Confirmed incidents raise remediation priority in PriorIQ Core: if a host is under attack, its vulnerabilities move up the queue, and the work lands as tickets in Jira, ServiceNow or Freshservice. Request a demo.