What is an incident response runbook?

An incident response runbook is the per-scenario operational playbook that walks a responder from the first detection signal through containment, eradication, recovery, and the durable record the post-incident review will read. Where the incident response plan describes the governance shape of the programme (authority, escalation, communication, regulatory clocks) and the tabletop exercise tests the response capability under simulated pressure, the runbook is the live-action procedure: the queries an analyst runs against the SIEM, the commands an engineer executes to isolate a host, the identity provider toggles an operator flips to revoke a session, the customer-facing message the communications lead releases, and the evidence each step preserves on the workspace record. A defensible runbook is keyed to a specific scenario class (ransomware, cloud control plane compromise, account takeover, third-party breach, denial of service, source code repository compromise, insider misuse, customer data exposure), names the role that owns each step, names the time budget for each phase, and produces an audit-readable record without the responder having to remember to capture it.

How is a runbook different from an incident response plan and a tabletop exercise?

The three artefacts sit at three different layers of the programme. The incident response plan is the policy document the audit reads: it names the authority, the severity scale, the escalation chain, the communication discipline, the regulatory notification clocks, and the cadence of testing. It is signed by leadership and revised on a periodic schedule. The runbook is the procedural document the responder reads during the incident: it walks step by step through one scenario class with the technical commands, the role accountability, the time budgets, the evidence preservation rules, and the closure criteria. It is owned by the on-call team and revised every time an incident or exercise surfaces a gap. The tabletop exercise is the discussion-based simulation that tests the plan and the runbook under pressure without touching production. It is run on a periodic cadence per scenario lane and produces an after-action report that drives runbook revision. A mature programme keeps the three in sync: the plan defines the shape, the runbook codifies the procedure for each scenario, and the tabletop validates that the runbook still matches the team and the estate.

What sections does a defensible incident response runbook contain?

Twelve sections produce a runbook that survives an audit read and an actual incident. Runbook header (scenario class, runbook identifier, version, effective date, owner, review cadence, framework expectations evidenced). Activation criteria (the detection signal pattern, the severity threshold, the on-call role that activates the runbook, the page or call that opens the incident). Roles for this scenario (incident commander, technical responders by capability, communications lead, legal counsel, executive escalation contact, scenario-specific stakeholders). Initial triage steps (the first ten to thirty minutes: alert validation, initial containment options, scope confirmation, severity reclassification, escalation decision). Containment procedure (the technical steps that stop the bleeding without destroying evidence: account isolation, network segmentation, credential rotation, traffic blocking, access revocation, build freeze). Evidence preservation rules (what to snapshot before any destructive action, what to log, what to chain-of-custody, what to leave alone). Eradication procedure (the technical steps that remove the cause: malicious artefact removal, vulnerable dependency rollback, identity provider posture change, build pipeline cleaning). Recovery procedure (the technical steps that restore service safely: validated backup restoration, staged service return, monitoring intensification, customer-facing service confirmation). Communication script (the templated messages to internal stakeholders, customers, regulators, vendors, and media at each phase, with the authority required to release each one). Closure criteria (the named conditions that move the incident from active to closed, including post-incident review completion). Post-incident review handoff (the artefacts that move to the post-incident review queue: timeline, decision register, action items, evidence pack). Runbook governance (revision triggers, signed-off ownership, training cadence, exercise rotation map).

How many runbooks does a programme need, and how should they be organised?

A defensible programme runs one runbook per scenario class so the responder reads a procedure tailored to the incident in hand rather than a generic playbook that tries to cover everything. Eight scenario classes cover most enterprise estates: ransomware affecting production, cloud control plane compromise, account takeover with lateral movement, customer data breach with regulatory clocks, critical third-party breach, source code repository or build system compromise, insider misuse or fraud, and denial of service or extortion against customer-facing platform. Sector-specific overlays add runbooks for the regulated paths the firm operates: payment card data compromise for PCI estates, electronic protected health information exposure for HIPAA estates, industrial control system compromise for OT estates, telecommunications outage for sector-specific regulators. The eight base runbooks plus the sector overlays are the durable set; a programme that has only one runbook is operating on a generic playbook and will write the scenario-specific procedure during the incident. Each runbook lives on the workspace as a versioned document, paired to the incident response plan, the tabletop exercise programme, the activity log, and the compliance tracking record so the audit can read one consistent operating discipline rather than a folder of disconnected files.

Who owns the runbook and how often should it be revised?

Runbook ownership sits with the role that runs the response for that scenario class, not with a documentation team. For most enterprise programmes the security operations leader or the on-call senior engineer owns the runbook for the scenarios their team is on point for, the platform engineering lead owns the runbook for cloud control plane scenarios, the application engineering lead owns the runbook for source code and build system scenarios, the privacy officer co-owns the runbook for customer data scenarios with the security operations leader, and the head of communications co-owns the communication script section of every runbook. Revision is event-driven rather than calendar-driven: every real incident in scope of a runbook produces a revision pass, every tabletop exercise in the scenario lane produces a revision pass, every significant change in the estate produces a revision pass, and the audit committee receives the revision log on the quarterly governance cycle. A defensible cadence is at least annual structured review per runbook, even when no events have triggered intermediate revisions. The signature trail on each revision is part of the audit-readable evidence pack.

How does the runbook handle evidence preservation during a live incident?

Evidence preservation is a first-class section in every runbook because containment actions that move fast can destroy the evidence the post-incident review and the regulator will need. Three disciplines hold the line. First, the runbook names the artefacts to snapshot before any destructive action: memory image of the affected host, network capture if available, identity provider session record, build pipeline log, container registry pull log, repository commit log, cloud control plane audit log, SIEM event window. Each is named with the storage location and the role responsible for capturing it. Second, the runbook names the destructive actions that require an evidence captured checkpoint before execution: reimaging a host, rotating credentials, deleting a malicious container image, force-revoking sessions, blocking an IP at the edge. The checkpoint is a literal stop in the procedure with a scribe responsibility to confirm capture before authorising the next step. Third, the runbook names the chain-of-custody record: who captured the evidence, when, where it is stored, who has accessed it, and the disposition rule the audit evidence retention policy assigns to incident records. On the workspace the document management feature carries the evidence with role-gated access, multi-factor authentication, and an immutable activity log so the chain-of-custody is observable rather than asserted.

What time budgets should the runbook set for each phase?

A defensible runbook names time budgets per phase per severity band so the responder reads an expectation rather than a hope. For a critical-severity incident the typical pattern is initial triage within fifteen minutes of detection, containment decision within thirty minutes, scope confirmation within ninety minutes, eradication progress within four hours, recovery initiation within twelve hours, and closure within seventy-two hours for the technical workstream (the disclosure-side workstream runs its own clock against the regulatory deadline). For a high-severity incident the cadences relax slightly: triage within thirty minutes, containment within sixty minutes, scope within four hours, eradication progress within eight hours, recovery within twenty-four hours, closure within five business days. For medium-severity incidents the runbook reads against the team operating hours rather than against pager-grade clocks. The time budgets are not service-level agreements with the customer; they are internal pacing expectations the runbook owner sets so the team knows when to escalate, when to call for additional capacity, and when to invoke the executive escalation contact. They are tracked on the workspace activity log and read at the after-action review against the actual incident timing.

How does the runbook align with framework expectations?

ISO/IEC 27001 Annex A 5.24 expects information security incident management to be planned and prepared, A 5.25 expects assessment and decision discipline on security events, A 5.26 expects response to security incidents, A 5.27 expects lessons learned, and Clause 7.5 expects documented information for the management system. Runbooks are the documented procedure that operationalises that expectation. SOC 2 CC7.4 expects detection and response procedures to be tested; CC7.5 expects recovery procedures to be tested; the runbook is the procedure that gets tested. PCI DSS Requirement 12.10.1 expects an incident response plan, 12.10.2 expects testing at least annually, 12.10.4 expects staff training, 12.10.5 expects monitoring and response, and 12.10.6 expects the plan to be evolved per lessons learned; the runbook is the per-scenario procedure that satisfies 12.10.5 and feeds 12.10.6. NIST SP 800-61 Rev. 2 Section 3.3 expects detailed procedures for handling specific incident types; runbooks are those procedures. NIST SP 800-53 IR-4 expects incident handling, IR-5 expects monitoring, IR-6 expects reporting, IR-7 expects assistance, and IR-8 expects an incident response plan; runbooks operationalise IR-4 per scenario class. NIS2 Article 21 expects incident handling, DORA Article 17 expects ICT-related incident management, HIPAA 164.308(a)(6) expects security incident procedures, and the SEC cybersecurity disclosure rule expects material incident determination procedures; runbooks per scenario class are the durable evidence that all of these are operationalised rather than aspirational.

How does the runbook integrate with the broader security operating record?

The runbook is one artefact in a connected operating record rather than a standalone document. It pairs to the incident response plan as the procedure the plan authorises, to the tabletop exercise programme as the procedure the exercise tests, to the findings management ledger as the source of the post-incident action items that move to remediation tracking, to the activity log as the timestamped record of every state change during the incident, to the compliance tracking record as the framework-evidence trail that the runbook execution produces, to the audit evidence retention policy as the classification that governs the incident artefacts, and to the security leadership reporting cycle as the source of the executive summary the leadership read. On the workspace SecPortal carries the runbook on document management with multi-factor authentication and team management RBAC controlling access, the engagement management record holding the per-incident execution context, the findings management ledger carrying the action items, the activity log capturing the immutable state-change record, the compliance tracking feature mapping the runbook to the framework controls it evidences, and the AI report generation feature drafting the post-incident report from the same live record so the audit committee read of incident performance and the operational read are the same query against the same data rather than two independently edited documents that diverge between reporting cycles.

What failure modes does a runbook programme have to design against?

Seven failure modes recur across enterprise programmes and each has a structural fix that the runbook above is designed to enforce. First, single generic playbook covering all scenarios: the responder reads a procedure not tailored to the incident and improvises the scenario-specific steps under pressure. Fix: one runbook per scenario class with explicit activation criteria. Second, runbook written by a team that does not run incidents: the procedure does not match the tools, the access patterns, or the cadence of the on-call team. Fix: ownership sits with the role that runs the response. Third, runbook frozen at first publication: the procedure goes stale as the estate, tools, and team change, and the responder reads steps that no longer apply. Fix: event-driven revision triggered by every incident and exercise. Fourth, evidence preservation treated as a footnote: containment moves fast and destroys the evidence the post-incident review and the regulator need. Fix: evidence checkpoint as a first-class stop in the procedure. Fifth, communication script absent: the technical response runs cleanly but the customer-facing, regulator-facing, and internal messaging is improvised in the moment. Fix: communication script section with templated messages and named release authority. Sixth, runbook stored in a folder nobody can find under pressure: the responder spends the first five minutes searching for the procedure. Fix: workspace-resident document management with role-gated access and search. Seventh, no signature trail on revision: the audit cannot read which runbook version was active during which incident. Fix: versioned document with sign-off and effective-date discipline.

Can the runbook be reused across multiple business units or tenants?

A defensible runbook reuses the procedural skeleton (sections, activation criteria, role mapping, evidence preservation discipline, communication scripting, closure criteria, framework crosswalk) across business units while letting each unit fork the technical commands, the platform-specific containment steps, the contact tree, and the regulator-clock overlays that apply to its estate and its regulatory geography. The skeleton is the discipline; the per-unit fork is the implementation. On SecPortal the workspace can carry the parent runbook as a master document on document management, each business-unit instance as a forked engagement record, and the activity log capturing the lineage between parent and child so a runbook revision in one unit surfaces as a candidate change in the others. For an external provider running incident response services for multiple clients the same pattern operates: the parent runbook lives on the provider workspace, each client receives a forked version on its tenant subdomain through the client portal feature, and the audit trail makes the per-client customisation visible to the next operator who picks the runbook up under pressure.

How should the runbook handle the handoff to the post-incident review?

The handoff from active incident to post-incident review is a discrete step in the runbook rather than an implied transition. Five artefacts move at handoff. The incident timeline (every detection signal, every containment action, every escalation, every customer-facing message, with timestamps and named actors) moves from the activity log on the engagement record. The decision register (every authority invoked, every option considered, every choice taken) moves from the runbook execution notes captured during the incident. The action item ledger (the gaps surfaced during the response that need remediation work after closure) moves to findings management with severity, owner, and target close date so action items get tracked the same way vulnerability findings do rather than as a separate to-do list that decays. The evidence pack (the snapshots, captures, logs, and chain-of-custody record) moves to document management with the audit evidence retention policy classification applied. The closure record (the named conditions met that move the incident from active to closed, signed by the incident commander and the sponsor) moves to the compliance tracking record as the evidence that the runbook ran to completion. The post-incident review draws on all five and produces the final report, the lessons-learned summary, and the runbook revision candidates that feed the next cycle.

Free Tool

Incident Response Runbook Template
one per-scenario package for activation, triage, containment, evidence, eradication, recovery, communication, closure, and post-incident handoff

A free, copy-ready incident response runbook template. Twelve structured sections covering runbook header and version control, activation criteria, scenario-specific role assignment, initial triage in the first ten to thirty minutes, containment options with evidence checkpoints, evidence preservation rules and chain-of-custody discipline, eradication procedure with vulnerability and compensating-control routing, recovery procedure with staged service return, communication script with templated messages and named release authority, closure criteria with signed closure record, post-incident review handoff with five artefact classes, and runbook governance with cadence and revision triggers. Aligned with ISO/IEC 27001 Annex A 5.24, A 5.25, A 5.26, SOC 2 CC7.4 and CC7.5, PCI DSS Requirement 12.10.1, 12.10.5, 12.10.6, NIST SP 800-61 Rev. 2 Section 3.3, NIST SP 800-53 IR-4 through IR-8, NIS2 Article 21, DORA Article 17, HIPAA 164.308(a)(6), and the sector-specific overlays a regulated estate operates against.

Get Started Free

No credit card required. Free plan available forever.

Twelve sections that turn an incident response procedure into a defensible runbook

An incident response runbook is the per-scenario operational procedure a responder reads during a live incident. It is not the incident response plan (the policy document that names authority, escalation, and the cadence of testing) and it is not the tabletop exercise (the simulation that tests the response capability under pressure). It is the step-by-step procedure for one scenario class: the activation criteria, the role assignment, the triage window, the containment options with evidence checkpoints, the eradication actions that remove the cause, the recovery procedure that returns service safely, the communication script that paces every audience, the closure criteria that end the response, and the post-incident review handoff that turns the response into runbook revisions for the next cycle.

The twelve sections below cover the durable shape of one runbook against ISO/IEC 27001 Annex A 5.24, A 5.25, A 5.26, SOC 2 CC7.4 and CC7.5, PCI DSS Requirement 12.10.1, 12.10.5, 12.10.6, NIST SP 800-61 Rev. 2 Section 3.3, NIST SP 800-53 IR-4 through IR-8, NIS2 Article 21, DORA Article 17, HIPAA 164.308(a)(6), and the sector-specific overlays a regulated estate operates against. The package is not a substitute for the operational incident response workflow that runs live incidents day to day, the parent plan that governs the shape of the programme, or the tabletop exercise programme that validates the runbook on a cadence. Pair it with the incident response workflow for the live-incident operating model, the incident response plan guide for the underlying plan structure, the tabletop exercise template for the cadence vehicle that tests the runbook, the security incident severity classification template for the upstream multi-dimensional rubric the on-call role applies at activation to decide which band fires this runbook and what response posture opens, the audit evidence retention policy for the classification that governs the incident artefacts, and the breach notification workflow for the parallel disclosure-side track the runbook hands off to. Copy the section that fits your stage and paste the rest as you go.

Copy the full runbook package (all twelve sections) as one block.

1. Runbook header and version control

Open the runbook with the boundary, the version, and the authority. A reviewer should be able to read in the first lines which scenario class the runbook covers, who owns it, when it was last revised, and which framework expectations the procedure evidences. ISO/IEC 27001 Clause 7.5 expects documented information for the management system with controlled identification, format, and review; this opening block is what makes the runbook traceable to the rest of the programme rather than a loose file on a shared drive.

Runbook title: {{RUNBOOK_TITLE}}
Runbook identifier: {{RUNBOOK_IDENTIFIER}}
Scenario class (one of: ransomware affecting production, cloud control plane compromise, account takeover with lateral movement, customer data breach with regulatory clocks, critical third-party breach, source code or build system compromise, insider misuse or fraud, denial of service or extortion):
- {{SCENARIO_CLASS}}

Sector overlay applied (where applicable: payment card data, electronic protected health information, industrial control system, telecommunications, financial services, federal civilian):
- {{SECTOR_OVERLAY}}

Version: {{RUNBOOK_VERSION}}
Effective date: {{EFFECTIVE_DATE}}
Next scheduled review date: {{NEXT_REVIEW_DATE}}
Revision trigger that produced this version (one of: scheduled annual review, post-incident lesson, tabletop after-action item, significant estate change, new regulatory requirement, tool change):
- {{REVISION_TRIGGER}}

Owner (the role that runs the response for this scenario; signs the runbook at publication):
- Role: {{OWNER_ROLE}}
- Named person at time of publication: {{OWNER_NAME}}
- Signature: {{OWNER_SIGNATURE}}
- Signature date: {{OWNER_SIGNATURE_DATE}}

Co-owners (roles that share authority for sections of the runbook):
- Communications co-owner: {{COMMUNICATIONS_CO_OWNER_ROLE}}
- Legal co-owner: {{LEGAL_CO_OWNER_ROLE}}
- Privacy co-owner (where the scenario touches personal data): {{PRIVACY_CO_OWNER_ROLE}}
- Platform co-owner (where the scenario touches specific platforms): {{PLATFORM_CO_OWNER_ROLE}}

Framework expectations evidenced by this runbook (ISO/IEC 27001 Annex A 5.24, A 5.25, A 5.26; SOC 2 CC7.4 and CC7.5; PCI DSS Requirement 12.10.1, 12.10.5, 12.10.6; NIST SP 800-61 Rev. 2 Section 3.3; NIST SP 800-53 IR-4, IR-5, IR-6, IR-8; HIPAA 164.308(a)(6); NIS2 Article 21; DORA Article 17; sector overlays; internal policy):
- {{FRAMEWORK_EXPECTATIONS_LIST}}

Cross-references:
- Parent incident response plan version: {{IR_PLAN_VERSION}}
- Tabletop exercise programme reference: {{TABLETOP_PROGRAMME_REFERENCE}}
- Audit evidence retention policy version: {{RETENTION_POLICY_VERSION}}
- Compliance tracking record identifier: {{COMPLIANCE_RECORD_IDENTIFIER}}

Revision history (each entry: version, effective date, trigger, owner, signed-off-by):
- v{{PRIOR_VERSION_1}} effective {{PRIOR_DATE_1}}, trigger {{PRIOR_TRIGGER_1}}, owner {{PRIOR_OWNER_1}}, signed {{PRIOR_SIGNATORY_1}}
- v{{PRIOR_VERSION_2}} effective {{PRIOR_DATE_2}}, trigger {{PRIOR_TRIGGER_2}}, owner {{PRIOR_OWNER_2}}, signed {{PRIOR_SIGNATORY_2}}

2. Activation criteria

Name the conditions that activate the runbook so a responder knows whether the runbook in hand is the right runbook for the alert in hand. Without explicit activation criteria the responder defaults to a generic playbook or to memory, and the response loses the scenario-specific procedural advantage the runbook is designed to give. The activation block is the first decision the on-call role makes and is captured on the activity log as the first state change.

Detection signal pattern (the alert types, telemetry patterns, customer reports, third-party notifications, or threat intelligence indicators that suggest this scenario class):
- Primary signal pattern: {{PRIMARY_SIGNAL_PATTERN}}
- Secondary signal patterns (additional signals that strengthen the case for this runbook): {{SECONDARY_SIGNAL_PATTERNS}}
- Disqualifying signals (signals that suggest the alert is not this scenario class and points to a different runbook): {{DISQUALIFYING_SIGNALS}}

Severity threshold for activation (the minimum severity at which the runbook activates; below this threshold the alert handles through standard ticketing rather than incident response):
- {{SEVERITY_ACTIVATION_THRESHOLD}}

On-call role authorised to activate the runbook (the role that confirms activation; activation is a discrete decision recorded on the activity log):
- Primary on-call role: {{PRIMARY_ON_CALL_ROLE}}
- Backup on-call role (when the primary is unavailable): {{BACKUP_ON_CALL_ROLE}}
- Escalation path when both are unavailable: {{ESCALATION_PATH_ON_UNAVAILABILITY}}

Activation page or call protocol (the standardised activation event):
- Activation channel: {{ACTIVATION_CHANNEL}}
- Activation message template: {{ACTIVATION_MESSAGE_TEMPLATE}}
- Acknowledgement requirement (named person acknowledges within how many minutes): {{ACKNOWLEDGEMENT_REQUIREMENT_MINUTES}}

Activation produces the following state on the workspace:
- New engagement record created or existing record reopened with the runbook reference attached.
- Activity log entry created with timestamp, named actor, and activation reason.
- Notification dispatched to the response team and the incident commander per the contact tree in Section 3.
- Severity classification recorded at activation; revisable as scope confirms in Section 4.

Stand-down criteria (the conditions that close the activation when the alert proves to be a false positive or a different scenario class):
- {{STAND_DOWN_CRITERIA}}
- Stand-down produces an activity log entry, a brief stand-down note on the engagement record, and a release of the response team back to standard duty.

3. Roles for this scenario

Name the people who carry the response for this scenario class. Generic role labels (the security team, engineering) collapse under pressure into the one person who happens to be online, and the rest of the response improvises. Scenario-specific role assignment is the discipline that keeps named accountability visible during the incident and observable on the audit trail after.

Incident commander (the role that runs the response; declares severity changes; authorises destructive actions; signs the closure record):
- Primary: {{IC_PRIMARY_ROLE}}
- Backup: {{IC_BACKUP_ROLE}}
- Authority limit (what the IC can authorise alone versus what requires the sponsor): {{IC_AUTHORITY_LIMIT}}

Technical responders required for this scenario class:
- Security operations (alert triage, telemetry analysis, evidence capture): {{SEC_OPS_RESPONDER}}
- Platform engineering (host isolation, network segmentation, service restoration): {{PLATFORM_ENGINEERING_RESPONDER}}
- Application engineering (application-layer containment, dependency rollback, code rollback): {{APPLICATION_ENGINEERING_RESPONDER}}
- Identity engineering (credential rotation, session revocation, identity provider posture change): {{IDENTITY_ENGINEERING_RESPONDER}}
- Cloud control plane operator (IAM rotation, cloud account isolation, organisation-level posture change): {{CLOUD_CONTROL_PLANE_OPERATOR}}
- Database engineering (database isolation, backup restoration, replication intervention): {{DATABASE_ENGINEERING_RESPONDER}}
- Build pipeline owner (pipeline freeze, signing key rotation, release rollback): {{BUILD_PIPELINE_OWNER}}
- Endpoint engineering (endpoint isolation, EDR posture change, fleet remediation): {{ENDPOINT_ENGINEERING_RESPONDER}}

Communications and disclosure roles:
- Communications lead (internal and external messaging cadence; templated message release authority): {{COMMS_LEAD_ROLE}}
- Privacy officer or data protection officer (personal data scope determination; regulatory clock authority): {{PRIVACY_OFFICER_ROLE}}
- Internal legal counsel (privilege boundary; legal hold initiation; contractual obligation determination): {{INTERNAL_COUNSEL_ROLE}}
- External legal counsel (regulator-grade disclosure decisions; cross-border coordination): {{EXTERNAL_COUNSEL_ROLE}}
- Customer success representative (customer-facing impact assessment; account-level coordination): {{CUSTOMER_SUCCESS_REPRESENTATIVE}}

Executive escalation contacts (the named contacts the IC reaches when authority above the IC limit is required; severity-banded):
- High severity: {{EXEC_ESCALATION_HIGH}}
- Critical severity: {{EXEC_ESCALATION_CRITICAL}}
- Board notification trigger: {{BOARD_NOTIFICATION_TRIGGER}}

Scenario-specific stakeholders (added based on the scenario class):
- HR (insider misuse scenarios): {{HR_REPRESENTATIVE}}
- Finance (extortion or fraud scenarios): {{FINANCE_REPRESENTATIVE}}
- Sales (customer-facing impact scenarios): {{SALES_REPRESENTATIVE}}
- Regulator-relations (notification scenarios): {{REGULATOR_RELATIONS_REPRESENTATIVE}}
- Vendor management (third-party breach scenarios): {{VENDOR_MANAGEMENT_REPRESENTATIVE}}
- OT or ICS operator (operational technology scenarios): {{OT_ICS_OPERATOR}}

Authority discipline (read at the start of the response):
- The incident commander authorises destructive actions; technical responders execute them.
- The communications lead releases customer-facing and regulator-facing messaging; the IC does not freelance disclosure.
- The privacy officer determines personal data scope; the IC does not assert scope without that determination.
- The internal counsel authorises legal hold and asserts privilege; legal hold is not optional once invoked.
- The sponsor or board contact authorises actions above the IC limit; the IC does not improvise above its authority.

4. Initial triage: the first ten to thirty minutes

Walk the responder through the first ten to thirty minutes of the response in named steps with time budgets per step. This is the window where the response either anchors to discipline or collapses into improvisation. The triage block is the most important section of the runbook and the section the responder reads first while the activation page is still open. Every step here produces an activity log entry.

Step 1 (target: within five minutes of activation) - Validate the alert:
- Confirm the detection signal pattern matches the activation criteria in Section 2.
- Cross-check against the disqualifying signals in Section 2.
- If the signal does not match this scenario class, hand off to the runbook for the scenario class that does match and record the handoff on the activity log.
- If the signal pattern matches, proceed to Step 2.

Step 2 (target: within ten minutes of activation) - Confirm initial scope:
- Identify the affected estate from the telemetry (hosts, accounts, services, customers).
- Capture an initial scope record on the engagement record with the named identifiers.
- Do not assume scope is bounded; record what is confirmed and mark the rest as in progress.

Step 3 (target: within fifteen minutes of activation) - Initial containment decision:
- Read the containment options in Section 5 and select the option that stops the spread without destroying evidence.
- If the chosen action is destructive (reimage, force-revoke, delete), confirm the evidence checkpoint in Section 6 before proceeding.
- If the chosen action is non-destructive (block, isolate, throttle), proceed and capture the action on the activity log.

Step 4 (target: within twenty minutes of activation) - Severity reclassification:
- Re-evaluate the severity classification against the confirmed scope and the customer-facing impact.
- If the severity has changed, record the change on the activity log with the rationale, and dispatch the severity-change notification per the contact tree in Section 3.
- If the severity has changed to critical, invoke the executive escalation contact for critical severity in Section 3.

Step 5 (target: within twenty-five minutes of activation) - Communications opening:
- The communications lead releases the internal incident-opened message per the template in Section 9.
- The customer success representative reviews customer-facing impact and flags accounts that will need account-level outreach.
- The privacy officer reviews the scope record for personal data exposure and starts the regulatory clock assessment if applicable.
- The legal counsel reviews the response and confirms whether legal hold needs to be invoked.

Step 6 (target: within thirty minutes of activation) - Containment progress check:
- Re-evaluate the initial containment from Step 3 against the latest telemetry.
- Confirm whether the spread has stopped, slowed, or continued.
- If the spread has continued, escalate the containment approach and select the next option from Section 5.

Triage record output (captured at the end of the thirty-minute window):
- Validated alert reference: {{TRIAGE_ALERT_REFERENCE}}
- Confirmed initial scope summary: {{TRIAGE_INITIAL_SCOPE}}
- Initial containment action taken and outcome: {{TRIAGE_INITIAL_CONTAINMENT}}
- Severity at end of triage: {{TRIAGE_END_SEVERITY}}
- Named responders engaged at end of triage: {{TRIAGE_ENGAGED_RESPONDERS}}
- First decision register entry written: {{FIRST_DECISION_REGISTER_ENTRY}}

5. Containment procedure

Walk the responder through the containment options the runbook authorises for this scenario class, in named steps with the evidence checkpoint that has to fire before any destructive action. Containment is the phase that benefits most from runbook discipline because the impulse to move fast is highest here, and the cost of destroying evidence is highest here. Every action in this section produces an activity log entry and pairs to the evidence preservation rules in Section 6.

Non-destructive containment options (preferred where they stop the spread):
- Network segmentation (move the affected hosts to an isolated segment without shutting them down):
  - Command or platform reference: {{NETWORK_SEGMENTATION_REFERENCE}}
  - Owner: {{NETWORK_SEGMENTATION_OWNER}}
  - Evidence captured before action: {{NETWORK_SEGMENTATION_EVIDENCE}}

- Account session revocation (revoke active sessions without deleting accounts):
  - Identity provider reference: {{SESSION_REVOCATION_REFERENCE}}
  - Owner: {{SESSION_REVOCATION_OWNER}}
  - Evidence captured before action: {{SESSION_REVOCATION_EVIDENCE}}

- Traffic blocking at the edge (block known-bad IPs, domains, or signatures at the perimeter):
  - Edge platform reference: {{EDGE_BLOCKING_REFERENCE}}
  - Owner: {{EDGE_BLOCKING_OWNER}}
  - Evidence captured before action: {{EDGE_BLOCKING_EVIDENCE}}

- Build pipeline freeze (stop builds without deleting the pipeline):
  - Pipeline reference: {{PIPELINE_FREEZE_REFERENCE}}
  - Owner: {{PIPELINE_FREEZE_OWNER}}
  - Evidence captured before action: {{PIPELINE_FREEZE_EVIDENCE}}

- Repository access revocation (revoke push and merge access without deleting the repository):
  - Repository platform reference: {{REPO_ACCESS_REVOCATION_REFERENCE}}
  - Owner: {{REPO_ACCESS_REVOCATION_OWNER}}
  - Evidence captured before action: {{REPO_ACCESS_REVOCATION_EVIDENCE}}

- Service throttling or feature flag rollback (reduce blast radius without taking the service offline):
  - Service or platform reference: {{SERVICE_THROTTLING_REFERENCE}}
  - Owner: {{SERVICE_THROTTLING_OWNER}}
  - Evidence captured before action: {{SERVICE_THROTTLING_EVIDENCE}}

Destructive containment options (require evidence checkpoint in Section 6 before execution):
- Host reimage or rebuild:
  - Platform reference: {{HOST_REIMAGE_REFERENCE}}
  - Owner: {{HOST_REIMAGE_OWNER}}
  - Mandatory evidence checkpoint: memory image, disk image, network capture window, EDR telemetry export.

- Credential rotation at scale:
  - Identity provider reference: {{CREDENTIAL_ROTATION_REFERENCE}}
  - Owner: {{CREDENTIAL_ROTATION_OWNER}}
  - Mandatory evidence checkpoint: identity provider audit log export, session list snapshot, role assignment snapshot.

- Container image deletion or registry cleanup:
  - Registry reference: {{REGISTRY_CLEANUP_REFERENCE}}
  - Owner: {{REGISTRY_CLEANUP_OWNER}}
  - Mandatory evidence checkpoint: image manifest export, pull log export, signing key chain export.

- Account deletion:
  - Identity platform reference: {{ACCOUNT_DELETION_REFERENCE}}
  - Owner: {{ACCOUNT_DELETION_OWNER}}
  - Mandatory evidence checkpoint: account record snapshot, group membership snapshot, audit log export covering the affected window.

- Service shutdown:
  - Service reference: {{SERVICE_SHUTDOWN_REFERENCE}}
  - Owner: {{SERVICE_SHUTDOWN_OWNER}}
  - Mandatory evidence checkpoint: service configuration snapshot, telemetry export covering the affected window, customer-facing impact assessment.

Containment progression rules:
- Try non-destructive containment first where the threat profile and the time budget allow.
- Move to destructive containment when non-destructive options have not stopped the spread or when the scenario class warrants immediate destructive action (e.g. confirmed ransomware encryption in progress).
- Every destructive containment action produces an activity log entry naming the actor, the time, the evidence checkpoint reference, and the authority invoked.
- The incident commander authorises every destructive containment action; the responder does not execute without the named authorisation captured on the activity log.

Containment completion criteria:
- Spread has stopped (telemetry confirms no new affected systems, accounts, or services in the last {{SPREAD_QUIESCENCE_WINDOW_MINUTES}} minutes).
- Confirmed scope is documented on the engagement record with the named identifiers.
- All destructive containment actions have completed evidence checkpoints recorded.
- The communications lead has briefed internal stakeholders that containment has held.

6. Evidence preservation rules

Name the artefacts the runbook preserves, the actions that require an evidence captured checkpoint before execution, and the chain-of-custody discipline the workspace applies. Evidence preservation is the section that protects the post-incident review and the regulator-grade record from the speed of containment. Treat this as a first-class procedural section rather than a footnote on the containment steps.

Artefacts to preserve before any destructive action (capture each to the workspace document management feature with the responsible named on the activity log):

- Memory image of each affected host:
  - Capture tool reference: {{MEMORY_IMAGE_TOOL}}
  - Storage path on workspace: {{MEMORY_IMAGE_STORAGE_PATH}}
  - Responsible role: {{MEMORY_IMAGE_RESPONSIBLE_ROLE}}

- Disk image of each affected host (where feasible within the time budget):
  - Capture tool reference: {{DISK_IMAGE_TOOL}}
  - Storage path on workspace: {{DISK_IMAGE_STORAGE_PATH}}
  - Responsible role: {{DISK_IMAGE_RESPONSIBLE_ROLE}}

- Network capture covering the affected window:
  - Capture source reference: {{NETWORK_CAPTURE_SOURCE}}
  - Storage path on workspace: {{NETWORK_CAPTURE_STORAGE_PATH}}
  - Responsible role: {{NETWORK_CAPTURE_RESPONSIBLE_ROLE}}

- Identity provider session and audit log export covering the affected window:
  - IDP reference: {{IDP_EXPORT_REFERENCE}}
  - Storage path on workspace: {{IDP_EXPORT_STORAGE_PATH}}
  - Responsible role: {{IDP_EXPORT_RESPONSIBLE_ROLE}}

- Cloud control plane audit log export covering the affected window:
  - Cloud account reference: {{CLOUD_AUDIT_EXPORT_REFERENCE}}
  - Storage path on workspace: {{CLOUD_AUDIT_EXPORT_STORAGE_PATH}}
  - Responsible role: {{CLOUD_AUDIT_EXPORT_RESPONSIBLE_ROLE}}

- SIEM event window export covering the alert and the response:
  - SIEM reference: {{SIEM_EXPORT_REFERENCE}}
  - Storage path on workspace: {{SIEM_EXPORT_STORAGE_PATH}}
  - Responsible role: {{SIEM_EXPORT_RESPONSIBLE_ROLE}}

- Build pipeline log covering the affected build window:
  - Pipeline reference: {{PIPELINE_LOG_REFERENCE}}
  - Storage path on workspace: {{PIPELINE_LOG_STORAGE_PATH}}
  - Responsible role: {{PIPELINE_LOG_RESPONSIBLE_ROLE}}

- Repository commit log and access log covering the affected window:
  - Repository reference: {{REPO_LOG_REFERENCE}}
  - Storage path on workspace: {{REPO_LOG_STORAGE_PATH}}
  - Responsible role: {{REPO_LOG_RESPONSIBLE_ROLE}}

- Container registry pull and push log covering the affected window:
  - Registry reference: {{REGISTRY_LOG_REFERENCE}}
  - Storage path on workspace: {{REGISTRY_LOG_STORAGE_PATH}}
  - Responsible role: {{REGISTRY_LOG_RESPONSIBLE_ROLE}}

Evidence checkpoint protocol (a literal stop in the containment procedure):
- The responder pauses before any destructive containment action.
- The responder confirms that every artefact applicable to the action is captured with a storage path recorded on the engagement record.
- The scribe role confirms the capture on the activity log with a checkpoint passed entry.
- The incident commander authorises the destructive action by name on the activity log.
- Only then does the destructive action execute.

Chain-of-custody discipline:
- Every artefact captured is written to the workspace document management feature.
- The document carries the captured-by role, the timestamp, and the engagement reference.
- Access to incident evidence is gated by the role-based access control in team management and protected by multi-factor authentication.
- Every read of an incident artefact lands on the activity log with the named reader, the timestamp, and the purpose.
- Disposition of incident artefacts is governed by the audit evidence retention policy classification for incident records (typically the longest retention window the firm operates).

Forbidden actions during a live response (without explicit incident commander authorisation):
- Reimaging an affected host before memory and disk capture.
- Force-revoking sessions before the identity provider audit log export.
- Deleting a container image before the registry log export.
- Closing the engagement record before the post-incident review draws the artefacts down.
- Editing or deleting the activity log entries from the affected window.

7. Eradication procedure

Walk the responder through removing the cause once containment has held. Eradication is the phase where the runbook prevents the same attack from re-entering through the same path, and where the runbook ties to the upstream vulnerability management and code scanning workstreams so the underlying weakness becomes a tracked finding rather than a forgotten note in the response.

Step 1 - Confirm the cause:
- Read the telemetry and the captured evidence to confirm the technical cause (malicious artefact, exploited vulnerability, leaked credential, misconfigured posture, social engineering attack).
- Record the confirmed cause on the engagement record as the eradication target.
- If the cause is not confirmed, do not proceed to removal; widen the scope investigation and re-engage Section 6 evidence capture.

Step 2 - Plan the eradication action:
- Name the action that removes the cause without re-exposing the estate (artefact removal, credential rotation at scope, dependency rollback, posture change, account remediation, configuration change).
- Confirm that the action does not undo the containment in Section 5 before it completes.
- Confirm that the action does not destroy evidence the regulator or the post-incident review will need.

Step 3 - Execute the eradication action:
- The technical responder executes the action under incident commander authorisation, captured on the activity log.
- The platform owner verifies the action completed (artefact removed, credential rotated, dependency replaced, posture changed, account remediated, configuration deployed).
- The change is documented on the engagement record with the named actor, the time, and the rollback path if the change has to be undone.

Step 4 - Detection rule update (where applicable):
- The security operations responder updates the detection rule that should have caught the initial signal earlier.
- The new or updated rule is recorded on the engagement record and the SIEM platform.
- The detection-rule action item moves to the action item ledger in Section 11 with severity, owner, and target close date.

Step 5 - Underlying vulnerability action:
- If the cause is an exploitable vulnerability in the estate, create or update a finding on the findings management feature with the CVSS-aligned severity, the named owner, the target close date, and the cross-reference to this engagement record.
- If the cause is a leaked credential, ensure the secret remediation action lives on the findings management ledger with the named owner.
- If the cause is a misconfigured posture, the posture-fix action item moves to the same ledger with severity, owner, and target close date.

Step 6 - Compensating control adjustment:
- Where eradication cannot fully remove the cause (legacy system, third-party dependency, vendor-managed component), the runbook names the compensating control that the response invokes (network restriction, monitoring intensification, access reduction, exception register entry).
- The compensating control lives on the workspace with a named owner, an effective date, an expiry date, and a review trigger so the compensation is observable rather than ambient.

Eradication completion criteria:
- Cause is confirmed and named on the engagement record.
- Eradication action has executed and the platform owner has verified completion.
- The detection rule, the vulnerability finding, the credential finding, the posture finding, or the compensating control has moved to the workspace ledger with severity, owner, and target close date.
- The communications lead has briefed internal stakeholders that eradication has completed.

8. Recovery procedure

Walk the responder through restoring service safely once eradication has completed. Recovery is the phase where the runbook keeps the team disciplined about validation before service return, and where it protects against the impulse to declare the incident over while telemetry is still settling. Every recovery action lands on the activity log so the post-incident review reads against an observable timeline rather than a remembered one.

Step 1 - Validation before service return:
- Run the validation queries that confirm the cause is no longer present in the affected estate (telemetry queries, vulnerability re-check, credential audit, posture compliance check, integrity check on restored components).
- Capture the validation output on the engagement record as part of the recovery evidence pack.
- If validation fails, return to Section 7 eradication; do not proceed to recovery on incomplete eradication.

Step 2 - Staged service return:
- Restore the affected service to a limited audience first (internal users, canary cohort, low-traffic region) and monitor for the signal patterns from Section 2.
- Confirm the staged return is stable for the named window before broadening: {{STAGED_RETURN_STABILITY_WINDOW_HOURS}} hours.
- Broaden the service availability in named tranches with a stability window between each tranche.

Step 3 - Monitoring intensification:
- Tighten the alert thresholds for the affected estate for the named window: {{MONITORING_INTENSIFICATION_WINDOW_DAYS}} days.
- Add or activate the detection rules from Section 7 Step 4.
- Brief the on-call team on the elevated monitoring posture and the response expectation if a signal recurs.

Step 4 - Customer-facing service confirmation:
- The customer success representative confirms the service is available to the affected customers and any account-level outreach from Section 9 has reached the affected accounts.
- The communications lead releases the service-restored message per the template in Section 9.
- Customer-reported impact tickets opened during the response are closed or referred to the post-incident review queue.

Step 5 - Backup and restore validation (where backups were touched):
- Confirm the backup integrity is preserved for the affected windows.
- Confirm the next scheduled backup completes successfully.
- Capture the backup validation record on the engagement record.

Step 6 - Recovery rollback option:
- Name the rollback path if the recovery does not hold: which containment options re-engage, which validation rerun is required, which executive escalation contact is engaged.

Recovery completion criteria:
- Validation has passed against the named queries.
- Service has been returned in staged tranches and the stability window has elapsed at full availability.
- Monitoring intensification is active for the named window.
- Customer-facing communication has reached the affected accounts.
- The incident commander has signed off on recovery completion on the engagement record.

9. Communication script

Hold the templated messaging for internal stakeholders, customers, regulators, vendors, and media inside the runbook rather than improvising during the incident. Every templated message names the release authority, the audience, the phase, and the cadence so the communication discipline operates as a procedure rather than as a guess.

Internal incident-opened briefing (release authority: incident commander; audience: response team and named internal stakeholders; phase: triage):
"At {{TIME}} on {{DATE}} we activated the {{SCENARIO_CLASS}} runbook in response to {{INITIAL_SIGNAL}}. Severity at activation is {{SEVERITY}}. The response team is engaged and the incident commander is {{IC_NAME}}. Next update in {{NEXT_UPDATE_MINUTES}} minutes."

Internal incident-progress briefing (release authority: communications lead under IC sign-off; audience: response team plus extended internal stakeholders; phase: every cadence interval during the response):
"As of {{TIME}} on {{DATE}}, response status on {{INCIDENT_REFERENCE}}: scope is {{CONFIRMED_SCOPE}}. Containment is {{CONTAINMENT_STATUS}}. Eradication is {{ERADICATION_STATUS}}. Recovery is {{RECOVERY_STATUS}}. No customer-facing impact has been confirmed | Customer-facing impact is {{CUSTOMER_IMPACT}}. Next update in {{NEXT_UPDATE_MINUTES}} minutes."

Customer-facing incident message (release authority: communications lead under privacy officer and legal counsel sign-off; audience: affected customers; phase: confirmed customer-facing impact):
"On {{DATE}} we identified a security incident affecting {{SERVICE_AND_CUSTOMER_SCOPE}}. We have contained the incident and are investigating the cause. {{IMPACT_DETAIL}}. We will provide further updates as the investigation progresses. If you have any concerns please contact {{CUSTOMER_CONTACT}}."

Customer-facing service-restored message (release authority: communications lead; audience: previously affected customers; phase: recovery completion):
"On {{DATE}} we restored {{SERVICE_NAME}} to full availability following the security incident reported on {{INITIAL_DATE}}. Investigation continues; we will publish further detail and any required customer actions in a follow-up communication by {{FOLLOW_UP_DATE}}."

Regulator notification (release authority: privacy officer or DPO under external legal counsel sign-off; audience: relevant regulator per the regulatory clock; phase: as soon as the personal data scope is confirmed or as soon as the notification clock requires):
"On {{INCIDENT_DATE}} {{ORGANISATION_NAME}} identified a security incident that may have affected personal data subject to {{REGULATORY_FRAMEWORK}}. Affected data categories: {{DATA_CATEGORIES}}. Estimated data subjects affected: {{DATA_SUBJECTS_AFFECTED}}. Containment actions taken: {{CONTAINMENT_SUMMARY}}. Investigation status: {{INVESTIGATION_STATUS}}. Notification contact: {{NOTIFICATION_CONTACT}}."

Vendor coordination message (release authority: vendor management representative under IC sign-off; audience: critical vendor in scope of the scenario; phase: vendor-related scenarios):
"On {{INCIDENT_DATE}} we identified a security incident potentially involving {{VENDOR_SERVICE_AND_SCOPE}}. Please confirm whether the indicators in {{INDICATOR_REFERENCE}} match activity on your platform and what coordination support you can provide on {{COORDINATION_REQUEST}}."

Media holding statement (release authority: communications lead under external legal counsel sign-off; audience: media on inquiry; phase: confirmed public visibility of the incident):
"We have identified a security incident and are currently in the response phase. We are taking the matter seriously, have engaged the appropriate internal and external expertise, and will share further information as the investigation progresses and as we are able to confirm specific facts. For specific inquiries please contact {{MEDIA_CONTACT}}."

Cadence rules:
- Internal incident-progress briefings run every fifteen minutes during the first hour, every thirty minutes for the next four hours, and every ninety minutes thereafter until closure.
- Customer-facing messaging is released only after the privacy officer and legal counsel have signed off.
- Regulator notifications respect the regulatory clock rather than the internal cadence.
- Media inquiries route to the communications lead; technical responders do not speak directly to media.
- Every message released lands on the activity log with the named actor, the audience, and the message reference.

10. Closure criteria

Name the conditions that move the incident from active to closed and produce the signed closure record. Without explicit closure criteria the response either drags on past its useful life or closes prematurely while work is still owed. The closure block is the discrete decision that ends the runbook execution and opens the post-incident review.

Closure criteria (all required before closure):
- Containment has held for the named quiescence window: {{CLOSURE_QUIESCENCE_WINDOW_HOURS}} hours.
- Eradication action has executed and the platform owner has verified completion.
- Recovery has completed and the service is at full availability per Section 8.
- Detection rule update, vulnerability finding, credential finding, posture finding, or compensating control from Section 7 has moved to the workspace ledger with severity, owner, and target close date.
- Customer-facing communication for the recovery has reached the affected accounts where customer-facing impact was confirmed.
- Regulator notification has been released where the regulatory clock required it.
- Evidence pack from Section 6 is complete and held on the workspace with the audit evidence retention policy classification applied.
- Activity log captures the full timeline of the response from activation through closure.
- The action items emerging from the response are recorded on the action item ledger in Section 11.

Closure record (signed by the incident commander and the sponsor):
- Incident reference: {{INCIDENT_REFERENCE}}
- Scenario class and runbook version: {{SCENARIO_AND_RUNBOOK_VERSION}}
- Activation time: {{ACTIVATION_TIME}}
- Closure time: {{CLOSURE_TIME}}
- Total response duration: {{RESPONSE_DURATION}}
- Confirmed scope at closure: {{CLOSURE_CONFIRMED_SCOPE}}
- Severity at closure: {{CLOSURE_SEVERITY}}
- Cause confirmed: {{CLOSURE_CAUSE}}
- Containment summary: {{CLOSURE_CONTAINMENT_SUMMARY}}
- Eradication summary: {{CLOSURE_ERADICATION_SUMMARY}}
- Recovery summary: {{CLOSURE_RECOVERY_SUMMARY}}
- Customer-facing impact summary: {{CLOSURE_CUSTOMER_IMPACT_SUMMARY}}
- Regulator notifications released: {{CLOSURE_REGULATOR_NOTIFICATIONS}}
- Action items raised and routed: {{CLOSURE_ACTION_ITEMS_COUNT}}
- Evidence pack reference: {{CLOSURE_EVIDENCE_PACK_REFERENCE}}
- Incident commander signature: {{CLOSURE_IC_SIGNATURE}}
- Sponsor signature: {{CLOSURE_SPONSOR_SIGNATURE}}
- Closure date: {{CLOSURE_DATE}}

Post-closure obligations:
- The post-incident review is scheduled within {{POST_INCIDENT_REVIEW_WINDOW_BUSINESS_DAYS}} business days of closure.
- The action item ledger is owned by the runbook owner until each item closes against its target close date.
- The runbook revision candidates surfaced by the response are queued for the next runbook governance cycle.
- The compliance tracking record is updated with the framework evidence the response produced.
- The audit committee receives the closure summary on the next governance cadence.

11. Post-incident review handoff

Name the artefacts that move from the active incident to the post-incident review queue, the roles that read each artefact, and the cadence at which the review converts the artefacts into runbook revision candidates. Without a structured handoff the post-incident review reconstructs the response from memory and the runbook revisions get reverse-engineered after the lessons have decayed.

Artefacts that move at handoff (each lives on the workspace and is read against the review schedule):

Incident timeline:
- Source: activity log on the engagement record (timestamps, named actors, state changes, communications released, evidence captured, destructive actions authorised).
- Reader: post-incident review facilitator and the incident commander.
- Output: the chronological narrative the after-action report opens with.

Decision register:
- Source: runbook execution notes captured during the response (each authority invoked, each option considered, each choice taken, each open question that could not close).
- Reader: post-incident review facilitator, the IC, and the role co-owners.
- Output: the decision quality assessment the after-action report carries.

Action item ledger:
- Source: the gaps surfaced during the response (detection rule update, vulnerability finding, credential finding, posture finding, compensating control, runbook revision candidate, training need, communication template revision).
- Reader: the runbook owner and the action item owner per item.
- Output: tracked items on findings management with severity, named owner, target close date, and evidence-of-closure requirement.

Evidence pack:
- Source: the artefacts captured in Section 6.
- Reader: the post-incident review facilitator, the privacy officer, the legal counsel where applicable, the external counsel where the regulator engagement continues post-closure.
- Output: the chain-of-custody record the audit can read.

Closure record:
- Source: the signed closure record in Section 10.
- Reader: the audit committee on the next governance cadence; the compliance tracking record receives a pointer to the closure record.
- Output: the framework evidence anchor for the runbook execution.

Post-incident review structure:
- Hot wash (within 24 hours of closure): immediate impressions captured while the response is fresh; named gaps escalated to the IC and the runbook owner.
- Formal review (within {{POST_INCIDENT_REVIEW_WINDOW_BUSINESS_DAYS}} business days of closure): the full reading of the timeline, the decision register, the evidence pack, and the action item ledger; the after-action report is drafted.
- After-action report (signed within ten business days of the formal review): the durable artefact that survives audit; lives on document management with the audit evidence retention policy classification.
- Runbook revision cycle (initiated by the runbook owner): the candidates surfaced by the response move to the next runbook revision pass per the governance cadence in Section 12.

After-action report contents (as a minimum):
- Executive summary (one page; signed by the IC and the sponsor).
- Timeline (chronological, pulled from the activity log).
- Cause and contributing factors (technical, procedural, organisational).
- Containment, eradication, and recovery summary against the runbook procedure.
- Decision quality assessment (was the right decision made at each decision point inside the time budget).
- Communication quality assessment (was every audience briefed at the cadence the runbook required).
- Evidence preservation assessment (was every destructive action preceded by the evidence checkpoint).
- Action item ledger summary with target close dates.
- Runbook revision candidates with the proposed change per section.
- Framework evidence mapping (which ISO 27001, SOC 2, PCI DSS, NIST, NIS2, DORA, HIPAA control the response evidences).

12. Runbook governance and review cadence

Name the cadence at which the runbook is reviewed, the triggers that move a review forward, the audit-readable artefacts produced per cycle, and the metrics the leadership reads against the runbook programme. Governance is what keeps the runbook a living document rather than a frozen file that the next responder reads under pressure and discovers is out of date.

Standing review cadence:
- At least annual structured review per runbook even when no events have triggered intermediate revisions.
- Quarterly review of the runbook portfolio across scenario classes by the security operations leader and the GRC operations leader.
- Annual review of the runbook portfolio by the audit committee against the framework expectations in Section 1.

Event-driven revision triggers (each event below triggers a revision pass and a versioned re-publication):
- Real incident in scope of the runbook (every closure triggers a revision pass).
- Tabletop exercise in the scenario lane (every exercise after-action report triggers a revision pass).
- Significant estate change (new business line, new regulatory geography, material acquisition, new core platform, change of identity provider, change of cloud account model, change of build pipeline, change of SIEM, change of EDR).
- New regulatory requirement applicable to the scenario class.
- Detection rule change that affects the activation criteria in Section 2.
- Communication template change that affects Section 9.
- Audit observation that names the runbook as deficient.

Revision pass procedure:
- The runbook owner drafts the revision against the trigger.
- The role co-owners review their sections.
- The internal counsel reviews legal hold and authority sections.
- The privacy officer reviews regulatory clock sections.
- The communications lead reviews the communication script in Section 9.
- The incident commander signs the revision and publishes the new version with effective date.
- The activity log captures the revision event.
- The prior version is retained on document management per the audit evidence retention policy.
- The next exercise in the scenario lane is reviewed against the new version.

Audit-readable artefacts per cycle:
- Runbook version with effective date.
- Revision trigger record.
- Sign-off record (owner, co-owners, IC, sponsor).
- Activity log entries for the revision event.
- Post-incident reviews and tabletop after-action reports referenced by the revision.

Programme metrics the audit committee receives quarterly:
- Number of runbooks in the portfolio: {{RUNBOOKS_IN_PORTFOLIO}}
- Average runbook age since last revision: {{AVERAGE_RUNBOOK_AGE_DAYS}}
- Number of runbooks revised in the quarter: {{RUNBOOKS_REVISED_QUARTER}}
- Number of runbooks overdue for scheduled review: {{RUNBOOKS_OVERDUE_REVIEW}}
- Number of action items raised from runbook execution in the quarter: {{ACTION_ITEMS_RAISED_QUARTER}}
- Action item closure rate against target: {{ACTION_ITEM_CLOSURE_RATE_QUARTER}}
- Number of incidents in scope of a runbook that ran outside the runbook procedure: {{OUT_OF_PROCEDURE_INCIDENTS_QUARTER}}

Annual programme metrics:
- Runbook portfolio coverage against the scenario lane library.
- Average decision-to-evidence-checkpoint compliance rate across responses.
- Average customer-facing communication cadence compliance.
- Average regulator notification timing against the regulatory clock where applicable.
- Notable cross-cycle lessons learned that landed in the runbook or in the wider response capability.

Programme acknowledgement:
- The runbook portfolio is the live procedural backbone of the incident response programme.
- The plan defines the shape, the runbook codifies the procedure for each scenario, the tabletop validates the procedure, and the post-incident review revises the procedure.
- The four artefacts are kept in sync on one workspace so the audit read of incident response and the operational read are the same record.

Seven failure modes the runbook has to design against

The runbook programme fails the audit read and the live-incident read in recognisable patterns. Each failure has a structural fix that the template above is designed to enforce. Read this list before you customise the runbook so the customisation does not weaken the discipline that makes the procedure defensible.

Single generic playbook covering every scenario

The firm has one incident response playbook that tries to walk every scenario class through the same procedural shape. Under pressure the responder reads steps that do not match the scenario in hand and improvises the scenario-specific procedure on the day. The fix is one runbook per scenario class with explicit activation criteria in Section 2 and scenario-specific containment options in Section 5.

Runbook written by a team that does not run incidents

A documentation team or an external consultant drafts the runbook to satisfy an audit requirement. The procedure does not match the tools, the access patterns, or the cadence the on-call team uses. The team reads the runbook once during onboarding and never references it again. The fix is named ownership in Section 1 tied to the role that actually runs the response for the scenario class, with revision pass authority sitting with that role.

Runbook frozen at first publication

The runbook is published at programme launch and never revised. The estate, the tools, the team, and the regulatory environment change underneath, and the responder reads steps that no longer apply. The fix is event-driven revision in Section 12: every incident, every exercise, every significant estate change triggers a revision pass with a versioned re-publication and a captured activity log event.

Evidence preservation treated as a footnote

The runbook covers detection, containment, eradication, and recovery in detail but treats evidence preservation as a sidebar. Containment moves fast in the moment and destroys the evidence the post-incident review and the regulator will need. The fix is Section 6 as a first-class procedural section with the evidence checkpoint as a literal stop in every destructive containment action and chain-of-custody discipline on the workspace document management feature.

Communication script missing or improvised

The technical response runs cleanly but the customer-facing, regulator-facing, internal, and media-facing messaging is improvised in the moment. The communications lead writes templates under pressure, legal review happens after release, and the regulator clock starts ticking before the privacy officer has confirmed the scope. The fix is the templated message library in Section 9 with named release authority per message and the cadence rules that pace the briefings against the response state.

Runbook stored in a folder nobody can find under pressure

The runbook lives in a shared drive, a wiki, or a vendor tool that the on-call team does not reach for in the first thirty minutes. Responders search for the runbook while the alert is still open. The fix is workspace-resident document management with role-gated access, multi-factor authentication, search, and the runbook reference attached to the engagement record at activation in Section 2.

No signature trail on revision

Revisions land on the runbook without sign-off, effective date discipline, or activity log capture. The audit asks which runbook version was active during which incident and the firm cannot answer. The fix is the version control block in Section 1 with owner sign-off at publication, prior version retention per the audit evidence retention policy, and an activity log entry for every revision event.

Ten questions the quarterly governance review has to answer

Operational review keeps the runbook portfolio current. Governance review answers whether the portfolio is delivering durable response capability or accumulating gaps the audit will read as procedure-on-paper. Run these ten questions at every quarterly review and capture the answers in the governance record on the workspace.

1.How many runbooks does the portfolio carry, and what is the coverage against the eight base scenario classes plus the sector overlays applicable to the firm.
2.What is the average runbook age since last revision, and how does it compare to the previous quarter.
3.How many runbooks are overdue for scheduled annual review, and what is the structural reason for the overrun.
4.How many incidents in the rolling twelve months activated a runbook, and how many ran outside the runbook procedure.
5.How many action items did runbook execution raise in the period, and what is the closure rate against target.
6.What is the decision-to-evidence-checkpoint compliance rate across the responses in the period.
7.What is the customer-facing communication cadence compliance rate against the cadence rules in each runbook.
8.How many destructive containment actions executed without a captured evidence checkpoint, and what was the structural cause.
9.Which runbook revisions in the period were triggered by an audit observation or a regulator interaction.
10.Which scenario lanes have not exercised an end-to-end runbook test in the rolling twenty-four months, and what is the next tabletop selection consequence.

How the package pairs with SecPortal

The template above is copy-ready as a standalone artefact. If your team already runs incident records, document custody, and finding tracking on a workspace, the runbook execution becomes a byproduct of the work rather than a separate evidence project. SecPortal pairs every runbook activation to a versioned engagement record through engagement management, so the scenario class, the activation criteria record, the participant list, the decision register, and the framework expectations the runbook evidences live alongside the rest of the engagement record rather than scattered across a chat channel, a wiki page, and a shared drive.

The document management feature holds the runbook itself, the captured evidence pack, the closure record, the post-incident review draft, and every prior runbook version retained per the audit evidence retention policy. Access to each document is gated by role-based access control through team management and protected by multi-factor authentication. The activity log captures the timestamped chain of state changes by user with 30, 90, or 365-day retention windows depending on the plan, so the activation event, the severity reclassifications, the destructive containment authorisations, the evidence checkpoint confirmations, the communication releases, and the closure sign-off are all observable rather than asserted. The notifications and alerts feature dispatches the contact-tree pages from Section 3 with the same audit trail.

Action items emerging from the response live alongside vulnerability findings on the same workspace through findings management, each carrying a CVSS-aligned severity, a named owner, a target close date, and an evidence-of-closure requirement. The compliance tracking feature maps the runbook execution and the closure record to ISO 27001, SOC 2, Cyber Essentials, PCI DSS, and NIST frameworks with CSV export, so when an auditor asks how the firm runs a ransomware response, a cloud control plane compromise, or a customer data breach, the runbook version, the activation record, the timeline, the evidence pack, the closure record, and the after-action report are one query against the same data. The AI report generation workflow produces a draft after-action report and a leadership summary from the same engagement data so the audit committee read of incident response performance and the operational read are the same record rather than two independently edited documents that diverge between reporting cycles.

For the operational workflow that runs incidents day to day, see the incident response use case. For the parallel disclosure-side workstream, see the breach notification and regulator readiness workflow. For the cadence vehicle that tests the runbook, see the tabletop exercise template and the tabletop exercise guide. For the underlying plan, see the incident response plan guide and the enterprise incident response at scale guide. For the wider continuity and recovery programme the per-scenario runbook sits inside, see the business continuity and disaster recovery plan template that carries the BIA, the RTO and RPO commitments per tier, the recovery strategy per tier, the backup immutability rule, the exercise cadence, and the framework crosswalk the runbook portfolio reads against. For the international standard the live-incident workflow reads against, see the ISO/IEC 27035 framework page. The compliance anchors live alongside their parent framework pages in ISO 27001, SOC 2, PCI DSS, and NIST SP 800-53. SecPortal does not run the live incident, execute the containment actions, drive the telemetry collection, or operate the regulator notification on the firm's behalf. The responders run the response; the runbook codifies the procedure; SecPortal carries the durable workspace record the response runs against and the audit reads after.

Buyer and operator pairing

The runbook portfolio is the procedural backbone internal security teams, security operations leaders, security engineering teams, GRC and compliance teams, vulnerability management teams, and CISOs and security leaders run when an incident response capability has to survive a regulator inquiry, an audit, an insurance claim, and a board review at the same time. External providers (virtual CISOs, managed security service providers, compliance consultants) use the same package to give clients a per-scenario operational procedure that meets framework expectations rather than a one-page playbook fragment per client.

Loading tool...

Related features

Orchestrate every security engagement from start to finish

Document management for every security engagement

Vulnerability management software that tracks every finding

Every action recorded across the workspace

Compliance tracking without a full GRC platform

Collaborate across your entire team

Multi-factor authentication on every workspace

Notifications and alerts for the people who carry the work

AI-powered reports in seconds, not days