What NIST SP 800-61 Rev. 3 changed
NIST published SP 800-61 Rev. 3, "Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile," in April 2025. It supersedes Rev. 2, the Computer Security Incident Handling Guide published in August 2012.
Rev. 2 described a circular life cycle: preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity. Rev. 3 explains that incidents now happen more often, cause more damage, and can take weeks or months to recover from, so incident response is better treated as part of cybersecurity risk management across the organization.
The new model uses the six CSF 2.0 Functions. Govern, Identify, and Protect are broader risk management activities that also prepare you for incidents; Detect, Respond, and Recover are incident response itself; and Improvement (ID.IM) connects them all. NIST also says organizations should use whichever life cycle model fits them, and it points to online resources for step-by-step detail rather than keeping it in the publication.
What an incident response plan should include
Write the plan so that no one has to invent roles, thresholds, or approvals in the middle of an incident. NIST SP 800-61 Rev. 3 lists common policy elements, including definitions of events and incidents, roles and authorities such as who may disconnect or shut down technology assets, and guidelines for prioritizing incidents and estimating their severity.
The table maps each part of the plan to the CSF 2.0 category that describes the outcome. Behind the plan sit procedures, and many organizations write those as playbooks for the incident types they are most likely to face, such as ransomware, a compromised account, a lost laptop, or an incident at a key vendor.
Keep a current contact list for everyone the plan names, inside and outside the organization, and a way to reach them if email or chat is unavailable.
| Part of the plan | What to decide in advance | CSF 2.0 category |
|---|---|---|
| Roles and decision rights | Who leads, who can declare an incident, and who can approve shutting down systems or bringing in outside help | Incident Management (RS.MA) |
| Severity and escalation | How reports are triaged, validated, categorized, and prioritized, and what triggers escalation to leadership | Incident Management (RS.MA) |
| Investigation and evidence | How analysis establishes what happened and the root cause, and how records and incident data keep their integrity and provenance | Incident Analysis (RS.AN) |
| Containment and eradication | Actions pre-approved to contain and eradicate an incident, and who may take them | Incident Mitigation (RS.MI) |
| Communications | Who notifies internal and external stakeholders, and what information is shared with whom | Incident Response Reporting and Communication (RS.CO) |
| Recovery | When recovery starts, how backups are verified before use, how restored systems are checked, and who declares recovery complete | Incident Recovery Plan Execution (RC.RP) |
| Recovery communications | How progress in restoring operations is reported to the people who need it | Incident Recovery Communication (RC.CO) |
| After-action improvement | How lessons become changes to the plan, procedures, and controls | Improvement (ID.IM) |
Counsel, insurers, regulators, and other outside parties
Some of the hardest calls in an incident involve people outside the security team. NIST SP 800-61 Rev. 3 names leadership, legal, public affairs, human resources, asset owners, and third parties among the roles that matter, so the plan should say when each one is brought in and who decides.
- Legal counsel: when counsel is engaged, what counsel directs, and how decisions about notifications are made and recorded.
- Cyber insurance: read your policy for notice deadlines, any requirement to get consent before hiring outside firms or incurring costs, and any approved vendor list, then write the claim steps into the plan.
- Regulators: which laws and contracts may require notice. For HIPAA covered entities and business associates, breach notification requirements are in 45 CFR Part 164, Subpart D; ask counsel which other federal and state requirements apply to you.
- Law enforcement: who decides whether and when to contact law enforcement, and who makes that contact.
- Customers and vendors: which contracts require you to notify customers, and what your vendors must tell you and when.
- Outside help: who can engage an incident response firm, under what terms, and how to reach them outside normal channels.
Testing the plan with a tabletop exercise
A cybersecurity tabletop exercise shows whether the plan works before an incident does; NIST SP 800-84 calls tabletops cost-effective tools for validating plans such as incident response plans. It describes them as discussion-based events: people with roles in the plan meet, a facilitator presents a scenario and asks questions, and the discussion tests roles, responsibilities, coordination, and decision-making without deploying any equipment.
NIST SP 800-84 walks through designing, developing, conducting, and evaluating the exercise. It notes that tabletops typically run two to eight hours, depending on the audience, the topic, and the objectives, and that short, concise scenarios often work better than long, detailed ones.
Immediately afterward, the facilitator leads a debrief, often called a hotwash, asking where participants did well, where they need training, and which parts of the plan should change. The after action report then records the purpose, objectives, participants, and scenario, the observations made during the exercise, and recommendations for improving the plan.
- Set objectives first: what decision or capability should this exercise test?
- Pick a realistic scenario and write injects: new developments or questions the facilitator adds as the scenario unfolds.
- Invite the people the plan names, including decision-makers, not only technical staff.
- Assign a facilitator and someone to record observations against criteria agreed in advance.
- Hold the debrief right away, then write the after action report while memories are fresh.
Scenario ideas from CISA's exercise packages
CISA Tabletop Exercise Packages give organizations material to run their own exercises: template objectives, scenarios, discussion questions, and references, plus templates for invitations, slides, feedback forms, and after action reports. Cybersecurity scenarios in the collection include ransomware, phishing, and insider threats.
A ransomware tabletop makes a strong starting point because it touches every part of the plan at once: detection, containment, communications, legal and insurance decisions, and recovery from backups.
Turning the after action report into improvements
An exercise only pays off if its findings change something. CSF 2.0 captures this in its Improvement category: improvements are identified from security tests and exercises, including those done with suppliers and relevant third parties (ID.IM-02), and incident response plans are established, communicated, maintained, and improved (ID.IM-04).
NIST SP 800-61 Rev. 3 adds that lessons learned should often be shared as soon as they are identified, not held until recovery ends. The same applies to exercises: if the tabletop shows that no one knows who can approve taking a customer-facing system down, fix that this week.
- Turn each recommendation into an action item with an owner and a due date.
- Update the plan, playbooks, and contact list, and record the version and date.
- Track actions to closure, and report open items to leadership.
- Test the fixes in the next exercise, ideally with a different scenario.
How often to review and exercise the plan
NIST SP 800-84 advises conducting tabletop exercises periodically, after organizational changes or updates to the plan, when new guidance is issued, and as otherwise needed. CISA's #StopRansomware Guide likewise advises creating, maintaining, and regularly exercising a basic cyber incident response plan.
Under HIPAA today, security incident procedures are a standard with a required specification for response and reporting (45 CFR 164.308(a)(6)), and contingency plans include testing and revision procedures as an addressable specification (164.308(a)(7)). HHS's January 2025 proposed rule would require reviewing and testing security incident response plans at least once every 12 months; as of September 27, 2026, that proposal has not been finalized or withdrawn.
PCI DSS, SOC 2 examinations, cyber insurance policies, and customer contracts can each set their own expectations for incident response. Read the current text of each one that applies to you and plan to the strictest.
- After a significant change: a new core system, a cloud migration, an acquisition, or a new vendor that holds critical data.
- After changes in key people, such as a new incident lead, general counsel, or head of communications.
- After every real incident, however small.
- On a regular schedule, varying the scenario each time.
Incident readiness versus incident response
Writing the plan, building playbooks, and running tabletop exercises are readiness work, done before anything goes wrong. Responding to an active incident is a separate capability: the people and providers who investigate, contain, and recover, working with your counsel and your insurer.
Decide in advance who would do that work for you. NIST SP 800-61 Rev. 3 notes that incident handlers can be on staff, on contract, or available when needed from a provider, a partner, or law enforcement, and that responsibilities shared with service providers should be clearly defined in a contract. Choosing that help calmly, and writing it into the plan, is itself part of readiness.