Why SOAR Implementations Fail (And How to Actually Use Them)

Gartner coined the term SOAR in 2017. Seven years later, in its 2024 Security Operations Hype Cycle, Gartner placed the category in the trough of disillusionment and marked it "obsolete before plateau". That's analyst-speak for: this stalled before it ever reached mainstream productivity, and something else is going to finish the job it started.

That's a rough verdict for a technology most SOCs still run today. So I am not hitting you with yet another "SOAR is dead" blog. You've heard that from every vendor with a booth, and it's a lazy claim. Automation in the SOC is more necessary than ever, and if you own a SOAR today, you own something genuinely useful. The more interesting questions require more thought: why did a category with this much promise and this much budget stall out? And what should you actually do with the SOAR you already have?

When I worked at one of the big MDRs we had plenty of ways to automate redundant, codifiable analyst tasks. Ironically, that became the problem. We had acquired one of the earliest SOAR tools on the market, and the SOC did what all SOCs do: solved the problem with whatever it had. Scripts running on a cadence, targeted ML models turning historical metadata into auto-resolution, and so on. Some of what the team came up with was genuinely impressive. But every time we tried to quantify the benefit, the questions multiplied faster than the answers: which automation are we even counting, is the impact getting better or worse, and who is watching all of it for degradation?

What you were left with was a small percentage of customers getting massive benefits - the ones who leaned in, engaged with us, and confirmed automations where they were comfortable - and a vast majority seeing far less, mostly because they never had the time to codify their workflows. I saw a microcosm of the entire market happen right before my eyes.

The promise

The pitch was scope. Automate the SOC end to end. Playbooks for everything: triage, enrichment, escalation, containment, reporting. Think of all the manual tasks your analysts do, then imagine each one as a workflow that runs itself. All manual tasks, all the time.

It was a good pitch. It raised a lot of money and it sold a lot of platforms. What actually happened is it failed to measure up to the expectations that were set.

What actually happened

Three things, and none of them are my opinion (don't worry, we'll get to that):

Teams automated a handful of things, then stopped. According to Forrester's Allie Mellen, despite the plethora of prebuilt playbooks available, security teams typically implement five to ten playbooks in total over their first several years with the platform. Not hundreds. She explicitly calls the "most teams run hundreds of playbooks" narrative a market mischaracterization. Five to ten, over years, against a pitch of everything.

The playbooks that shipped became a job. In the SANS 2024 State of Automation in Security Operations survey, roughly 68% of respondents named the engineering effort to build and maintain automation as the single most challenging attribute of SOAR - more than cost, more than skills, more than anything else. And that effort usually lands on one person. Forrester again: few security teams have security-minded automation experts in their ranks, and often a lone analyst maintains the whole thing. Gorka Sadowski, who helped coin the term SOAR at Gartner, describes where that leads: every new tool, new use case, or new exception sent the playbook team back to work. "It was a never ending story and ROI was getting progressively worse". (We've already written a whole piece on this one, because the maintenance tax deserves its own accounting: SOAR playbooks: how they work, why they break, and what's replacing them)

The category itself dissolved. Look at what happened to the standalone SOAR vendors: Demisto went to Palo Alto Networks for $560 million. Phantom went to Splunk for a reported $350 million, and then Splunk went to Cisco. Siemplify went to Google. Resilient went to IBM. CyberSponse went to Fortinet. When Google closed the Siemplify deal, Forrester called it the end of standalone SOAR. And the vendors still in the market largely stopped saying the word - they describe themselves as AI SOC, agentic AI, hyperautomation, workflow automation, intelligent workflows, almost anything else.

{{ebook-cta}}

Why SOAR implementations stalled

Here's the part I hope you find most useful, because it's not a story about bad engineering. The SOAR platforms were well built (OK, well most of them). The people deploying them were competent. It stalled anyway, and the reason is architectural - not a failure of the builders, but the honest limit of what anyone could build at the time given the available technology.

Deterministic automation is brittle by design. You don't need to trust me on this one because all of the vendors formerly-known-as-SOAR (FKASOAR) have already said it before me. A playbook is a decision tree somebody wrote in advance: if this field says that, do this. It excels in structured, stable, predictable environments, and it breaks on ambiguity, edge cases, and change. Same input, same output, every time - which is exactly what you want, right up until the input isn't the same. An API changes a field name. A vendor updates a schema. An alert arrives that's almost, but not quite, the shape the branch expected.

Now put that architecture in a SOC. Security operations work is filled with ambiguity. Every alert arrives with unknown context: is this login weird for this user? Is this process normal on this host? Is this the same activity we saw Tuesday? Judgment turtles, all the way down.

So teams did the rational thing. They automated the narrow band where determinism actually fits - phishing triage, enrichment lookups, notifications, ticket creation. The predictable, high-frequency, low-judgment tasks. And then they stopped, because the next playbook on the list required the automation to exercise judgment, and decision trees don't have any. That's the five-to-ten playbook ceiling on SOAR implementations, a result of the architecture at that time.

Sadowski relays the Gartner nuance that sums it up: SOAR had a lot of value automating some manual tasks, sometimes. It got sold as all manual tasks, all the time. The failure was the overpromise, not the function.

How to actually use it

If the diagnosis is right, the prescription writes itself, and it isn't "rip it out."

Determinism is exactly what you want where consequences live. Isolating a host. Disabling a user account. Revoking a session. Running a compliance-mandated notification chain. For actions like these, predictability is often required. You want the same input to produce the same output every single time. You want auditable decision paths, known failure modes, guaranteed latency, an approval gate, and a rollback path. You do not want anything creative anywhere near the button that isolates a production server.

I'll say this even though I work at an AI SOC company: the execution layer is not obsolete, and the honest people building AI-driven security operations tooling will tell you the same. Something still has to actually revoke the session, with an audit trail.

So the practical guidance for the SOAR you already own is this: point it at the response layer and keep it there. Keep your containment playbooks. Keep your notification chains. Additionally, keep every workflow where a compliance framework or an auditor cares about deterministic behavior. And stop trying to playbook your way through judgment calls, because seven years of market evidence shows SOARs fail at making variable judgements at scale no matter how many branches you write.

The lens

Here's the simple principle that seems to make sense to most of my beloved security people: agentic where judgment lives, deterministic where response lives.

SOAR's mistake was never determinism. It was putting determinism where the judgment needed to be, and then promising it could think - or perhaps not promising that, but just not realizing it was required.

In the next few posts we'll follow that thread: what teams actually automated with SOAR (the data is clarifying), and what changes when the decision happens at runtime instead of in a decision tree somebody wrote last quarter. For the cynics who say this is just an AI SOC vendor rolling out its own playbook - that's a fair take, but let's please not call it a playbook because boy howdy, is that confusing.

The whole point of this series is to root the argument in what analysts, surveys, and practitioners have been saying for a few years now. Bring your skepticism, I've always got mine handy!