---
{
  "title": "Incident playbooks",
  "summary": "Turn a recurring incident pattern into an adaptable response guide.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    2
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Incident Response Recommendations, SP 800-61 Rev. 3",
      "url": "https://csrc.nist.gov/pubs/sp/800/61/r3/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## A guide for decisions under pressure

An incident playbook describes how an organization handles a recurring incident pattern. It identifies triggers, initial questions, evidence sources, responsibilities, response options, and escalation points. Its purpose is to make coordinated action easier when time and attention are limited.

A playbook is most useful when it explains decisions and boundaries, rather than presenting a long command list. The same alert can occur on a test laptop, a production server, or a privileged administrator account. Those situations may require different authority, evidence preservation, and operational precautions.

## Design one around mailbox compromise

For a fictional academy, a mailbox playbook begins with reports of unexplained messages or forwarding rules. Initial tasks identify the mailbox, obtain the report through a trusted channel, and preserve relevant account and mailbox events. The playbook lists where those records are found and which permissions are required.

A decision point asks whether there is evidence of ongoing unauthorized access. Available actions might include restricting sign-in, revoking sessions, reviewing registered authenticators, and removing unauthorized forwarding. Each action has an owner and a note about its expected effect. Resetting a password should not be presented as a universal way to invalidate every session or connected application.

Another branch addresses possible exposure of sensitive correspondence. The investigator determines which records can show access or forwarding and involves the appropriate privacy or business owner. The playbook should direct legal or notification questions to qualified responsible people rather than inventing a single deadline for every jurisdiction.

## Make prerequisites visible

Record the tools, log coverage, retention, contact details, and approval arrangements the process depends on. An instruction to retrieve an event is ineffective if nobody on the response shift has the necessary access. Include alternatives when a source is unavailable and state what uncertainty that creates.

Separate low-impact information gathering from disruptive actions requiring specific authority. Where automation is used, document its scope, stop conditions, and audit trail. [[soar]] can execute repeatable steps, but it cannot compensate for an ambiguous decision rule.

## Exercise and revise

Run a tabletop with a small group. Begin with one suspicious message, then introduce a privileged account or a missing log source. Observe where the team hesitates, duplicates work, or assumes another person owns a decision.

Turn those findings into concrete revisions: a clearer escalation contact, a tested query, an added dependency, or a better recovery check. Assign a review owner and revisit the playbook after relevant service or process changes.

For practice, write a one-page playbook with three decision points and no product-specific commands. A colleague should be able to explain when to escalate, what evidence to preserve, and who can authorize [[containment]]. Connect the guide to [[incident-response]] and [[incident-reporting]] so execution and handover stay aligned.

## Related concepts

- [[tabletop-exercises]]