The 2026 Incident Response Playbook for CISOs

Most incident response plans fail the moment a real incident starts — not because the plan is wrong, but because no one practiced it under pressure. This playbook distills what actually works, extracted from 150+ real C-Suite tabletop exercises and dozens of live incidents.

When a ransomware note lands on your CFO's laptop at 2:47 AM, nobody opens the 80-page IR plan. They call whoever they think is in charge, start a Zoom bridge, and begin arguing about whether to pay. This playbook exists to replace that chaos with a repeatable command structure.

It follows the six phases defined in NIST SP 800-61 Rev. 2 — Preparation, Detection & Analysis, Containment, Eradication, Recovery, and Post-Incident Activity — but with the operational detail that only comes from running scenarios with real executives at the table.

Phase 1: Preparation (What You Do Before the Incident)

Preparation is the only phase you get to do calmly. Every hour spent here saves five during an actual incident. The goal of preparation is not a binder — it is a trained team with pre-authorized decisions.

The six roles every incident needs

Before anything else, assign these six roles and name backups for each. See our detailed breakdown in Incident Command Roles: Who Does What.

• Incident Commander — owns the decisions and the timeline. Not necessarily the most senior person.
• Scribe — maintains the defensible record. Every decision, every notification, every timestamp.
• Communications Lead — drafts internal, customer, and regulator messaging.
• Legal Liaison — owns privilege, notification decisions, and law enforcement contact.
• Technical Lead — directs containment, forensics, and recovery engineering.
• Executive Sponsor — unblocks resources, approves cross-functional action, briefs the board.

Pre-authorized decisions

The decisions that cost you the most time in an incident are the ones you should never be making in an incident. Pre-authorize them now:

• Who can isolate a production system without additional approval?
• Who can take the website offline?
• Who decides to engage outside counsel?
• Who decides to notify the cyber insurer? (Hint: the insurer usually requires first notice within 24 hours.)
• Who decides to contact the FBI?
• Who signs the SEC 8-K or the GDPR notification?

Retainers and contracts signed in advance

You cannot negotiate a $500/hour forensics retainer at 3 AM on a Saturday. Before you need them, have signed master services agreements with:

1. Incident response / digital forensics firm (DFIR)
2. Outside cybersecurity counsel (for privilege)
3. Crisis communications firm
4. Ransom negotiation firm (even if you swear you'll never pay)
5. Notification / breach response vendor (for mass consumer notification)

Phase 2: Detection and Analysis

Detection is where most organizations have invested the most money — SIEM, EDR, XDR, MDR — and where the playbook has the least to add. The playbook's job starts the moment an alert is escalated from "potential" to "confirmed incident."

The triage decision tree

When an alert arrives at the IR team, the on-call analyst needs a fast, boring decision tree. Not a wiki page. Four questions:

1. Is this confirmed malicious activity? (Not just anomalous.)
2. Does it touch regulated data or critical systems?
3. Is it still active?
4. Is the blast radius more than one host?

Two or more "yes" answers triggers the formal IR activation. Below that threshold it stays with the SOC.

The clock you cannot stop

The moment you classify an event as a confirmed incident, multiple regulatory clocks begin. You do not get to decide when they start — the regulation decides. See our deep dives on SEC 96-hour notification and GDPR 72-hour notification.

Phase 3: Containment

Containment is where good plans go to die. The pressure is maximum, the information is incomplete, and every option has irreversible consequences. The playbook's job here is to force deliberate trade-offs instead of panic reactions.

Short-term vs. long-term containment

Short-term containment stops the bleeding — isolate the host, kill the process, block the C2 domain. Long-term containment rebuilds the environment so the adversary cannot simply re-enter. Teams that conflate the two either act too slow (because they are debating the rebuild) or too fast (because they skipped the rebuild entirely).

The "pull the plug" debate

In ransomware incidents specifically, the first 30 minutes almost always contain the same argument: should we disconnect everything from the network right now? The answer depends on two factors the playbook should make explicit:

• Encryption velocity. If the encryptor is still running, disconnect. Every minute costs systems.
• Forensic volatility. If you pull power you lose memory. If you pull network you usually keep it.

Our specific guidance for ransomware is in Ransomware Response: The First 24 Hours.

Phase 4: Eradication

Eradication removes the adversary's persistence mechanisms. This is not the same as "restoring service" — that comes next. The common failure mode here is declaring eradication complete before you understand how the adversary got in.

Eradication is not complete until you can answer, in writing:

1. How did they get initial access?
2. How did they escalate privileges?
3. How did they move laterally?
4. What persistence mechanisms did they install?
5. Have all of the above been remediated on every affected host?

Phase 5: Recovery

Recovery brings systems back into production in a controlled sequence. The mistake most teams make is treating recovery as a single event ("we're back up") instead of a staged process with verification gates.

Recovery sequencing

1. Identity plane first. Clean AD, clean federation, rotated secrets, re-issued certificates.
2. Core infrastructure second. DNS, DHCP, file shares, backup targets.
3. Business-critical applications third. In priority order defined before the incident.
4. Everything else fourth.

Monitoring during recovery

Assume the adversary is still watching and will attempt to re-enter. Heightened monitoring — new SIEM rules, expanded logging, tripwire accounts — stays in place for at least 30 days after recovery.

Phase 6: Post-Incident Activity

The after-action review (AAR) is where the investment in the previous five phases actually compounds. Skip it and you will pay the same tuition on the next incident. See our template and guide at After-Action Reviews: From Incident to Improvement.

A defensible AAR includes:

• Executive summary (one page, no jargon)
• Full timeline from initial access to full recovery
• What worked — preserve these for next time
• Gaps identified with severity ratings
• SLA compliance (did you hit your own response times?)
• Regulatory notification status and evidence
• Prioritized remediation recommendations with owners and dates

The Defensible Record

Every phase above generates decisions, notifications, and evidence. If you cannot prove what you decided, when, and why — to a regulator, a plaintiff's attorney, or your own board — you effectively did not do it. That is why IR-OS records every event in a SHA-256 hash-chained, append-only ledger. Read the technical deep dive at The Defensible Record: Why IR Needs a Hash Chain.