Incident Playbooks

An unapproved artifact is running in production. The release identity that admitted it has also read an export credential, and the workload has begun scanning tenant records. Chapter 44 established command, severity, evidence handling, and communication. Those arrangements answer who decides. They do not tell the technical lead whether to suspend the identity, isolate the workload, protect the logging account, or preserve the artifact first.

That is the playbook’s job. A playbook makes the first hour executable for a recognizable class of incident. It names the evidence likely to disappear, the containment moves available, the approvals that destructive actions require, and the observations that make recovery trustworthy. It cannot make the incident routine. Its value is that responders spend scarce judgment on the facts that are different this time instead of reconstructing the response from memory.

How to use a playbook

Select the playbook from observed behavior, not an early root-cause theory. The release incident begins with the supply-chain playbook because artifact provenance and the build path are in doubt. If investigation confirms that the release identity was stolen, run the credential-compromise actions as a linked workstream. If tenant data left the service, add the data-exposure workstream. One incident may need several playbooks under one commander and one timeline.

The first fifteen actions in each playbook are ordered, but they are not a single-file queue. The commander assigns evidence preservation, scope, containment, customer-impact analysis, and communications in parallel. An urgent action may move forward when delay would extend harm. Record who authorized the change, what evidence could be lost, and why the delay was unacceptable.

Before using these playbooks, replace generic names with the organization’s actual systems and owners. Record the identity provider, cloud organizations, protected logging and backup accounts, evidence repository, isolation mechanisms, legal and privacy contact path, customer-support owner, status-page owner, and recovery authorities. Test access to them from the degraded conditions the playbook anticipates.

Credential compromise

Use this playbook when a user, administrator, API key, workload identity, or service account may be controlled by someone unauthorized. Privileged access, security-control changes, active lateral movement, or sensitive-data access normally requires at least a dedicated response and may justify the highest severity. A low-privilege account with no observed misuse can begin as a managed investigation only if the team sets an escalation deadline.

First fifteen actions

1. Open the incident record and name a commander, identity lead, evidence owner, and customer-impact owner.
2. Record the signal, affected identity, observed time, source, current privilege, and systems it can reach.
3. Preserve authentication, token, MFA, directory, privilege-change, and conditional-access logs; extend retention.
4. List active sessions, refresh tokens, API keys, certificates, application passwords, and delegated grants.
5. Identify recent logins, devices, source networks, geographies, and authentication methods without treating anomaly alone as proof.
6. Find role assignments, group changes, consent grants, new credentials, and policy changes made by the identity.
7. Scope resource, data, secret, code, pipeline, and administrative actions since the earliest plausible compromise.
8. Protect identity logging, break-glass accounts, backup administration, and other control planes from the suspected identity.
9. Decide whether immediate revocation is necessary; record the operational and evidence consequences.
10. Revoke sessions or disable credentials through a trusted administrator path when continued access presents material risk.
11. Isolate affected workloads or devices if revocation does not remove their authority or persistence.
12. Search for copied credentials, registered MFA methods, malicious federation, mailbox rules, scheduled jobs, and other persistence.
13. Start customer and data impact analysis for every sensitive resource the identity could access.
14. Notify the identity owner and required security, legal, privacy, service, or leadership contacts through an approved channel.
15. Set the next command checkpoint with owners for scope, persistence, containment, and communication questions.

Preserve the raw identity events, token and key metadata, directory and policy changes, affected-device or workload telemetry, relevant resource audit logs, and the exact revocation actions. Do not reset MFA, delete keys, or wipe a device before capturing their identifiers and history unless the delay keeps dangerous access alive.

Eradication removes malicious grants, federation, forwarding rules, registered factors, keys, scheduled access, and any vulnerability that exposed the credential. Reissue access through a verified identity and trusted device; do not send replacement secrets over a channel the attacker may control. Recovery requires clean authentication, reviewed privileges, no unexplained sessions, healthy identity telemetry, and monitoring for replay or movement into related accounts.

Tell affected service owners what authority may have been used and what remains unknown. Bring legal or privacy into decisions about personal or customer data; do not infer that absence of a download event proves absence of access. Afterward, improve credential lifetime, phishing resistance, privilege boundaries, secret detection, session revocation, and alert-to-resource correlation according to the path actually used.

Cloud account compromise

Use this playbook for unauthorized console access, unexpected keys or role assumptions, privilege escalation, public resource creation, logging changes, or unusual data movement in a cloud environment. Loss of an organization, identity, logging, key-management, or backup control plane is a severe event even before workload impact is known.

First fifteen actions

1. Declare the incident and assign cloud, identity, evidence, communications, and customer-impact owners.
2. Record affected accounts, subscriptions or projects, organizations, regions, principals, and the earliest suspicious event.
3. Preserve organization, control-plane, identity, network, object-access, key-management, and billing logs; extend retention.
4. Verify that audit trails, log destinations, security services, and their encryption keys are still trustworthy.
5. Protect or isolate dedicated logging, security, backup, DNS, registry, and identity accounts from the suspected path.
6. Enumerate recent role assumptions, keys, policies, trust changes, federation changes, and organization-level actions.
7. Identify created or altered compute, functions, containers, storage, network paths, snapshots, secrets, and persistence mechanisms.
8. Scope data reads, copies, snapshots, exports, replication, and outbound transfer from affected resources.
9. Preserve configuration, metadata, snapshots, and volatile state for suspect workloads before termination where feasible.
10. Choose the narrowest containment that stops material harm: revoke a session, disable a key, deny a role, quarantine a workload, or restrict egress.
11. Apply an organization or service-control deny only with an owner who understands the possible production blast radius.
12. Block new deployments or administrative changes through the compromised path while retaining a trusted recovery path.
13. Start service, customer, data, financial, and regulatory impact analysis.
14. Publish an internal update that separates confirmed actions from resources still being enumerated.
15. Set the next checkpoint around control-plane trust, persistence, data movement, and recovery authority.

Do not delete compromised resources merely to make the console look clean. Preserve policies, trust relationships, tags, disks, images, runtime identity, network state, and audit references. Keep evidence in an account outside the suspected blast radius.

Eradication removes unauthorized identities, roles, policies, resources, images, startup mechanisms, network paths, and stolen secrets, then closes the entry path. Recover affected workloads from trusted templates and artifacts. Recovery is earned when the organization hierarchy, IAM baseline, logging, key management, backups, network exposure, workloads, and data paths have been independently compared with known-good state and new detections cover the observed path.

Communications should state which cloud boundaries are confirmed affected and which are still being tested. Billing anomalies and resource creation may reveal scope but do not substitute for access analysis. Improvements often belong in organization guardrails, protected audit storage, short-lived workload identity, account vending, infrastructure drift detection, and rehearsed control-plane recovery.

Data exposure

Use this playbook for public storage, broken authorization, misrouted messages or exports, tenant-isolation failure, log leakage, or suspicious bulk access. Severity follows the sensitivity, subjects, volume, reachability, duration, evidence of access, and ability to stop further disclosure—not the storage technology involved.

First fifteen actions

1. Declare the incident and assign technical, evidence, data-impact, legal/privacy, communications, and customer-support owners.
2. Record the exposed system, data path, discovery source, earliest plausible exposure, and current accessibility.
3. Stop continuing exposure with the narrowest safe control, such as removing a public policy, disabling a link, or closing an affected route.
4. Preserve access, authorization, application, storage, delivery, cache, search, database, and network logs; extend retention.
5. Preserve the exposed object’s metadata, policy, version, location, hash, and replication state without creating another uncontrolled copy.
6. Identify data classes, fields, jurisdictions, tenants, customers, employees, or other subjects represented.
7. Determine who or what could reach the data, including anonymous users, authenticated roles, crawlers, caches, recipients, and downstream processors.
8. Query actual reads, listings, downloads, exports, sends, shares, and copies while documenting known logging gaps.
9. Check replicas, backups, indexes, previews, search caches, analytics stores, email systems, and third-party destinations.
10. Preserve the faulty authorization decision, configuration, code version, deployment, and relevant negative-test results.
11. Prevent recurrence in the active path without deleting evidence needed to establish scope.
12. Begin the authoritative affected-population list and record the query, time range, exclusions, and reviewer.
13. Ask legal and privacy owners to assess contractual, regulatory, and notification duties from the known facts.
14. Prepare customer-support and leadership holding language that makes uncertainty explicit.
15. Set the next checkpoint for exposure closure, access evidence, affected population, and notification decisions.

The exposed data itself is sensitive evidence. Minimize copies, restrict the evidence repository, and record every export made for analysis. A missing log can bound neither access nor impact; report the gap and use adjacent evidence such as cache logs, object version history, recipient records, or network transfer.

Eradication fixes the authorization, routing, sharing, logging, or tenancy defect and removes uncontrolled copies where the organization has authority to do so. Recovery requires negative authorization tests, deployment evidence, closed caches and replicas, verified logging, a reviewed population analysis, and owners for every notification or retention decision.

Communicate in terms of data classes, affected populations, time windows, confirmed access, plausible access, and remaining uncertainty. Avoid claiming “no exfiltration” when the team has only removed public reachability. Improvements should strengthen private defaults, object-level authorization, tenant tests, export controls, recipient confirmation, data minimization, and access-log coverage.

Ransomware or destructive attack

Use this playbook for encryption, destructive deletion, backup tampering, extortion, mass file changes, or loss of administrative control. Active destruction, compromised recovery systems, safety impact, or broad business interruption ordinarily demands the highest command level and early legal, leadership, insurer, and specialist involvement according to policy.

First fifteen actions

1. Declare severity and assign incident command, technical, security, evidence, recovery, business-priority, legal, and communications owners.
2. Record the destructive behavior, affected zones, discovery time, business services at risk, and whether activity continues.
3. Protect backup control planes, immutable copies, recovery credentials, key management, and offline recovery material.
4. Preserve representative ransom notes, binaries, alerts, identity events, endpoint telemetry, network records, and change logs.
5. Identify the earliest affected identity, host, workload, share, cluster, account, and administrative system currently known.
6. Stop propagation by pausing synchronization, replication, automation, or deployments that carry destructive changes.
7. Isolate affected segments or hosts using trusted controls; record evidence and availability consequences.
8. Disable compromised identities or network paths when delay would extend destruction.
9. Verify whether endpoint, identity, virtualization, cloud, backup, monitoring, or key-management control planes remain trustworthy.
10. Establish a clean coordination and administration environment outside the suspected blast radius.
11. Rank business services for containment and restoration using safety, customer harm, dependencies, and recovery feasibility.
12. Begin a clean-room recovery plan without attaching backups to an untrusted environment.
13. Start customer, data, contractual, safety, financial, and operational impact analysis.
14. Route extortion, law-enforcement, insurer, public, and payment questions to authorized legal and executive owners.
15. Set the next checkpoint for active destruction, protected backups, trusted administration, scope, and recovery order.

Do not wipe or reimage every affected host before preserving representative evidence and understanding the propagation path. Conversely, do not keep destructive access alive solely to improve a forensic record. The commander records that trade-off and protects people, customers, and critical systems first.

Eradication removes compromised identities, persistence, malicious automation, vulnerable entry paths, and poisoned administrative tooling. Rebuild from trusted media in an isolated environment, rotate credentials from a clean path, and validate backups before restoration. Recovery requires business-owner checks, security telemetry, segmentation, persistence testing, data-integrity checks, and a controlled reconnection plan with rollback conditions.

Updates should separate service availability, data integrity, data confidentiality, and recovery confidence. A restored server is not proof that records are complete or secrets remain confidential. Improvements may include immutable backups, separated recovery identity, restore drills, propagation brakes, segmentation, application allowlisting, endpoint coverage, and manual recovery procedures for failed control planes.

Supply-chain compromise

Use this playbook for a malicious dependency, poisoned artifact, compromised build or signing path, third-party integration compromise, or untrusted model or dataset. The unapproved release that opened this chapter belongs here first. Severity rises with distribution, execution privilege, customer reach, signing authority, downstream reuse, and loss of provenance.

First fifteen actions

1. Declare the incident and assign build, service, identity, evidence, downstream-impact, communications, and customer-impact owners.
2. Record suspect component names, versions, digests, signatures, build runs, repositories, pipelines, and release windows.
3. Stop new builds, promotions, releases, downloads, or integrations through the affected path without destroying its records.
4. Preserve source, lockfiles, artifacts, images, packages, models, datasets, manifests, attestations, signatures, and pipeline logs.
5. Preserve build-worker state and volatile evidence when feasible before recycling runners or deleting jobs.
6. Protect artifact registries, signing services, source control, secrets, audit logs, and trusted recovery branches.
7. Identify every environment, product, customer, mirror, cache, and downstream build that received the suspect material.
8. Determine whether the component executed, what identity it held, what network and data it could reach, and what it changed.
9. Enumerate recent source, workflow, dependency, permission, secret, maintainer, and signing-key changes.
10. Revoke or constrain compromised build and release credentials through a trusted administrative path.
11. Quarantine suspect artifacts by digest; do not rely only on mutable names or tags.
12. Choose rollback, feature disablement, integration isolation, or service shutdown according to active harm and known-good availability.
13. Begin customer, data, contractual, ecosystem, and downstream-impact analysis.
14. Notify affected internal consumers and prepare precise external guidance that identifies versions and digests.
15. Set the next checkpoint for distribution scope, execution evidence, build-path trust, and replacement release criteria.

Preserve the artifact as evidence even when distribution is blocked. Yanking a package, overwriting a tag, rotating a signing key, or deleting a runner can erase the link between source, build, release, and execution. Record those state changes and retain the affected provenance graph.

Eradication closes the source, maintainer, dependency, build-worker, credential, signing, registry, or integration path that admitted the compromise. Produce replacements on independently trusted infrastructure with reviewed source, pinned inputs, fresh credentials, reproducible or corroborating build evidence, and new attestations. Recovery requires confirmed removal or isolation of every affected digest, downstream verification, healthy release controls, and monitoring for the compromise’s observed behaviors.

Communications must name what is known by immutable identifier, which environments and customers are affected, and what consumers must do. Do not announce a clean version merely because it was built later. Improvements should strengthen provenance, protected workflows, maintainer security, isolated builds, secret scope, signing separation, dependency review, inventory, and the ability to recall artifacts by digest.

Web and API exploitation

Use this playbook for injection, broken access control, server-side request forgery, unsafe file handling, credential stuffing, unexpected administrative actions, or abusive export. Severity follows the reachable authority and data: cross-tenant access, control-plane reach, code execution, sensitive export, or active exploitation requires rapid escalation.

First fifteen actions

1. Declare the incident and assign application, platform, evidence, data-impact, communications, and customer-support owners.
2. Record the endpoint, method, route, actor or source, tenant context, discovery signal, and earliest suspicious request.
3. Preserve application, authorization, identity, gateway, WAF, load-balancer, database, storage, and network logs; extend retention.
4. Preserve the deployed code, configuration, feature flags, schemas, policy bundle, image digest, and release record.
5. Determine which identities, objects, tenants, internal services, metadata endpoints, files, or administrative functions the path can reach.
6. Identify observed successful requests, failed attempts, payload classes, resulting actions, and response sizes without circulating weaponized detail.
7. Check related routes, alternate methods, bulk operations, background jobs, caches, GraphQL resolvers, and administrative interfaces for the same boundary failure.
8. Apply the narrowest safe containment: disable a route, revoke a feature, tighten server-side policy, block an abusive client, or isolate the service.
9. Preserve a minimal authorized reproduction and the failing negative test before changing code when active harm permits.
10. Revoke sessions, tokens, uploads, jobs, or callbacks created through the exploit path.
11. Hunt for persistence, web shells, changed data, queued work, outbound requests, and access to secrets or cloud identity.
12. Start tenant, customer, data, integrity, and availability impact analysis from authoritative records.
13. Prepare detections for replay and variants while responders build the durable fix.
14. Give support and communications owners confirmed scope, mitigations, uncertainty, and the next update time.
15. Set the next checkpoint for exploit closure, adjacent paths, data impact, persistence, and patch validation.

Keep payloads and vulnerable reproduction details in restricted evidence, not broad incident channels. A WAF rule or source block can buy time, but neither proves the application boundary is repaired; attackers can change clients and encodings.

Eradication fixes the server-side validation, authorization, request routing, parser, upload, network, or business-logic defect and removes attacker-created state. Recovery requires code review, focused positive and negative tests, deployment evidence, data-integrity checks, secret review, healthy logs, and monitoring for both the original behavior and adjacent variants.

Customer communication should describe service and data effects, not exploit instructions. Improvements belong in threat modeling, object-level authorization tests, safe egress defaults, upload isolation, rate controls, security event schemas, and release gates that exercise the failed boundary.

Insider misuse

Use this playbook for suspicious privileged access, support-tool abuse, policy bypass, unusual export, or activity outside job responsibility. Treat the case as a security incident without assuming motive or guilt. Legal, privacy, HR, and investigation policy govern who may know, what monitoring is authorized, and when the subject may be contacted.

First fifteen actions

1. Open a restricted incident record and assign an authorized commander, evidence owner, technical lead, and legal/HR/privacy contacts required by policy.
2. Record the observed action, source, identity, privilege, affected resource, discovery time, and reason it is outside expected behavior.
3. Limit case access and communications to people with a defined investigative or decision role.
4. Preserve identity, endpoint, application, support-tool, database, export, file-access, and physical-access records as authorized.
5. Extend retention and protect logs, cases, and backups from the identity or administrative group under review.
6. Verify account ownership, role, approved duties, tickets, change windows, emergency access, and other legitimate explanations.
7. Scope objects, customers, tenants, records, secrets, systems, and administrative actions touched by the identity.
8. Identify copied, exported, printed, shared, emailed, uploaded, or removable-media destinations where evidence supports the inquiry.
9. Preserve relevant tool configuration, queries, approvals, screen or session records, and data-loss-prevention events.
10. Ask the authorized decision owner whether to monitor, reduce privileges, revoke sessions, suspend access, or isolate a device.
11. Execute containment discreetly through a trusted administrator and record employment, safety, evidence, and service consequences.
12. Check for alternate accounts, shared credentials, delegated access, API keys, scheduled exports, and colluding identities only within authorized scope.
13. Begin customer, employee, data, contractual, and regulatory impact analysis.
14. Route any contact with the subject, customers, law enforcement, or external parties through the designated authority.
15. Set the next restricted checkpoint for legitimate explanation, evidence integrity, access containment, and impact.

Do not broaden surveillance or collect personal material merely because the case is sensitive. Preserve what answers the incident questions, enforce access controls, record lawful authority and collection method, and use specialist forensic handling where employment or criminal proceedings are plausible.

Eradication removes unauthorized grants, shared access, unsafe support capabilities, scheduled exports, and control bypasses while preserving required evidence. Recovery requires reviewed privileges, trustworthy tool and audit configuration, accounted-for data, customer and legal decisions, and safeguards against retaliation or evidence tampering where relevant.

Communications are deliberately narrow. Teams outside the case receive only the operational facts they need. Improvements often include purpose-bound support access, dual approval for exports, just-in-time privilege, session recording, separation of duties, reliable break-glass review, and audit queries that distinguish authorized exceptional work from misuse.

DDoS and resource exhaustion

Use this playbook for volumetric traffic, application-layer floods, queue or connection exhaustion, expensive endpoint abuse, tenant-driven overload, or runaway AI inference cost. Severity follows customer impact, control-plane risk, cost growth, dependency failure, and whether defensive changes are harming legitimate traffic.

First fifteen actions

1. Declare the incident and assign traffic, application, infrastructure, customer-impact, communications, and evidence owners.
2. Record affected services, regions, endpoints, queues, tenants, start time, current error rate, latency, saturation, and cost rate.
3. Verify that the condition is hostile or abusive traffic rather than release failure, dependency outage, retry storm, or capacity loss.
4. Protect DNS, identity, edge, management, observability, deployment, and emergency-access control planes.
5. Preserve representative edge, gateway, application, queue, network, and cost records without trying to retain every packet.
6. Characterize sources, protocols, routes, request shapes, cache behavior, response cost, concurrency, and amplification paths.
7. Enable provider or edge mitigation and contact upstream response services through the prearranged path.
8. Rate-limit, cache, challenge, shed, or disable the most expensive abusive path with an owner watching legitimate-user harm.
9. Isolate critical queues, worker pools, databases, inference capacity, or tenants from shared exhaustion.
10. Prioritize safety-critical and contractual functions and define which degraded features may be suspended.
11. Stop retry amplification, autoscaling runaway, logging overload, and defensive rules that move saturation downstream.
12. Monitor false positives, regional effects, customer cohorts, queue age, recovery lag, and spend as controls change.
13. Prepare customer and status updates that state service impact and mitigation without exposing defensive thresholds.
14. Record every temporary bypass, limit, routing change, capacity addition, and its expiry owner.
15. Set the next checkpoint for attack pressure, customer harm, control-plane health, cost, and safe rollback.

Evidence should support cause and later tuning: representative request samples, traffic distributions, mitigation events, configuration changes, saturation metrics, cost data, and customer effects. Capturing everything can worsen the incident by exhausting storage, telemetry, or analyst capacity.

Eradication closes amplification bugs, unbounded work, missing quotas, abusive accounts, retry loops, and exposed expensive paths. Recovery requires stable service at ordinary limits, drained or deliberately discarded queues, reconciled state, verified critical functions, understood cost, and controlled removal of emergency capacity or filtering.

Tell customers what functions and regions are impaired, which work may be delayed, and when the next update will arrive. Improvements should add cost-aware rate limits, per-tenant isolation, bounded queues, graceful degradation, upstream contacts, tested edge controls, retry budgets, and observability that survives overload.

AI and LLM incident

Use this playbook when prompt injection causes unsafe tool use, prompts or logs expose sensitive data, retrieval crosses an authorization boundary, an agent identity is misused, or a model, provider, connector, dataset, or policy layer may be compromised. Treat the incident according to the authority exercised and impact produced, not according to whether the initiating content looked like “just text.”

First fifteen actions

1. Declare the incident and assign application, model, identity, evidence, data-impact, communications, and affected-tool owners.
2. Record the user, tenant, conversation or job, model and version, policy version, agent identity, tools, connectors, and observed unsafe action.
3. Disable or require human approval for the affected high-impact tool, connector, or action while preserving read-only investigation access.
4. Preserve prompts, system instructions, retrieved context identifiers, model outputs, tool requests and results, policy decisions, traces, and audit logs.
5. Preserve model, adapter, prompt-template, retrieval-index, dataset, connector, and application versions needed to reproduce the path.
6. Identify which authorization boundary failed: user-to-data, tenant-to-tenant, model-to-tool, tool-to-resource, or provider-to-system.
7. Scope every action the agent identity performed, attempted, queued, or delegated during the plausible incident window.
8. Identify sensitive content returned to users, written to logs, sent to providers, stored in memory, or passed to downstream tools.
9. Revoke exposed tokens and constrain the agent identity without rotating unrelated secrets through an untrusted workflow.
10. Remove or quarantine malicious retrieval content, connector input, plugin, model, or dataset by version while retaining evidence.
11. Stop queued autonomous work and inspect pending approvals, scheduled jobs, callbacks, and long-running tool sessions.
12. Reproduce only in an isolated environment with inert tools and synthetic or authorized data.
13. Begin user, tenant, customer, data, safety, financial, and provider impact analysis.
14. Give support, privacy, legal, vendor, and leadership owners confirmed actions, affected versions, and current uncertainty.
15. Set the next checkpoint for authorization scope, executed actions, sensitive-data flow, compromised components, and recovery tests.

Prompts and model traces can contain credentials, personal data, customer content, or attacker material. Restrict them as evidence and preserve identifiers and versions; copying raw traces into a general incident channel can repeat the exposure. Provider retention and logging may impose separate evidence and notification constraints.

Eradication repairs authorization outside the model, narrows tool schemas and identities, removes poisoned content, rotates exposed credentials, and closes unsafe autonomous paths. Prompt wording alone is rarely a sufficient security fix. Recovery requires cross-user and cross-tenant negative tests, inert-tool replay, approval enforcement, least-privilege identity, reviewed logs, verified component versions, and monitoring for related inputs and actions.

Communicate the action the system took or data it revealed, not anthropomorphic claims about what the model “wanted.” Improvements should strengthen deterministic policy enforcement, per-tenant retrieval, connector trust, provenance, output handling, tool allowlists, action previews, spend and rate limits, trace access control, and incident-capable model and prompt versioning.

Recovery is a claim supported by evidence

Across all nine playbooks, containment answers whether immediate harm has been reduced. Eradication answers whether the path and persistence have been removed. Recovery answers whether the system can resume its purpose from a state the team can defend.

Before closing a playbook, the commander should be able to point to the restored system or identity, the trusted source used to rebuild or reissue it, tests of the failed boundary, healthy logging and detection, business validation, remaining uncertainty, temporary controls and their owners, customer or legal decisions, and rollback conditions. “The alert stopped” supplies none of those facts.

After the incident, change the playbook while memory is still specific. Add the evidence source responders could not find, the authority that was ambiguous, the containment action whose blast radius surprised the team, the customer-impact query that took too long, and the recovery test that actually established trust. Then exercise the revised path under one inconvenient condition—a missing commander, delayed telemetry, unavailable identity provider, or failed collaboration system. A playbook becomes operational through those encounters, not through the completeness of its headings.