What is playbook?

What is a playbook?

In security operations, a playbook is a documented set of steps for handling one specific type of incident or alert: a reported phishing email, a lost laptop, a compromised cloud account, ransomware, a DDoS attack. It tells the responder what to check, what to do, whom to contact and what not to do, in order, so the response is fast and consistent even when the person on call is tired or new. A playbook can be a document or checklist that people follow, or a workflow that a SOAR platform executes automatically, and many are a mix of both.

What a good playbook contains

• Scope and trigger: the incident type it covers and the alert or report that opens it.
• Roles and decision authority: who leads, who may take systems offline, who approves contact with outside parties.
• Ordered steps: triage, containment, evidence collection, eradication and recovery actions for that incident type.
• Decision points: branches such as "if more than one host is affected, escalate to SEV-1."
• Do-not steps: warnings such as "do not power off the host" that protect evidence.
• Communication and escalation: contacts, channels, and when to bring in legal, HR, the insurer or law enforcement.
• Ownership and version: an owner, a revision number and the date it was last tested.

Example: a compromised mailbox playbook

A condensed playbook for a user account taken over through phishing might read:

1. Confirm the alert: review sign-in logs for unfamiliar locations, devices or impossible travel.
2. Revoke all active sessions and refresh tokens, then reset the password.
3. Find and remove attacker persistence: new MFA methods, inbox forwarding or deletion rules, and OAuth app consents.
4. Search mail logs for messages the account sent during the compromise and quarantine any phishing it sent internally.
5. Preserve the sign-in and audit logs for the investigation.
6. If the mailbox held regulated data, notify the privacy officer to assess breach reporting duties.
7. Re-enroll the user in phishing-resistant MFA and close the ticket with a summary.

Steps 1, 2 and 4 are easy to automate. Step 6 needs human judgment, which is why many playbooks mix automated and manual steps.

Playbook vs. runbook vs. incident response plan

• Incident response plan: the overall program document. It defines what an incident is, severity levels, team roles and authority, and communication rules. It is broad on purpose.
• Playbook: the steps for one incident type, following the plan's structure.
• Runbook: usually the detailed technical procedure for one operational task, such as restoring a database from backup or isolating a host in the EDR console. A playbook step may point to a runbook.

Organizations and vendors use playbook and runbook loosely, and some treat them as synonyms. Judge an exam question by what the document describes, not by its label.

Keeping playbooks useful

A playbook nobody has exercised is an assumption. Teams test playbooks in tabletop exercises and simulations, update them after every real incident during the post-incident review, and check that contact numbers, tool steps and decision authority are still correct. An automated playbook also needs guardrails, such as human approval before actions that lock users out or take systems down.

Playbook on the CompTIA Security+ exam

On SY0-801, playbooks are part of objective 4.7, where they are written during the preparation phase of incident response, and objective 4.6, where SOAR platforms run them automatically. A question asking for step-by-step guidance on handling a specific incident type, or for a way to make every analyst respond to the same alert the same way, points to a playbook. The tempting wrong answer is the incident response plan, which sets the overall framework but not the steps for one scenario. A policy is also wrong, because it states rules and intent rather than procedures. If the scenario stresses running the steps automatically across tools, the answer is a SOAR playbook.