Cyber Incident Response Runbook
A cyber incident response runbook is the scenario-specific execution guide that turns the IR plan into action under stress. Where the IR plan is the strategic document, runbooks are the tactical procedures for a specific incident class: ordered steps, role assignments, decision gates, communication touch points, and regulatory clock triggers. This page covers runbook structure, the 10 essential runbooks for most organizations, the relationship between plan-runbook-playbook, and runbook software requirements.
Plan vs runbook vs playbook
The three documents serve different purposes and exist in different layers of the response architecture.
| Document | Layer | Purpose | Audience |
|---|---|---|---|
| IR Plan | Strategy | Policy, team structure, communication strategy, posture | Security committee, executives, board |
| Runbook | Tactics | Scenario-specific execution guide for a class of incident | Incident commander, response team |
| Playbook | Automation | Routine detection-phase steps automated through SOAR | SOC analyst, SOAR engineer |
The three coexist. The IR plan sets strategy. The playbook handles the routine steps that follow common detection patterns. The runbook is the scenario-specific tactical guide that drives the response phase. When a runbook calls for "log preservation," a playbook may execute the actual log capture. When a runbook calls for "draft GDPR Article 33 notification," an AI agent produces the draft. The runbook is the orchestration layer for the response.
What goes in a runbook
A good runbook follows a consistent structure across scenarios. The structure makes runbooks comparable, trainable, and stress-testable through tabletops.
- Scope and triggers. What incident class the runbook covers, the conditions that activate it, the conditions that hand off to a different runbook.
- Initial assessment with decision gate. The first 15-30 minutes of work to confirm classification and severity. Decision criteria for activating the runbook fully or de-escalating.
- Named roles and authorities. Who fills each command role (Incident Commander, Communications Lead, Legal Lead, Forensics Lead, Recovery Lead). What each role is authorized to decide.
- Containment actions in order. Specific containment steps with named owners. Each step has a time estimate, a decision criterion, and an artifact captured.
- Eradication and recovery. Restoration sequencing including dependency management, RTO/RPO targets, and verification checkpoints.
- Communication touch points. When Legal, Communications, Executive Sponsor, regulator, customer, and supplier communications fire. What draft template applies. Who approves before release.
- Regulatory clock starts. Which of the 8 clocks the incident triggers and at which step the clock starts. See regulatory clocks 2026.
- Cyber insurance first-notice trigger. The step at which FNOL fires, the panel vendor activation sequence, the broker coordination touch point.
- Post-incident steps. AAR scheduling, lessons learned capture, runbook update proposals, board briefing.
- Artifacts to preserve. Forensic images, log captures, communications transcripts, regulator filings, approval signatures - everything that goes into the defensible record.
The 10 essential runbooks
Most mid-market organizations need ten foundational runbooks. Sector-specific runbooks (HIPAA breach, PCI compromise, NY DFS event, DORA major ICT incident) extend the foundation for regulated organizations.
Ransomware response
Business email compromise (BEC)
Insider threat response
Third-party or supply chain compromise
Data exfiltration
DDoS response
Credential compromise and account takeover
Wire fraud
Zero-day or critical vulnerability response
Cloud account compromise
Runbook software requirements
Runbook software (or a CIRM platform with runbook capabilities) maintains the runbook library, drives the runbook during incident response, and captures the execution record. The minimum capability set includes:
- Authoring with version control. Runbooks change. The platform tracks versions so a past incident can be reconstructed against the runbook in force at the time.
- In-incident step tracking. Each step is a tracked task with a named owner, a time estimate, and an artifact-capture link.
- Regulatory clock integration. Triggering steps start the relevant clocks automatically. See regulatory clock calculator.
- Communication template integration. Drafts pulled from the holding statement library at each communication touch point.
- AI-augmented drafting. The 7-agent architecture produces high-quality first drafts at each communication step.
- Hash-chained execution record. Every step taken, every approval, every output committed to the ledger for the defensible record.
- Tabletop integration. The same runbook drives both incidents and tabletop exercises so the exercise tests the runbook in force.
Maintenance cadence
Runbooks should be reviewed quarterly and updated after every incident or tabletop that surfaces a gap. Annual recertification by the security committee is a common standard. Material changes (new regulator, new business unit, new critical system) trigger an out-of-cycle update. Version history is preserved so a past incident can be defended against the runbook that was in force at the time.
Software-managed runbooks make the maintenance cadence visible. Stale runbooks (not reviewed in N months) surface as platform alerts. Post-incident lessons learned propose runbook updates that the security committee approves. The result is a runbook library that stays current with the threat environment and the organization's posture.
IR-OS approach
IR-OS treats the IR plan as a computable entity with embedded runbooks for each scenario class. On incident open, the platform selects the applicable runbook based on the incident classification and drives the response through it. Each step is a tracked task with a named owner. AI agents draft outputs at each step that requires communication. The execution record is committed to the hash-chained ledger.
The runbook becomes the defensible record of how the response unfolded. A regulator or counsel reviewing the incident sees not just the outcome but the runbook that drove the response, the specific steps taken, the people who took them, and the approval signatures at each decision gate. The runbook is no longer a document on a shared drive; it is the operational substrate of the response.
Frequently Asked Questions
What is a cyber incident response runbook?
A cyber incident response runbook is a scenario-specific execution guide that turns the IR plan into action for a particular incident class (ransomware, BEC, insider threat, supply chain compromise). Where the IR plan is the strategic document, runbooks are the tactical procedures: ordered steps, role assignments, decision gates, communication touch points, and regulatory clock triggers. Good runbooks are concise, scannable, and stress-tested through tabletop exercises.
How is a runbook different from a playbook or IR plan?
The IR plan is the strategic document (NIST SP 800-61 Section 2) that covers policy, team structure, communication strategy, and overall response posture. A playbook is a procedural workflow, often automated through SOAR, that handles routine detection-phase steps. A runbook is the scenario-specific execution guide for the response phase: ordered actions for handling a ransomware incident, a BEC, an insider threat. The three coexist: the plan sets the strategy, the playbook automates the routine, the runbook drives the response.
What are the 10 essential cyber-IR runbooks?
The 10 essential runbooks for most mid-market organizations are: (1) ransomware response, (2) business email compromise (BEC), (3) insider threat response, (4) third-party or supply chain compromise, (5) data exfiltration, (6) DDoS response, (7) credential compromise and account takeover, (8) wire fraud, (9) zero-day or critical vulnerability response, (10) cloud account compromise. Highly regulated organizations add sector-specific runbooks (HIPAA breach, PCI compromise, NY DFS event, DORA major ICT incident).
What structure does a good runbook follow?
A good runbook follows a consistent structure: (1) scope and triggers, (2) initial assessment steps with decision gate, (3) named roles and authorities, (4) containment actions in order, (5) eradication and recovery steps, (6) communication touch points (legal, comms, executive, regulator, customer), (7) regulatory clock starts that apply, (8) cyber insurance first-notice trigger, (9) post-incident steps including AAR and lessons learned, (10) artifacts to preserve as evidence. Each step has a named owner, a time estimate, and a decision criterion.
What is a ransomware response runbook?
A ransomware response runbook is the scenario-specific execution guide for handling a ransomware incident from discovery through recovery. Key elements include: containment actions (isolation, account lockdown), backup verification, encryption scope assessment, ransom demand handling under counsel direction, OFAC sanctions screening, cyber insurance first-notice, parallel regulatory clocks (SEC 8-K Item 1.05, GDPR Article 33, CIRCIA, HIPAA, NY DFS, sector-specific), forensic preservation, recovery sequencing, customer and stakeholder communications. See the ransomware response guide for the full template.
What is a BEC response runbook?
A BEC (business email compromise) response runbook is the scenario-specific guide for handling email account takeovers, wire fraud attempts, and CEO impersonation incidents. Key elements include: account compromise containment (session revocation, MFA reset, mailbox rule audit), wire recall coordination with the bank (typically a 24-72 hour window), Suspicious Activity Report to FinCEN if applicable, IC3 reporting, communication with the compromised executive's organization, customer notifications, cyber insurance first-notice, and forensic preservation of authentication logs.
How often should runbooks be updated?
Runbooks should be reviewed quarterly and updated after every incident or tabletop that surfaces a gap. Annual recertification by the security committee is a common standard. Material changes (new regulator, new business unit, new critical system) trigger an out-of-cycle update. Runbook version history is preserved so a past incident can be reconstructed against the runbook that was in force at the time. Software-managed runbooks make this versioning automatic.
What is runbook software?
Runbook software is the platform that maintains the runbook library, drives the runbook during incident response, and captures the execution record. Capabilities include: runbook authoring with version control, in-incident step tracking with role assignments, automatic regulatory clock starts on triggering steps, communication template integration, AI-augmented drafting of next-step recommendations, and capture of execution to the hash-chained ledger for the defensible record.
Should every runbook step be automated?
No. Many runbook steps require human judgment (declaring materiality, authorizing ransom payments, approving regulator notifications, briefing the board). The right pattern is: automate the routine (account lockdown, log preservation, ticket creation), AI-augment the drafting (notifications, statements, briefs), and reserve the human judgment for decisions that carry legal or operational accountability. Runbooks should mark which steps are automatable, which are AI-augmented, and which are human-only.
How does IR-OS handle runbooks?
IR-OS treats the IR plan as a computable entity with embedded runbooks for each scenario class. On incident open, the platform selects the applicable runbook based on the incident classification and drives the response through it. Each step is a tracked task with a named owner, the AI agents draft outputs at each step that requires communication, and the execution record is committed to the hash-chained ledger. The runbook becomes the defensible record of how the response unfolded.
Drive incidents through computable runbooks
IR-OS embeds 10 scenario-specific runbooks in your IR plan and drives the response through them. AI-augmented drafts at each communication step, hash-chained execution record, defensible by design.
Start your 7-day free trial