Incident Response Playbook vs Runbook: Decision Logic, Execution Steps and When to Use Each

Most incident response libraries fail not because they are missing documents, but because playbooks and runbooks are mixed together, so the decision logic is buried in command steps and the command steps go stale inside documents nobody tests. A playbook tells responders what to decide and in what order for a type of incident; a runbook tells one operator exactly how to carry out one task. The terms are used inconsistently across vendors, SOAR products and site reliability teams, which makes the confusion worse. This guide compares the two on audience, granularity, automation fit and maintenance, shows how they link, and gives a worked example. It is for SOC leads, incident managers, detection and automation engineers and anyone rebuilding an incident response document library. For a full identity incident playbook, see the Identity Incident Response Playbook.

Key takeaways

• Short answer: a playbook holds the decisions for an incident type (triage questions, branches, escalation, who to tell); a runbook holds the exact, repeatable steps for one task (revoke sessions, isolate a host, rotate a key).
• They are linked, not alternatives: AWS describes playbooks as investigating and identifying a root cause, then pointing to a runbook that resolves it.
• Runbooks automate first: fixed inputs and deterministic steps suit SOAR or scripted automation; playbook branches that need judgement stay human or gain approval gates.
• Terminology is not standard: in SOAR products and CACAO a "playbook" is an executable workflow, and Google SRE calls its on-call procedures playbooks, so define both terms in your incident response plan.
• Staleness is the main failure: runbooks break when systems change, playbooks break when the organisation changes; each needs its own owner, trigger for review and test cadence.

Definitions from the primary sources

• NIST SP 800-61 Rev. 3 (April 2025): many organisations create playbooks as part of documenting procedures; playbooks provide actionable steps or tasks for people to perform during various scenarios, and formatting procedures as a playbook can improve usability. NIST also says procedures should be based on the incident response policy and plan, and can be tested or exercised periodically to verify accuracy and train new staff. See the NIST SP 800-61 Incident Response Guide.
• NCSC incident management guidance: a playbook is a detailed response plan, usually focused on a specific incident type. The NCSC advises starting with the three to five most likely and damaging incident types and, at minimum, documenting the first few hours: who to contact, how to triage, how to contain and how to preserve evidence.
• AWS Well-Architected, Operational Excellence: a runbook is a documented process to achieve a specific outcome, at its simplest a checklist to complete a task (OPS07-BP03). Playbooks are step-by-step guides used to investigate an incident, scope impact and identify a root cause, and should point to the runbook that resolves it (OPS07-BP04).
• OASIS CACAO Security Playbooks v2.0 (Committee Specification 01, 27 November 2023): a playbook is a workflow for security orchestration containing a set of steps. In this machine-readable sense a CACAO playbook can contain both decision branches and execution steps. See the OASIS CACAO Security Playbooks Standard Guide.
• Microsoft incident response playbooks: each contains prerequisites (logging and permissions needed), a workflow, a checklist matching the workflow steps, and detailed investigation steps, which is a playbook with runbook-level detail attached.

The working definition used on this page: playbook = decision logic for an incident type; runbook = execution steps for a task. Whatever names you choose, the separation is what matters.

Side-by-side comparison

The playbook in depth

What it protects against: poor decisions under pressure. The risks a playbook manages are escalating too late, containing too early (alerting the attacker or destroying evidence), forgetting a regulatory clock, and different shifts treating the same incident differently.

Structure that works:

1. Trigger and scope: the detections, reports or alerts that start this playbook, and what is out of scope (with a pointer to the right playbook).
2. Triage questions: five to ten questions answered in the first 30 minutes, for example: is the account privileged, was MFA satisfied, is there evidence of data access, is the activity ongoing?
3. Severity and escalation: criteria that map answers to a severity level, mapped to CSF 2.0 RS.MA-03 (categorise and prioritise) and RS.MA-04 (escalate as needed).
4. Decision points: each branch named, with who decides and the evidence needed, for example "contain now or observe" or "reimage or preserve".
5. Linked runbooks: each action references a runbook ID rather than containing the steps.
6. Evidence to preserve: what to capture before containment, aligned with RS.AN-07 (incident data collected with integrity and provenance preserved).
7. Notification triggers: who must be told and the rule that drives it, per RS.CO-02.
8. Exit and recovery criteria: when the incident moves to recovery (RS.MA-05) and when it closes.

Controls: sign-off by legal and the business for notification and containment authority; version control with a changelog; an owner and a review date on the first page.

The runbook in depth

What it protects against: execution errors. A tired analyst disabling the wrong account, revoking a key without knowing which workloads use it, or forgetting to verify that a session token was actually revoked.

Structure that works: AWS's runbook template is a good minimum: ID, description and desired outcome, tools used, special permissions, author, last updated and escalation contact, followed by numbered steps. For incident response add:

• Preconditions: what must be true before starting (for example, memory captured, change approval obtained for production).
• Inputs and validation: exactly which identifiers the operator needs, and checks that the target is correct and not on a protected list.
• Verification step: how to prove the action worked, such as confirming a sign-in attempt now fails or a host shows as isolated.
• Rollback: how to reverse the action if it was wrong.
• Error handling: what to do when a step fails, and when to stop and escalate.
• Audit record: what to write in the case: runbook ID and version, operator, time, target and result.

Controls: least privilege for the permissions listed, so the runbook does not become a reason to give every analyst global admin; peer review of changes; and a test against a non-production object after any system change. The SOC Runbook Template gives a ready structure.

Where identity fits: many incident runbooks touch credentials: disabling users, revoking refresh tokens, rotating API keys and service account secrets. These are the runbooks most likely to break production if the operator does not know where a credential is used. Pair them with a credential inventory, and see the Secrets Rotation Runbook Template and the Enterprise Credential Reset Runbook Template.

Automation fit: what to hand to SOAR and what to keep human

Automation sits naturally at the runbook layer. AWS recommends building a runbook and playbook library first and then automating it, keeping automation and documents in sync. In SOAR products the word "playbook" usually means the executable workflow, which is effectively an automated runbook with some branching. The SOAR and Security Automation Guide covers engineering rules for those workflows.

CACAO treats a manual step as a first-class command type, which is a useful model: an automated workflow can hand a step to a human and resume, rather than forcing everything to be either fully automated or fully manual. Automation also creates a privileged identity that attackers target; see Securing the SOAR platform itself and the Runbook Automation Security Guide. Where AI agents are taking on triage, the AI SOC Agents vs SOAR Playbooks explains which decisions they can safely make.

How detailed should an incident response playbook be?

• Enough to decide, not to execute: if a playbook step contains a console path or a command, move it to a runbook and link it.
• The first hours in detail: following the NCSC advice, the first few hours deserve the most precise guidance because that is when pressure is highest.
• One flowchart per playbook: a responder should see the branches on one page; detail lives behind each box.
• Checklist alongside the flow: Microsoft's pattern of a checklist matching the workflow steps helps regulated organisations show what was done.
• Not a substitute for judgement: Google's SRE book reports that recording best practice in advance in a playbook produced roughly a threefold improvement in mean time to repair compared with improvising, while also warning that no playbook replaces engineers able to think on the fly.

Worked scenario: leaked cloud access key

Playbook: credential exposure. Trigger: a secret scanning alert reports a cloud access key in a public repository. Triage questions: is the key active, which identity owns it, what permissions does it carry, has it been used from unfamiliar addresses since exposure? Decision point 1: if the key is active and highly privileged, severity is high and the incident lead is paged. Decision point 2: if audit logs show use from unknown sources, switch to the cloud compromise playbook and engage forensics. Notification: data protection lead informed if the identity can read personal data. Exit: key revoked, replacement deployed, no further unauthorised calls for an agreed period.

Runbooks it calls:

1. RB-ENR-04, identify key owner and usage: query the identity and access console and audit logs for the key ID, list services using it. Fully automated.
2. RB-EVD-02, preserve audit logs: export the relevant audit log window to protected storage with hashes recorded. Automated.
3. RB-CRD-07, deactivate and rotate access key: create replacement, update the consuming workload's secret store, deactivate the old key, verify a call with the old key fails, then delete after the observation period. Automated behind approval, because a wrong rotation can break production.
4. RB-REP-01, remove secret from repository history: owned by the engineering team, manual with peer review.

The playbook stays valid when the cloud console changes; only RB-CRD-07 needs updating. Detailed versions exist in the Cloud Access Key Leak Playbook and the API Key Leak Response Playbook.

When to use each

• Write a playbook when: an incident type needs decisions by several roles, involves notification or legal questions, or has caused inconsistent handling before. Start with the three to five most likely and damaging types.
• Write a runbook when: a task is repeated, has a clear outcome, needs specific permissions or tools, or would cause damage if done wrongly. AWS suggests starting with tasks that are semi-regular, short and low-impact on failure.
• Small organisations: start with an incident response plan, three playbooks and the ten runbooks those playbooks call most. A retainer provider can supply forensic runbooks. See the Incident Response Plan Template.
• Large organisations: maintain a catalogue with IDs, owners and review dates; playbooks owned centrally, runbooks owned by platform teams; automation engineers turn mature runbooks into SOAR workflows.
• Regulated organisations: keep human-readable versions of every automated workflow so auditors and responders can see what the automation does.

Building or refactoring the library, step by step

1. Inventory: list every existing document and classify each section as decision logic or execution steps.
2. Define terms: write the playbook and runbook definitions into the incident response plan, including what your SOAR product calls them.
3. Split: move execution detail out of playbooks into runbooks with IDs; replace it with a reference.
4. Assign owners: playbook owners in incident response, runbook owners in the teams that run the systems.
5. Test: run each playbook in a tabletop and each runbook against a test object. The Tabletop Exercise Guide covers exercise design.
6. Automate in rings: enrichment first, then evidence capture, then reversible containment with approvals; keep the manual runbook as fallback and rollback path.
7. Link to detections: as AWS advises, put a pointer to the playbook inside each alert so responders open the right one.
8. Review on triggers: after every major incident and exercise, and whenever a system, API or permission model changes.

Detection and measurement

• Coverage: percentage of high-severity detection rules that link to a playbook.
• Freshness: percentage of runbooks tested since the last change to the system they touch; percentage of playbooks exercised in the last 12 months.
• Execution failures: runbook runs that failed or needed improvisation, from case records; each one is a maintenance ticket.
• Automation share: proportion of runbook executions done by automation, and the rollback rate of automated actions.
• Decision timing: time from incident declaration to each playbook decision point, compared across incidents. See MTTD vs MTTR.

Common failure patterns

• The 40-page playbook: decisions and commands mixed together, so nobody reads it under pressure and every console change makes it wrong.
• Runbooks drifting from systems: AWS lists runbooks drifting out of sync with system changes and automation as an anti-pattern; steps that worked last year fail mid-incident.
• Automating decisions, not tasks: SOAR workflows that isolate or disable automatically without protected-asset lists or approval for critical systems.
• Untested rollback: Google's SRE emergency response chapter describes untested rollback procedures that were flawed and lengthened an outage; incident runbooks need the same testing.
• No evidence step: containment runbooks that reboot or reimage before evidence capture, because the playbook never stated what to preserve first.
• Terms undefined: one team's "playbook" is another team's "runbook", so responders open the wrong document. Define both in the plan.

Framework mapping

Practitioner checklist

• Define playbook and runbook in your incident response plan, including SOAR terminology.
• Keep playbooks to decisions, escalation, evidence and notification; move commands into runbooks.
• Give every runbook an ID, owner, permissions list, verification step and rollback.
• Cover the first hours of your three to five most likely and damaging incident types first.
• Automate enrichment and evidence capture before containment; put approvals on critical assets.
• Test runbooks after every relevant system change and exercise playbooks at least yearly.
• Link each high-severity alert to its playbook.
• Track coverage, freshness, execution failures and automation rollback rate.

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NCSC: Cyber incident response processes
• OASIS: CACAO Security Playbooks Version 2.0
• CISA: Federal Government Cybersecurity Incident and Vulnerability Response Playbooks
• AWS: Well-Architected OPS07-BP03 Use runbooks to perform procedures
• AWS: Well-Architected OPS07-BP04 Use playbooks to investigate issues
• Microsoft: Incident response playbooks
• Google: Site Reliability Engineering, Introduction

Related NHI Mgmt Group resources: Identity Incident Response Playbook · SOC Runbook Template · SOAR and Security Automation Guide · Incident Response Guide