soar-playbook-designlisted

# SOAR Playbook Design A good playbook removes toil from the analyst without removing judgment from the decisions that need it: it enriches reliably, routes clearly, asks a human before it changes the world, records what it did, and can be stopped and undone. Automation goes wrong in predictable ways: a noisy detection becomes a storm of containment actions, a retry applies the same block twice, a hung API call leaves nobody sure whether the account was disabled, an approval that timed out is treated as a yes, and a playbook nobody can switch off keeps isolating laptops during an outage. Every step below exists to prevent one of those. Inputs a playbook parses (email bodies, filenames, URLs, alert descriptions) are attacker-controlled data; a playbook, and any model inside it, must never take instructions from them. ## Workflow 1. **Pin down the trigger, the outcome, and the non-goals.** Write one sentence each: what starts it (which alert, with what filter), what the analyst gets at the end (a case with evidence, a closed alert, a blocked IP), and what it deliberately will not do. Most bad playbooks fail here by trying to fully resolve an incident. Enrich-and-route is the default scope; containment is added only for a narrow, well-understood case. 2. **Lay out the steps in the standard order: parse, enrich, decide, gate, act, record, hand off.** Draw the graph before writing JSON. Every decision has a default branch that leads to a human. Every enrichme