Published October 22, 2026
What the plan is now
NIST published SP 800-61 Revision 3 in April 2025. It supersedes Revision 2 from August 2012, the source of the familiar four-phase cycle: preparation; detection and analysis; containment, eradication and recovery; post-incident activity.
Revision 3 is a full rewrite, organized as a Community Profile of the NIST Cybersecurity Framework (CSF) 2.0. NIST released CSF 2.0 on February 26, 2024. It has six Functions: Govern, Identify, Protect, Detect, Respond and Recover. Govern is new.
NIST now treats Detect, Respond and Recover as the response itself, and Govern, Identify and Protect as the preparation that supports it. Lessons learned feed the Improvement Category of Identify at any point, not only after recovery. NIST's reason: recovery now often takes weeks or months.
Revision 3 no longer gives step-by-step handling procedures. NIST says those change too often to keep in one publication. The procedures are yours to write.
What the plan has to decide
A plan is a set of decisions made in advance: who declares an incident, who can shut down a system, who decides on disclosure, and who calls outside help.
NIST SP 800-61r3 lists what most incident response policies contain: management commitment, purpose and scope, definitions, roles, responsibilities and authorities, prioritization and severity guidelines, and performance measures. Its example authority: which roles may confiscate, disconnect or shut down technology assets.
Keep the plan short enough to use. Put the procedures for each incident type in playbooks and point to them from the plan.
Roles and who holds them
| Role | What it does in an incident | Settle in the plan |
|---|---|---|
| Leadership | Oversees the response, funds it, and may decide high-impact actions such as shutting down or rebuilding critical services. | Who can approve a shutdown, and at what hour |
| Incident lead | Leads one incident. NIST suggests naming one per incident and says the lead is often responsible for safeguarding its records. | Who is eligible, and the backup |
| Incident handlers | Verify the incident, collect evidence, contain, find root cause and restore. On staff, on contract, or called in. | Which are internal and which come from a provider |
| Legal | Reviews the plan for legal compliance, reviews supplier contracts, and advises on incidents with legal consequences such as prosecution or lawsuits. | Inside or outside counsel, and when they join |
| Public affairs | Informs the media and, through it, the public when an incident calls for it. | Who approves external statements |
| Human resources | Joins when an employee is suspected. | When HR is notified |
| Asset owners | Set response and recovery priorities for their systems. | An owner for each critical system |
The roles come from NIST SP 800-61r3 Section 2.2. Name people and alternates in a contact list kept outside the plan, so the plan does not change each time someone leaves.
The order of the work
- Set scope and definitions. Define an incident for your organization and the criteria for declaring one. NIST's Detect outcome DE.AE-08 is that incidents are declared when adverse events meet the defined incident criteria.
- Name roles and authorities. Fill the table above with people and alternates, including who may take systems offline.
- Define severity levels. Base them on risk factors, not arrival order. NIST lists examples: asset criticality, functional impact, data impact, stage of activity, threat actor and recoverability. Tie each level to who is notified and who joins.
- Write the legal and disclosure path. List every notification duty that applies, the owner of each, and who decides materiality if you are a public company.
- Write playbooks for the likely incidents. Start with the incident types you are most likely to see, and the procedures you would need urgently, such as rebuilding your primary authentication platform.
- Set up evidence handling. Decide how actions are logged and how data is collected and retained.
- Put retainers and contracts in place. Incident response provider, outside counsel, and the incident terms in cloud and managed service contracts.
- Test it. Run a tabletop exercise, record what failed, and fix the plan.
What takes longer than expected
- Agreeing on authority. Who may shut down a revenue system is a business decision.
- The disclosure path. Legal, finance and the security team have to agree who decides materiality and on what facts. That needs meetings, not drafting.
- Third-party terms. Cloud and managed service providers hold part of the response. NIST says those responsibilities, including information flows and the provider's authority to act for you, should be defined in the contract.
- Playbooks that match the real environment. A generic ransomware playbook does not say how to isolate your network segments or restore your identity system. Writing that needs the engineers who run those systems.
The detail plans leave out
- Out-of-band communications. If email, chat or identity systems are compromised, the response cannot run on them. Decide the fallback channel and test it.
- Evidence handling. NIST says formal chain-of-custody procedures may not be used for every incident, but collected incident data is still evidence. Retain it under your evidence preservation and data retention policies, and consider the cost of keeping the hardware and software needed to read it later.
- The response record. NIST outcome RS.AN-06: actions taken during an investigation are recorded, and the records' integrity and provenance are preserved. Restrict access to them.
- Watching the attacker. Redirecting an attacker to a sandbox to monitor them and gather evidence delays containment and eradication. NIST says to discuss it with the legal department first.
- Recovery criteria. Write down when recovery starts, and account for the disruption recovery itself causes.
- Reports from outside. NIST recommends a way for third parties to report incidents involving you, and that those reports are monitored.
Disclosure, notification and retainers
SEC registrants. Form 8-K Item 1.05 requires disclosure of a cybersecurity incident the company determines to be material. The company must make that determination without unreasonable delay after discovery, then file generally within four business days of it. The filing describes the material aspects of the incident's nature, scope and timing, and its material or reasonably likely material impact. Disclosure may be delayed if the U.S. Attorney General determines it would pose a substantial risk to national security or public safety and notifies the SEC in writing.
In May 2024, the SEC's Division of Corporation Finance said Item 1.05 is for incidents determined to be material. It encouraged companies to disclose other incidents under a different item, such as Item 8.01. The plan should name who makes the materiality call and how the security team gets facts to them.
Breach notification. All US states, the District of Columbia, Puerto Rico and the US Virgin Islands have breach notification laws, according to the FTC. HIPAA: notify affected individuals without unreasonable delay and within 60 calendar days of discovering a breach. GDPR Article 33: notify the supervisory authority within 72 hours of becoming aware of a personal data breach, where feasible. NIS2: an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours, and a final report within one month of the notification. List every duty that applies, including contract terms, with an owner for each.
CIRCIA. Under the Cyber Incident Reporting for Critical Infrastructure Act of 2022, covered entities will report covered cyber incidents to CISA within 72 hours of reasonably believing one occurred, and ransom payments within 24 hours of paying. As of October 2026, CISA says it is still working on the final rule, and reporting is not required until the rule takes effect. CISA encourages voluntary reports now at report@cisa.gov.
Retainers. Sign them before you need them. If you have cyber insurance, check whether the policy requires approved firms and when the insurer must be notified.
Skills and operations
NIST recommends periodic evaluation of the program through self-assessments, third-party assessments or audits, and exercises run with suppliers and other third parties. CISA publishes Tabletop Exercise Packages with scenarios, discussion questions and an after-action report template.
Update the plan after every exercise and every real incident. NIST says lessons should often be shared as soon as they are identified, not held until recovery ends. Give the plan one owner and a review date.
Settle these first
- Who can declare an incident, and who can shut down a production system?
- Which notification laws and contract terms apply, and who owns each?
- Which incident response firm and outside counsel are on retainer, and does your insurer approve them?
Questions
- Has NIST SP 800-61 Revision 2 been replaced?
- Yes. Revision 3 superseded it in April 2025. It organizes incident response around the six CSF 2.0 Functions instead of the four-phase life cycle.
- How long does a public company have to disclose a material cyber incident?
- Form 8-K Item 1.05 is due generally within four business days after the company determines the incident is material. The materiality determination must be made without unreasonable delay after discovery.
- Is CIRCIA reporting required yet?
- No. As of October 2026, CISA says it is still working on the final rule, and reporting is not required until the rule takes effect.