SOAR and SIEM are not alternatives. SIEM decides what is happening, SOAR decides what to do about it, and the order you deploy them in matters more than which you buy. Automation running on a poorly tuned SIEM does not save analyst time. It executes the wrong containment at machine speed, estate-wide, before anyone has read the alert.
Is SOAR still a category in 2026?
Not as a standalone market. Gartner marked SOAR “obsolete before plateau” on its Hype Cycle in 2024, a designation that means the category stalled before becoming established, and Dark Reading’s reporting on that call quoted analyst Eric Ahlm’s assessment that vendors selling nothing but dedicated automation platforms do not have a lively future ahead of them.
The capability did not disappear. It got absorbed. Splunk SOAR, Palo Alto Networks XSOAR, CrowdStrike Fusion and Microsoft Sentinel’s automation rules all now sit inside or alongside the detection platform rather than beside it as a separate purchase. That changes the question you are actually asking. It is rarely “which SOAR should we buy” any more. It is “should we switch on the automation we already have a licence for”, and the honest answer for a lot of SOCs is not yet.
Gartner’s SOAR definition still describes the function accurately: orchestration across tools, automated response, and case management. Treat it as a set of features to enable rather than a product to procure.
What does each one actually do?
SIEM collects, normalises and correlates events, then surfaces prioritised alerts and retains the underlying data for audit and forensics. SOAR consumes those alerts, enriches them from other systems, executes containment actions through APIs, and writes the case record back. The dividing line is that SIEM produces judgements about the past and SOAR takes actions in the present.
| Dimension | SIEM | SOAR |
|---|---|---|
| Core job | Detect, correlate, alert, retain | Orchestrate, enrich, contain, case-manage |
| Inputs | Logs, events, flows, cloud telemetry | SIEM alerts, threat intel, ticketing, APIs |
| Outputs | Prioritised alerts, dashboards, audit trails | Executed actions, enriched cases, closed tickets |
| Effect on MTTD | Direct: correlation cuts detection lag | Indirect: context speeds the analyst decision |
| Effect on MTTR | Indirect: alert quality sets the ceiling | Direct: containment runs in seconds |
| Analyst load | High: review, tuning, rule maintenance | Lower on routine work, unchanged on hard cases |
| Failure mode | Noise, ignored alerts, silent parser breakage | Confident wrong actions, executed fast and wide |
| Retention role | The system of record | Case and execution logs only |
That last row is the one worth sitting with. A noisy SIEM wastes analyst attention, which is expensive but recoverable. A confident automation layer running on a noisy SIEM disables the wrong accounts and isolates the wrong hosts, which is an outage you caused yourself.
Why sequence beats the shootout
The most common procurement mistake is buying automation before earning the right to automate. Vendor demos show a clean line: alert fires, playbook runs, threat contained. What the demo omits is the months of detection tuning that have to come first for that playbook to fire on something real.
| Gate | What it requires before you automate |
|---|---|
| 01. Detection fidelity | A false-positive rate your team has agreed and actually measured |
| 02. Documented playbooks | At least three incident types with a written, repeatable response |
| 03. Asset inventory | Complete enough that containment hits the right machine |
| 04. Corroborating signal | No playbook fires on a single uncorroborated source |
| 05. Escalation path | A defined human owner for every playbook failure |
The asset inventory gate is the one teams skip most often and regret hardest. Automated containment resolves a hostname or an identity to a target and acts on it. If the inventory is stale, the action lands on the wrong machine, and it lands there faster than a human would have caught the mistake. The joint Best Practices for Event Logging and Threat Detection guidance from ASD’s ACSC, CISA, the FBI and the NSA puts the same emphasis on knowing what you are collecting from before you build on top of it.
What a playbook actually runs
Phishing triage is the canonical first playbook because the workflow genuinely is identical every time, which is the only real qualification for automating anything.
| Step | What happens | Run by |
|---|---|---|
| 01. Detect | SIEM correlation rule fires on a clicked, flagged URL | Automated |
| 02. Forward | Alert passed to SOAR with sender, URL and recipient identity | Automated |
| 03. Enrich | Threat intel, identity history and asset criticality pulled in | Automated |
| 04. Decide | Known-bad contains, unknown escalates with context attached | Automated |
| 05. Review | Analyst confirms or reverses, then checks blast radius | Human |
| 06. Close | Disposition written back to SIEM for audit and correlation | Automated |
Before any of that runs in production, execute it in dry-run against a month of historical alerts and count how often step four would have contained something it should not have. That number is your gate. If automated containment would have fired incorrectly at a rate your team would not accept from a junior analyst, the detection underneath needs work before the automation is enabled.
The same chain applies to credential exposure. When an infostealer infection surfaces, the enrichment and suspension steps are mechanical and worth automating, while the question of what else that credential opened is not. Our guide to detecting and responding to infostealer infections covers the judgement half, and what the first hour of a breach should look like covers where automation stops helping.
What should never be automated
SOAR’s value is not uniform across incident types, and pretending otherwise is how teams end up distrusting their own tooling. Automate where the response is identical every time and the blast radius of being wrong is small:
- Enrichment of any kind. Pulling reputation, asset criticality and identity history costs nothing if it is wrong.
- Known-bad indicator containment, where the indicator is corroborated by more than one source.
- Ticket creation, case assembly and disposition write-back.
- Reversible actions on low-criticality assets, such as forcing a password reset.
Leave the rest to people. Multi-stage intrusions involving living-off-the-land techniques, novel tooling or hands-on-keyboard operators do not decompose into a playbook, because the next step depends on what the last step revealed. Containment on domain controllers, production databases and anything an executive uses should carry a human approval step regardless of confidence score, since the cost of a wrong action there exceeds the cost of a slow one.
There is a related trap in the cloud, where a playbook with broad API permissions is itself a privileged identity worth stealing. If you are automating containment across cloud accounts, the misconfigurations that cause breaches apply to your automation service account as much as to anything else.
How do you know it is working?
Four numbers, tracked from the day the first playbook goes live. Everything else is vendor marketing:
- False-positive action rate. How often an automated containment was later reversed by an analyst. This is the health metric. If it climbs, stop expanding coverage.
- Playbook success rate. How often an execution completes without an API error or timeout. Silent failures during an active incident are worse than no automation.
- Analyst minutes saved per alert type. Measured against a real pre-automation baseline, not an estimate.
- MTTR for covered incident types versus uncovered ones. If the delta is small, the playbook is automating something that was never the bottleneck.
Which platform surfaces the alert in the first place is a separate decision with its own trade-offs, covered in our companion piece on SIEM vs XDR. If you are weighing whether machine learning changes any of this, AI in the SOC separates what is working from what is still a demo. And for the tier below, the EDR, XDR and MDR tiebreaker covers the endpoint decision.
Frequently asked questions
Is SOAR dead?
The standalone product category is largely over. Gartner marked SOAR obsolete before plateau in 2024, and the capability now ships inside SIEM and XDR platforms. The orchestration and automation functions themselves are more common than ever, just no longer bought separately.
Do you need SIEM before SOAR?
Yes, in almost every case. SOAR acts on the alerts SIEM produces, so alert quality sets the ceiling on automation quality. Automating a noisy detection pipeline converts false positives into containment actions against the wrong systems.
What is the difference between SOAR and XDR automation?
Scope. XDR automates response within the telemetry and tooling its vendor controls. SOAR orchestrates across tools from many vendors, including ticketing, identity and infrastructure. If your stack is single-vendor, the XDR’s native automation may be all you need.
Which incidents are worth automating first?
Phishing triage, indicator enrichment and known-bad containment, because the analyst response is identical every time. Anything requiring a judgement about what the previous step revealed should stay with a human.
How do you measure whether automation is working?
Track the false-positive action rate above everything else: how often an automated containment gets reversed. Then playbook success rate, analyst minutes saved per alert type, and the MTTR delta between covered and uncovered incidents.
Can a small team run SOAR?
Small teams get the most value per analyst hour from automation, but they also have the least capacity to maintain playbooks when upstream APIs change. Start with two or three enrichment playbooks that do not take destructive actions, and expand only once the false-positive action rate holds steady.
Sources and further reading
- SOAR Is Dead, Long Live SOAR, Dark Reading, on Gartner’s obsolete-before-plateau designation
- Security orchestration, automation and response (SOAR), Gartner glossary
- Security information and event management (SIEM), Gartner glossary
- Best Practices for Event Logging and Threat Detection, ASD’s ACSC with CISA, FBI and NSA
- MITRE ATT&CK