An Incident Response Plan That Works
When an intrusion is confirmed, containment usually comes down to a single decision: take the affected production system offline, or leave it running and accept the risk that the compromise spreads. What slows most organizations at that moment is not the technical difficulty of the choice but the absence of a clear owner for it. The analyst who found the activity often lacks the authority to disconnect a production system, the manager who holds that authority may be unreachable, and the plan itself rarely names who acts in their place.
An incident response plan is the documented set of procedures an organization uses to detect, contain, and recover from a security incident. That definition describes what the document contains, not whether it will hold up under pressure. A plan that works is defined instead by its decision rights and its handling of the first hour: who can pull a system offline, who formally declares an incident, who notifies the regulator, and who speaks for the company. Those assignments need to exist in writing before anything happens, rather than being negotiated while systems are already being encrypted.
The first hour is three decisions
The first hour of a breach is spent making decisions rather than following a checklist. The first is whether an incident has occurred at all, which CISA's response playbooks describe as deconfliction: confirming that an alert reflects a real intrusion and not an administrator running a scheduled job. A wrong call in either direction means either ignoring a live attacker or halting production over a false alarm. The second decision is scope, covering what the attacker touched and what level of access they managed to obtain. The third is containment, covering what comes offline and when. Each of those calls should sit with one named person who has a designated backup for the hours they cannot be reached.
Roles decide who acts, not who attends
Incident response roles assign who leads the response, who investigates, who communicates externally, and who authorizes each containment action. Most organizations can produce a document that lists all of these, yet the same organizations discover under pressure that the incident commander is traveling, that legal was never briefed on breach-notification thresholds, and that no one is certain whether the chief executive or the communications lead should speak first. Deciding those handoffs in advance, and rehearsing the escalation path until it reliably reaches someone with the authority to act rather than someone who only forwards the alert, is what separates a staffed plan from a workable one.
A plan that works is measured by decision rights, not by the completeness of its lifecycle diagram.
Why NIST moved governance to the front
NIST SP 800-61 Revision 3, published in April 2025, reorganizes incident response around the six functions of the Cybersecurity Framework 2.0. It retires the earlier four-phase lifecycle and treats Govern, Identify, and Protect as continuous preparation, with Detect, Respond, and Recover forming the live response. The change carries real weight, because it places governance and readiness ahead of the response steps, which is precisely where most plans come apart. SANS retains its tactical six-step sequence, Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned, for handlers who need a running order at the keyboard. The two fit together well: NIST gives the program its governance structure, and SANS gives the responder a sequence to work through during the incident itself.
Run the plan without its author
The question worth asking is not whether an incident response plan exists but whether the team can run it when the person who wrote it is unreachable. A practical way to test that is to hand the runbook, cold, to an analyst who had no part in writing it, and to measure how long it takes them to reach someone who can authorize a disconnection. When that takes longer than a few minutes, the weakness lies in the decision rights rather than in the documentation, and adding further detail to the diagram will not resolve it. The work that genuinely improves a plan is settling the names, and the authority attached to them, well before they are needed.
Sources
National Institute of Standards and Technology, "SP 800-61 Revision 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile" (April 2025). https://csrc.nist.gov/pubs/sp/800/61/r3/final
Cybersecurity and Infrastructure Security Agency, "Federal Government Cybersecurity Incident and Vulnerability Response Playbooks." https://www.cisa.gov/resources-tools/resources/federal-government-cybersecurity-incident-and-vulnerability-response-playbooks
SANS Institute, "Incident Handler's Handbook." https://www.sans.org/white-papers/33901
Disclaimer
This article is provided for general informational and educational purposes and does not constitute legal, regulatory, or professional security advice. Incident response obligations, breach-notification timelines, and reporting thresholds vary by jurisdiction, sector, and contract. Verify any requirement against the current primary source and consult qualified counsel and advisers before acting. Framework references reflect the versions current at the time of writing.
Incident Response
Questions worth settling before an incident
An incident response plan is a documented set of procedures an organization uses to detect, contain, and recover from a security incident. In practice, the plans that hold up under pressure are the ones that assign decision rights in advance rather than the ones with the most detailed lifecycle diagram.
The common incident response phases are preparation, detection and analysis, containment, eradication, recovery, and post-incident review. NIST SP 800-61r3 now maps these to the six Cybersecurity Framework functions, while SANS keeps them as a tactical six-step sequence for handlers at the keyboard.
In the first hour of a breach, an organization makes three decisions: confirming that the alert is a real incident, establishing what the attacker touched and their level of access, and deciding what to take offline and when. Each of those calls should sit with one named person, supported by a backup, so the response does not stall waiting for approval.
Incident response roles assign who leads the response, who investigates, who communicates externally, and who authorizes each containment action. The failure point is rarely the role list itself but the handoffs, so the escalation path should be rehearsed until an out-of-hours alert reliably reaches someone with the authority to act.
Yes. NIST SP 800-61 Revision 3, published in April 2025, is the current federal guidance and organizes incident response around the six functions of the Cybersecurity Framework 2.0. It supersedes Revision 2 and places governance and preparation ahead of the live response steps.
