Top SOAR Playbook Use Cases: What Teams Actually Automate

In the first post of this series I made the case that SOAR implementations stall for architectural reasons, not because the teams deploying them are bad at their jobs. For the primer on what a SOAR playbook is, how they get built, and why they break, see SOAR playbooks: how they work, why they break, and what's replacing them. According to Forrester's Allie Mellen, security teams often implement a maximum of five to 10 playbooks in total over the first several years of adoption, despite the plethora of prebuilt playbooks available. And when she polled practitioners directly, two-thirds said they regularly use 5-10 playbooks or fewer.

This post is about the more interesting question hiding inside that number: which five to ten? Because if you look at what actually survived in production - across surveys, across vendors, across years - the list is remarkably consistent. That consistency is worth paying attention to - it's a pretty good map of where deterministic automation actually fits, drawn by teams who found the edges the hard way.

What the data says

The SANS 2024 State of Automation in Security Operations survey (sponsored, in a detail I genuinely enjoy, by one of the FKASOAR themselves) asked teams what they already automate. The top of the list:

• Phishing response: already automated by 52% of organizations
• Vulnerability management: 43%
• Data enrichment: 42%

SANS's own analysis reveals that teams found the most success automating mature, well-understood processes like phishing and vulnerability response, while more complex functions such as breach response remain future priorities rather than current capabilities.

Notice what the top three have in common. None of them require the automation to decide whether something is bad. They require it to fetch, check, route, and file - work whose every condition can be written down before the alert ever fires. A human still makes the call - the automation just does the legwork.

Now hold that against the ambition. In the same survey, 45% of organizations said they're targeting automation of at least half of their incident response workflows - and another 35% are aiming for at least three-quarters. The production reality, per Forrester, is five to ten playbooks living in the narrow band above. That gap in what teams want to automate versus what's actually running is basically the whole SOAR story.

{{ebook-cta}}

What I watched teams automate

I spent years at one of the big MDRs that owned one of the early SOAR platforms, and the customers who got real value out of it - the minority who leaned in - automated a list that could have been at least partially predicted from the survey data. Two of the four below never appear as survey line items. I think that's interesting because you may look at them and say they're not pure security automations, but rather the ticketing and approval workflows that practitioners build around their SecOps use cases.

1. Enrichment from sources only they had. The highest-value playbooks were rarely exotic. They pulled from environment-specific sources - a CMDB, an internal asset system, something without a friendly API - so that when a certain alert fired, the context that turned a twenty-minute lookup into an instant answer was already attached. Sometimes that context alone was enough to close the alert automatically.
2. Phishing triage. The perennial number one, and the survey says it still is. Was this already mitigated by the mail gateway? Does the same message exist in other inboxes? Is there anything left to clean up? Every one of those is a checkable fact, not a judgment call, which is exactly why it automates so well.
3. Containment with an approval step. Teams wanted response actions automated, but almost nobody wanted them autonomous. Every customer had their own approval workflow, and the sophisticated ones grouped their assets - VIP machines got a different path than the general population. The playbook's job was to make the action instant once a human said yes, and impossible before. And here's the part I find most telling: this was often the first thing customers wanted in place, not because it would fire often, but because having it proved to their organization that when something truly mattered, the response would be fast. High leverage, rarely used - hopefully.
4. Workflow enablement. The unglamorous connective tissue: if we contained a box, open a ticket in the IT system, because somebody is inevitably going to have to get that user back up and running. Nobody puts this on a conference slide, but it almost certainly saved more analyst hours than most of what did.

There are two patterns from those years that the survey percentages can't show you. First, adoption rarely started where the volume was. It started with gated containment - the playbook a team hoped to almost never run. High-volume automation was where teams actually hesitated, because at volume, a playbook that's slightly wrong manufactures more noise and confusion at machine speed than saving time.

Second, the boundary between deterministic work and judgment work doesn't run between use cases. It runs through them. The simple version of workflow enablement - box contained, open the IT ticket - worked beautifully. The generalized version, codifying when to open tickets and which team outside SecOps should own them, looked every bit as definable and almost never was. Underneath "route this to the right team" sits a pile of business logic and organizational context, and the bar for getting it right is high, because the failure mode is automatically generating trash for a sister team.

All four share some version of: in this particular situation, for these particular machines, for these particular users, do this. Every condition is enumerable in advance and every step is specifiable before the alert ever fires. That's the kind of work deterministic automation is genuinely great at - and whether they realized it or not, that's what the teams getting real value out of SOAR were selecting for.

Where the list ends

Reflecting back on this, I don't consider the list above a starting point. It's the finished list. Teams didn't automate phishing triage and enrichment first and then graduate to automating triage judgment across their whole alert queue. They automated the deterministic band and stopped, because playbook eleven required the automation to decide whether an ambiguous login was actually suspicious, and a decision tree written last quarter doesn't have an informed opinion about that.

The survey data shows the same stall. In SANS's 2024 Detection & Response survey (almost 400 respondents), 64% of organizations are integrating automated response mechanisms into their operations. Only 16% report having fully automated their response processes, and 68% describe their response as semi-automatic. Put those together: almost everyone is automating, and almost nobody is willing to take the human out of the loop. The industry converged on the approval gate - the same one my customers insisted on a decade ago.

One clarification that I believe is a common misread (also flagged it in the first post): what teams automated with SOAR was never just response actions. Enrichment and phishing triage are investigation work. The boundary was never "investigation vs. response" - it was predictable vs. judgment, and in reality it is often core to both.

One honest caveat, because the pattern has a real exception: broad automation does work - in a specific kind of shop. MSSPs, MDRs, and very large tech SOCs run playbook estates far beyond ten, sustainably…ish. I know this first hand (maybe someday we'll do a fully dedicated blog on the "ish" part) but two things about that. First, the preconditions don't generalize: automation is the product, a dedicated engineering team maintains it full time, and playbooks get reused across many client environments - none of which exists inside the median enterprise SOC, which per the SANS 2024 SOC Survey (403 respondents) has been 2 to 10 people every year since the survey began in 2017. Second, and more telling: even at that scale, look at what was being automated. The same deterministic band, replicated across hundreds of clients. The judgment work still landed on human analysts. That's why MDRs employ a large team of SOC analysts. More scale just meant more of the same kind of automation - it never got them past the judgment problem.

The list was right

So here's the conclusion I'd offer, and it might not be the one you expect from someone at an AI SOC company: the teams who built that narrow list weren't doing SOAR wrong. They were doing determinism right.

Enrichment pipelines, phishing checks, gated containment, ticket handoffs - those workflows are deterministic because they should be. You want the VIP-machine approval path to work the same way every single time. You want the IT ticket to open every time a box gets contained, no creativity involved. That was true in 2018 and it's true today. If you have those playbooks running right now, keep them pointed exactly where they're pointed.

The principle from the first post covers it: agentic where judgment lives, deterministic where response lives. What the five-to-ten-playbook era proved is that practitioners already knew the second half of that sentence. They found the deterministic band with years of trial and error and automated it well. The unfinished half is everything on the other side of the boundary - the judgment work that stayed manual because nothing available could do it.

That's the subject of the next post: what actually changes when the decision happens at runtime instead of in a branch somebody wrote in advance. Bring your skepticism, I've always got mine handy.