Continue your mission
A practical reference for designing, building, and operating security automation playbooks. Covers four canonical playbook designs (phishing triage, endpoint isolation, account compromise, and vulnerability notification), including error handling, escalation logic, and audit requirements.
A security automation playbook is a documented, executable workflow that defines exactly what a security system should do when a specific type of event occurs. The playbook encodes analyst decision logic, tool interactions, escalation criteria, and audit requirements into a repeatable process that can run without human intervention for deterministic scenarios and route to human analysts when conditions exceed defined thresholds.
The word "playbook" is borrowed from American football, where it refers to a collection of pre-rehearsed plays called based on situation. The analogy holds in security: playbooks are prepared in advance for known scenarios so that when those scenarios materialize, the team executes a practiced response rather than improvising under pressure.
What distinguishes a security automation playbook from a simple script is its structure. A script executes linearly. A playbook includes branching logic (if the URL is malicious, do X; if benign, do Y; if the API call fails, do Z), error handling at every step, escalation paths that transfer control to human analysts when automated confidence is insufficient, and comprehensive audit logging that records every action taken, every decision made, and the data that drove each decision.
Well-designed playbooks are the difference between a SOC that processes 200 phishing cases per shift and a SOC that drowns in them. They are also one of the most auditable artifacts in a security program: because every automated action is logged with inputs, outputs, and timestamps, playbooks provide a verifiable chain of custody for incident response actions that satisfies both internal audit requirements and external compliance frameworks.
---
Every well-structured security automation playbook has six components.
Trigger definition: The precise condition that starts playbook execution. This could be an alert from a SIEM rule, an EDR detection, an email security gateway event, or a scheduled scan result. The trigger should be as specific as possible to avoid false starts.
Data collection phase: Before any analysis or action, the playbook gathers all relevant data. For a phishing alert, this means extracting the sender address, all URLs in the body, all attachment hashes, the recipient, and the email headers. This phase should be read-only and fast.
Enrichment and analysis phase: Each indicator is queried against reputation sources, internal threat intelligence, historical alert data, and asset inventory. The playbook accumulates a risk score or decision signal based on enrichment results.
Decision logic: Based on enrichment outputs, the playbook follows conditional branches. Malicious indicators go one path. Benign indicators go another. Ambiguous or inconclusive results escalate to a human.
Action phase: Remediation actions execute for confirmed-malicious cases. These actions should be logged individually: each API call, each result, each timestamp.
Case closure and feedback: The ticket is updated with a full action log, false positive rates are fed back to detection rules, and any organizational learning (new blocked domain, updated filter rule) is captured for institutional memory.
Phishing is the highest-volume, best-understood use case for security automation. A mature phishing triage playbook follows this sequence.
The trigger is an email security gateway alert or user-submitted report landing in the SOC queue. The playbook immediately extracts: sender email address and domain, all URLs (including redirect chains), attachment filenames and SHA-256 hashes, reply-to address if different from sender, and originating IP address from headers.
Enrichment runs in parallel across multiple sources. Each URL is checked against VirusTotal, URLhaus, and Cisco Talos reputation databases. The sender domain is queried for WHOIS registration age (domains registered less than 30 days are high-risk), MX record configuration, and SPF/DKIM/DMARC alignment. Each file hash is checked against VirusTotal and any internal sandboxing infrastructure. The originating IP is checked against threat intelligence feeds and geo-IP services.
Decision logic applies after enrichment. If any URL returns malicious verdict from two or more sources: block the URL and domain in the web proxy, quarantine the email from all recipient mailboxes via the email security API, create a high-severity incident ticket, send the recipient a notification explaining that a phishing email was removed, and close the SOC queue ticket with a detailed action log. If all indicators return clean: mark the ticket as false positive, log the sender domain as reviewed-clean for 30 days, and optionally update filter rules to reduce future noise from the same source. If enrichment returns inconclusive (one source flags, others are clean, or the domain is new but indicators are clean): escalate to a human analyst with enrichment data pre-populated, so the analyst reviews conclusions rather than repeating lookups.
EDR platforms generate high-confidence alerts for certain malware categories (ransomware pre-execution indicators, credential dumping tools, known C2 beacon patterns). For these alert types, the time between detection and isolation is a direct measure of blast radius: every minute the endpoint remains on the network, lateral movement and data exfiltration risk increase.
The trigger is an EDR alert classified as critical or high severity. The playbook immediately queries asset inventory to confirm the endpoint's business criticality (a domain controller is treated differently than a standard workstation), the assigned user, and whether the device is a clinical, OT, or other sensitive category that might require elevated approval before isolation.
For critical-severity alerts on standard workstations: the playbook automatically issues an isolation command to the EDR API, which cuts the endpoint's network access while preserving the EDR agent communication channel. The playbook simultaneously creates a priority incident ticket, pages the on-call analyst via PagerDuty or equivalent, and begins collecting forensic artifacts (running processes, network connections, recent file activity) from the EDR before they are lost.
For high-severity alerts: the playbook enters a timed approval window. The on-call analyst receives a Slack or Teams notification with enrichment data and a one-click approval button. If the analyst approves within five minutes, isolation executes. If no approval is received within five minutes, the playbook auto-escalates to the senior analyst on call and extends the window by ten minutes. If no approval in fifteen total minutes, the playbook executes isolation automatically and logs the override with justification.
For critical infrastructure (domain controllers, backup servers, OT-adjacent systems): automatic isolation is suspended. The playbook alerts immediately but requires explicit human authorization. The risk of a false positive isolation on a domain controller (network outage for all dependent systems) exceeds the risk of a five-minute analyst review cycle.
Every isolation action is logged: the API call made, the EDR response received, the timestamp, and the analyst identifier (or "automated" with playbook version) for the initiating action.
Account compromise indicators are typically behavioral: impossible travel (authentication from two geographic locations within a time window that exceeds physically possible travel speed), authentication from anonymous proxy infrastructure, first-seen device login, or successful login following a series of failed MFA attempts.
The trigger is a SIEM rule or identity provider alert matching one or more of these patterns. The playbook first retrieves the account's recent authentication history (last 30 days), current active sessions, MFA device registrations, and assigned role and privileges.
For impossible travel or anonymous proxy indicators: the playbook forces an immediate MFA re-authentication challenge. If the user completes MFA successfully within ten minutes, the session is validated and the ticket is logged as anomalous-but-confirmed. If MFA is not completed, or if the user reports they did not initiate the sign-in: the playbook disables the account in the identity provider, revokes all active sessions (in Microsoft Entra ID, this is the Revoke-MgUserSignInSession API call; in Okta, the Clear User Sessions endpoint), resets the account password to a temporary credential, creates a priority incident ticket, and notifies both the user and their manager via email with instructions for regaining access through IT.
The playbook then initiates a scope investigation phase: it queries the identity provider for all applications the account accessed in the 24 hours prior to the compromise indicator, flags any sensitive applications (payroll, HR, code repositories, cloud infrastructure consoles) for deeper forensic review, and creates sub-tasks in the incident ticket for each flagged application.
The National Vulnerability Database (NVD) publishes new CVEs daily. Critical CVEs (CVSS 9.0+) require rapid organizational response. Without automation, the process of determining whether a newly published CVE affects the organization requires manual cross-referencing against asset inventory, which takes hours and is often incomplete.
The trigger is an NVD API event for a CVE with CVSS score above 7.0 (configurable threshold). The playbook immediately queries the organization's software asset inventory or SBOM (Software Bill of Materials) database for the affected product and version range. If the organization uses an attack surface management platform, the playbook also queries it for external exposure of the affected component.
If no affected assets are found: the CVE is logged as not-applicable with the inventory query results as evidence, and the ticket is closed.
If affected assets are found: the playbook creates a remediation ticket assigned to the team responsible for the affected system, populates it with CVE details (description, CVSS score, affected versions, available patches, exploit availability), sets an SLA timer based on severity (critical: 15 days, high: 30 days, medium: 90 days, per CIS Controls v8 guidance), and begins tracking remediation progress. If the CVE has known active exploitation in the wild (based on CISA KEV catalog lookup), the SLA timer is accelerated to 7 days for critical and 15 days for high.
---
Playbooks reduce the cognitive load on SOC analysts during high-pressure situations. When a ransomware precursor alert fires at 2 AM, an analyst following a well-designed playbook executes a practiced sequence. An analyst without one improvises under fatigue, under time pressure, and often without all the relevant context.
Beyond individual analyst performance, playbooks institutionalize organizational knowledge. When a senior analyst with ten years of incident response experience leaves the organization, their knowledge of what to do during a phishing investigation does not leave with them if it has been codified into production playbooks. Playbooks are how SOC expertise scales beyond the individuals who possess it.
From a compliance perspective, playbooks provide the audit trail that frameworks increasingly require. NIST CSF, ISO 27001, and CIS Controls all contain provisions around documented incident response procedures. A playbook that logs every action satisfies the documentation requirement and provides forensic evidence for post-incident reviews.
---
Every API call in a production playbook must handle failure. Common failure modes include: API rate limiting (the reputation service returns 429 Too Many Requests), API timeout (the endpoint isolation command does not receive a response within the expected window), authentication failure (API credentials have rotated), and partial results (a hash lookup returns metadata but no verdict).
For each failure mode, define the playbook's behavior. Rate limiting: implement exponential backoff (retry after 2 seconds, then 4, then 8, then escalate). Timeout: log the failure, mark the data point as unresolvable, continue playbook execution with available data, flag the incomplete enrichment in the ticket. Authentication failure: halt the playbook, create a high-priority alert for the SOC operations team, and do not execute any automated actions that depend on the failed integration.
Never design a playbook that silently swallows errors. Silent failure in a security automation context means a threat indicator went unchecked or a remediation action went unexecuted, with no record that either happened.
Every automated action must produce a log entry containing: the timestamp (UTC), the action type (API call, ticket update, email notification, block action), the data inputs used to make the decision, the result or response received, the playbook name and version that executed the action, and the ticket identifier that provides the full incident context.
Audit logs must be written to a write-once store. SOC personnel should not be able to modify or delete automation audit logs, even with elevated privileges. This is both an operational integrity requirement and a forensic preservation requirement.
---
Security automation playbooks are the operational mechanics of CDA's Predictive Defense Intelligence (PDI) methodology within the TID domain. PDI's tagline, "See the threat before it sees you," implies not just detection capability but response speed. Detection without fast response is surveillance without action.
In CDA's campaign model, playbook development is a structured activity within the C-HARDEN campaign phase. Each playbook maps to a specific TID mission. The phishing triage playbook maps to foundational email defense missions. The account compromise playbook maps to IAT-adjacent missions covering identity-based threat response (TID and IAT operate concurrently in the PDM's concentric domain model, and account compromise sits at their intersection). The vulnerability notification playbook connects TID to VSD domain operations, as surface reduction and patch management inform threat response prioritization.
CDA evaluates SOC automation maturity on a five-point scale derived from playbook coverage, error handling completeness, and measurement rigor. Level 1 organizations have no playbooks. Level 2 have playbooks for one or two use cases with no error handling. Level 3 have coverage across the four canonical use cases with basic error handling. Level 4 add full error handling, audit logging, and ROI measurement. Level 5 organizations have playbooks that improve themselves: they feed false positive data back into detection rules and measure their own accuracy over time.
Most organizations that invest in SOAR platforms operate at Level 2 or 3 two years after deployment. The technology investment happens; the operational discipline to document error handling and measure outcomes often does not. CDA's TID engagement model starts every SOAR implementation with an explicit commitment to Level 4 as the minimum acceptable production standard.
---
---
---
docs/canon/pdi-predictive-defense-intelligence.mdCDA Theater missions that address topics covered in this article.
Written by Evan Morgan
Found an issue? Help improve this article.