Incident Phase Playbook¶
Procedure — instantiates Phase-Specific Intervention
Implements the archetype by using different response modes for detection, containment, stabilization, recovery, communication, postmortem, and prevention phases.
An Incident Phase Playbook sequences the temporal phases of one unfolding event — detect, contain, eradicate, recover, learn — and gives each phase its own written response mode, its own owner, and its own signal for when it is over. Its defining move is the handoff: as an incident moves from "stop the bleeding" to "restore service" to "make sure it never recurs," the goal, the decision-maker, the tempo, and the definition of success all change, and the playbook makes those transfers of authority explicit rather than letting one improviser carry the whole event. Where a checklist lists steps, the playbook is organized by phase-of-the-incident: it knows that a containment action taken during recovery is a mistake, and it captures the transition boundaries — the observable signs that it is time to switch modes — so the response never stays locked in an obsolete phase.
Example¶
At 02:14 a monitoring alert fires: an internal database is exfiltrating traffic to an unknown host. The on-call engineer opens the security incident playbook. Detection phase: confirm it is real, not a false positive, and declare an incident — the boundary indicator here is a validated indicator-of-compromise, which flips the team into containment. Containment has its own owner (the incident commander) and its own mode — isolate the host, revoke credentials, preserve forensic images — and it explicitly forbids the tempting "just reboot and move on," because that would destroy evidence needed later. When the bleeding stops (no new malicious connections for a defined window), the playbook signals the boundary into eradication and recovery, and authority hands off: the commander passes rebuild decisions to the service owner, who restores from clean backups and validates integrity before reopening traffic. Only when service is stable does the incident enter its postmortem phase, where a blameless review captures what the detection missed and what the containment did well, and writes those lessons into the playbook so the next incident starts smarter. The whole arc follows a recognized incident-handling lifecycle.[n1]
How it works¶
- One mode per phase. Each phase carries its own runbook — its objective, its permitted actions, its comms cadence — so responders aren't guessing which behavior fits the moment. Containment optimizes for stopping harm; recovery optimizes for safe restoration; these are deliberately different.
- Boundary signals, not clocks. Transitions fire on observable conditions (IOC validated, no-new-activity window elapsed, service health green), not on elapsed time, so the response advances when the incident actually changes state.
- Explicit handoffs. At each boundary the playbook names who now holds authority, what they inherit, and what the outgoing owner must hand over — preventing both dropped context and two people commanding at once.
- Postmortem into memory. The learning phase writes findings back into the playbook, so recurring failure modes update the procedure rather than being re-discovered every incident.
Tuning parameters¶
- Phase count — coarse (contain / recover) or fine (detect / triage / contain / eradicate / recover / harden). More phases sharpen mode-fit but multiply handoffs and coordination overhead.
- Transition thresholds — how strong a signal must be to advance a phase. Loose thresholds risk premature de-escalation (declaring "recovered" while the attacker still holds access); tight ones strand the team in emergency mode.
- Handoff formality — a logged, acknowledged transfer versus a verbal nod. Formality preserves continuity under stress but slows fast-moving incidents.
- Postmortem depth — a quick retro versus a full root-cause analysis. Depth improves the memory but competes with getting people back to sleep.
When it helps, and when it misleads¶
Its strength is that it stops "stale emergency mode" — teams grinding on containment long after the threat is gone — and it prevents the opposite error of declaring victory before the incident is actually contained. Clean handoffs keep a long incident from collapsing onto one exhausted person, and the postmortem loop turns each event into a better procedure.
Its central failure mode is the stale playbook: a runbook written for last year's architecture that the team follows on autopilot into the wrong action, trusting the document over the room. The classic misuse is treating the phases as a rigid script and forcing a novel incident through boilerplate phases that don't fit it — over-fragmentation that adds ceremony without adding control. The guarding discipline is to let the postmortem memory actually rewrite the playbook, to keep an exception path for incidents the model doesn't recognize, and to treat boundary signals as evidence to be checked, not boxes to tick.
How it implements the components¶
phase_playbook— the per-phase runbooks (detect / contain / recover / learn), each with its own objective and permitted actions.transition_boundary_indicator— the observable signals (validated IOC, no-new-activity window, service-health green) that mark when to switch modes.phase_handoff_rule— the explicit transfer of authority and context from on-call to commander to service owner as phases change.phase_transition_memory— the postmortem findings written back into the playbook so recurring failures improve the procedure.
It does not implement action_by_phase proportioning or a phase_contraindication_map of therapies by clinical stage — that's Disease-Stage Treatment Protocol; nor mixed_phase_segmentation to route audiences by their phase — that's Stage-Specific Communication Plan. It sequences temporal phases of one event; it does not grade a standing severity tier — that's the adaptation_rule-driven dialing in Escalation/De-escalation Matrix.
Related¶
- Instantiates: Phase-Specific Intervention — supplies the phase-sequenced response core for incident management.
- Consumes: Escalation/De-escalation Matrix — within the containment phase, the playbook calls the severity matrix to size the response tier.
- Sibling mechanisms: Disease-Stage Treatment Protocol · Stage-Specific Communication Plan · Ecological Phase Management · Education Scaffolding by Stage · Product Lifecycle Strategy · Lifecycle-Stage Policy · Market Regime Strategy · Maturity Model Guidance
Editorial Notes¶
Form Classification¶
Form family: Protocol, Workflow & Routine
Rationale: Incident Phase Playbook operates as a repeatable ordered procedure or handoff sequence that coordinates action because it implements the archetype by using different response modes for detection, containment, stabilization, recovery, communication, postmortem, and prevention phases
Independent corroboration: The frozen evidence defines Incident Phase Playbook as 'Implements the archetype by using different response modes for detection, containment, stabilization, recovery, communication, postmortem, and prevention phases', so its operative form is Protocol, Workflow & Routine.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: The preparation-detection-containment-eradication-recovery-postincident lifecycle is canonically codified in NIST computer-security incident handling.
Related originating lineages:
- Disaster Management & Risk Reduction — Emergency-management lifecycles independently structure response by temporal phase.
- Security Studies & Intelligence Analysis — Cyber threat response materially supplies detection, containment, and eradication phases.
Review resolution: Both reviewers independently assign computer_science as the primary originating domain, so that shared primary is retained. Alternate domains are the union of reviewer-identified formative or independently originating lineages; later application settings alone are excluded. The evidence describes one principal historical lineage. It has established independent use across several domains, but that does not make it domain-free. The encyclopedia entry generalizes the established mechanism without creating a new composite lineage.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] The widely used incident-handling lifecycle — preparation, detection & analysis, containment / eradication / recovery, and post-incident activity — codified in NIST Special Publication 800-61, the U.S. federal Computer Security Incident Handling Guide. It is the canonical example of a response organized by temporal phase rather than by a single flat checklist. ↩