Your SOAR vendor changed an API output format last month. Maybe you noticed. Maybe you didn’t, while playbooks failed silently and enrichment steps returned partial data. A top engineer spent Friday tracking it down and patching the connectors.
That Friday has a dollar value. It never shows up on your SOAR invoice.
License and compute are the numbers you approved. The number you’re actually paying is much higher. It’s spread across your team in ways that don’t land in a single line item, and it grows every quarter.
The five cost centers nobody budgets for
Most SOC leaders can tell you what they pay for SOAR licensing. Almost none can tell you what SOAR actually costs them. That’s because the real expense lives in five places that don’t show up on the vendor invoice.
| Cost center | What it looks like | Who absorbs it | How it compounds |
|---|---|---|---|
| Integration build-out | Every new tool = weeks of connector work, field mapping, auth setup | Engineering / senior analysts | Each new vendor in your stack restarts this cycle |
| Integration maintenance (“drift tax”) | APIs change, schemas shift, auth rotates. Playbooks break silently. | Engineering | Grows with number of integrations |
| Playbook engineering | Every new detection or use case = playbook design, build, QA, edge-case handling | Engineering / L3 analysts | Every detection rule update, every new alert source, every org change triggers rework |
| Edge-case escalation | Playbooks handle the “if A then B.” Everything else lands on an analyst. | L1–L2 analysts | Edge cases are the majority of real threats. The playbook handles the routine. Humans get the rest — plus the maintenance. |
| Opportunity cost | Your best people are debugging workflows instead of hunting threats or building detections | The entire SOC | This is the one that kills you. Senior talent doing plumbing instead of security work. |
None of these show up on a purchase order. All of them are real. The last one, opportunity cost, is the most expensive because it’s invisible. Nobody tracks “hours my senior analyst spent debugging a broken Jira connector instead of investigating a suspicious lateral movement alert.” Those hours add up, and the work they displaced doesn’t get done.
Why it gets worse, not better
These costs compound.
Your stack grows every quarter. Each one means new integrations, new playbooks, new edge cases. SOAR costs scale with the size of your security stack, not with the threats you’re trying to stop.
Detection engineering makes it worse, counterintuitively. Write better detection rules, cover more of your attack surface, generate more alerts. More alerts means more playbooks to build and maintain. Getting better at detection makes your SOAR more expensive to operate.
Then your vendors change things on their end. API versions get deprecated. Output formats drift. Fields get renamed or removed. The stack your SOAR was integrated against six months ago is already different from what it’s talking to now.
Here’s a question worth asking in your next SOC standup: how much of your engineering capacity is going toward keeping automation alive, and how much is going toward building new capability?
Most teams can’t answer that cleanly. Which is the problem.
The per-alert math
We can put a number on part of this. A fully loaded SOC analyst at $85K/year, triaging roughly 12 alerts per hour at 70% efficiency, costs somewhere between $2.50 and $4.00 per alert in direct triage time. That’s the cost for alerts that require human attention, which in most SOCs is the majority of alert volume. Typical SOAR playbook coverage rarely exceeds 30% of alert types.
| Human triage (SOAR-assisted) | Morpheus | |
|---|---|---|
| Per-alert triage cost (alerts requiring human review) | $2.50–$4.00 | ~$0.25–$0.27 |
| Integration maintenance | Additional — scales with stack size | $0 (self-healing) |
| Playbook engineering | Additional — scales with detection count | $0 (runtime generation) |
| Escalation handling | Additional — scales with alert complexity | Included (attack path discovery) |
| 24/7 coverage multiplier | 5–6 FTEs per analyst seat (4.2 bare minimum) | None |
The first row is the number we can defend. The rows below depend on your environment: how many integrations you run, how often things break, how complex your alert types are. We’re not going to invent a figure for those. But they’re not zero, and in most environments, they’re not small.
The staffing multiplier
There’s another cost buried in the math: 24/7 coverage.
Start with arithmetic anyone can check. There are 168 hours in a week. A standard workweek is 40 hours. That’s 4.2 FTEs to keep one analyst seat occupied around the clock, and that assumes zero PTO, sick days, training time, or shift overlap. Nobody operates this way.
Layer in reality. Mid-career security analysts typically get 15 days of PTO. Cybersecurity roles carry heavier training loads than most: 5 to 10 days a year for SANS courses, cert prep, and internal sessions. Add sick leave and unplanned absence, and most workforce planning models put 24/7 coverage at roughly 5.4 FTEs per seat. SOC leaders we’ve spoken with put it between 5 and 6.
That’s the cost of keeping one person in a chair at all times.
SOAR does reduce per-analyst workload for alert types with solid playbook coverage. That’s a genuine benefit, but it doesn’t eliminate the staffing multiplier. The 24/7 human coverage requirement stays. The overhead SOAR introduces, integration debugging, playbook QA, connector maintenance, lands on headcount that isn’t always separate from the analysts you were hoping to free up.
The other piece: most SOAR playbooks operate at L1 triage. They can enrich and classify, but they can’t investigate. Your analysts still carry the full L2 burden, looking across systems, tracing attack paths, making a judgment call, on top of maintaining the automation that was supposed to free them up.
What a different model looks like
SOAR tuning can improve efficiency for well-defined, high-volume use cases. That’s where it works best. The underlying architecture, static playbooks, manual integration maintenance, human-in-the-loop for anything outside the script, creates overhead that doesn’t shrink as your environment grows.
Morpheus was built around different assumptions. Here’s how each of those five cost centers changes:
| Cost center | SOAR reality | Morpheus approach |
|---|---|---|
| Integration build-out | Weeks per connector | Pre-built across 800+ integrations |
| Integration maintenance | Ongoing manual fixes | Self-healing — detects API drift and auto-corrects |
| Playbook engineering | Build, test, maintain per use case | Generated at runtime from live alert context |
| Edge-case escalation | Analyst handles everything outside the script | Attack path discovery investigates across the stack |
| Opportunity cost | Senior talent doing plumbing | Senior talent doing threat hunting and detection engineering |
SOAR’s real cost isn’t license plus runtime. It’s engineering throughput plus analyst throughput. Morpheus flips that equation.
We’ve written about the operational differences elsewhere: how self-healing integrations work, what attack path discovery does during triage, and why wrapping AI around a legacy SOAR chassis doesn’t solve the problem. This post is about the economics underneath all of that.
One thing worth doing this week
Pull your last quarter of Jira or ServiceNow tickets. Filter for anything related to connector fixes, playbook failures, integration maintenance, and API changes. Count those tickets. Then count the ones that were actual threat investigations.
That ratio is your real SOAR cost. Not the invoice: the work.
If the number surprises you, or if you want help running the math on your specific environment, we’ll do it with you. We’ll show you the full number, and what your SOC looks like when you stop paying it.
