SIEM vs SOAR: What Each Does, and When You Need a Separate SOAR

A security information and event management (SIEM) platform collects, centralizes, and analyzes log data so a security team can detect threats. A security orchestration, automation, and response (SOAR) platform takes alerts from the SIEM and other tools and runs playbooks that enrich them, route them, and respond through other systems. The SIEM decides what looks suspicious, and the SOAR decides what happens next. Buy and tune the SIEM first, because a SOAR can only automate decisions about alerts that something else has already produced. The two categories have also converged: Microsoft Sentinel and Google Security Operations each include SOAR capabilities, so the practical question is whether native automation is enough before you pay for a standalone SOAR.

What does a SIEM do?

Joint guidance from the Australian Signals Directorate, CISA, the NSA, and partner agencies describes a SIEM as a software platform that collects, centralizes, and analyzes log data. In practice the SIEM does four jobs. It ingests logs from endpoints, identity providers, cloud services, network devices, and applications. It normalizes them into a common schema. It runs correlation and detection rules that turn log patterns into alerts. It retains the data so analysts and investigators can search it months later.

The detection rule is the SIEM's core artifact, and the team that writes and tunes those rules decides how good the security operations center (SOC) is. The same guidance notes that most SIEM pricing models are based on the quantity of data the SIEM ingests, which makes the choice of log sources a budget decision and a security decision at once. Our breakdown of SIEM as a service pricing shows the units vendors bill on, and our guide to SOC as a service pricing covers the other cost drivers in running the operation around the SIEM.

What does a SOAR do?

The same guidance says some SOAR platforms collect and analyze logs themselves, while others integrate with an existing SIEM and use its log collection and analysis. The core artifact is the playbook, a set of steps that runs when a specific alert or incident arrives. Palo Alto Networks' documentation for Cortex XSOAR describes playbooks that automate security processes, remediate incidents by calling third-party integrations, and include manual tasks where an analyst confirms information or escalates. Most SOAR platforms add case management, so the playbook steps, the evidence, and the analyst's notes sit in one record.

A SOAR depends on detection sources for its input. Google describes its SOAR as ingesting, grouping, and prioritizing alerts from all your detection tools to execute playbooks automatically. Those detection tools include the SIEM, endpoint detection and response (EDR), the email gateway, the identity provider, and cloud security posture tools. Feed a SOAR poor alerts and it executes poor decisions quickly.

How do SIEM and SOAR compare?

The table explains why the comparison is uneven. A SIEM without a SOAR still gives you detection, with people doing the response by hand. A SOAR without a reliable detection layer gives you fast, automated reactions to alerts nobody has validated.

Has the line between SIEM and SOAR disappeared?

For most buyers it has. Microsoft's documentation states that Sentinel, "in addition to being a SIEM system, is also a platform for security orchestration, automation, and response," with automation rules that manage incident handling centrally and playbooks built on Azure Logic Apps workflows. Google Security Operations documents its SOAR as part of the same product family. A Sentinel or Google Security Operations customer already owns a SOAR engine, so the buying question becomes whether that engine covers the workflows the SOC needs.

Convergence also changes migration plans. The same Microsoft page states that after March 31, 2027, Sentinel will no longer be supported in the Azure portal and will be available only in the Microsoft Defender portal. It also lists procedures not yet supported in the Defender portal, including running a playbook manually on an alert or on an entity. Sentinel customers who are redesigning automation in 2026 should build and test it in the Defender portal and check those gaps against their runbooks before the cutover.

Where do XDR and AI triage agents fit?

Extended detection and response (XDR) platforms sit between the two categories. Microsoft describes Defender XDR as a suite that coordinates detection, prevention, investigation, and response across endpoints, identities, email, and applications, and that automatically applies containment actions when it correlates high-confidence signals from multiple workloads. An XDR detects like a narrow SIEM and responds like a narrow SOAR, within one vendor's products. An enterprise with third-party and custom log sources, long retention needs, or investigations that cross vendors still needs a SIEM, and the XDR becomes one of the SIEM's most valuable feeds.

AI triage agents are the newest layer. Microsoft documents a Defender agent that classifies user-reported phishing alerts as true or false positives, explains its reasoning, resolves the false positives itself, and leaves the true positives open for an analyst. Agents like this make the verdict that a SOAR playbook would otherwise wait for a person to make. Govern them the way you govern any automated decision: sample their closed alerts, limit their permissions, and keep a path to reverse what they do.

When does a standalone SOAR make sense?

A standalone SOAR earns its license in four situations. The first is an estate with more than one SIEM, such as a company running two after an acquisition, or a provider serving many clients, where one automation layer across all of them costs less than rebuilding playbooks in each. The second is heavy orchestration outside security tools, where playbooks open ServiceNow tickets, page on-call engineers, and call internal APIs. The third is a large library of working playbooks that would cost more to rewrite than to keep. The fourth is a team with dedicated automation engineers who will use the depth a standalone product offers.

Without one of those conditions, native automation in the SIEM covers enrichment, routing, and common containment with one fewer platform to license, patch, and integrate. A standalone SOAR also adds a second place where response logic lives, and someone has to keep the SIEM's incident model and the SOAR's case model in sync. Count that synchronization work in the business case.

Which should you implement first?

Implement the SIEM first and the SOAR second. The practitioner guidance from the same agencies states that SOAR platforms are usually not suitable for immature environments, which it describes as organizations without a SIEM, with a newly established SIEM, or without an experienced security team. It also warns that a misconfigured platform can misidentify regular user or system behavior as an incident and disrupt service delivery.

The order that works has four steps. Onboard the priority log sources and confirm they parse correctly. Tune the detections until you know each rule's true-positive rate. Write a triage runbook for each rule that states what the alert means, what to check, and when to escalate. Then automate the runbooks that analysts follow the same way every time, starting with enrichment and case handling and moving to containment only after the earlier steps run cleanly. The executive guidance is blunt about the effort: neither a SIEM nor a SOAR is a "set and forget" tool, and an organization that implements either one in-house should expect multiple skilled staff to work on it full time.

What does the choice mean for staffing and cost?

SIEM cost scales with data, so the levers are log source selection, filtering at ingestion, and tiered retention. SOAR cost scales with integrations, because every playbook that calls an outside tool breaks when that vendor changes an API, renames a field, or retires an endpoint. A playbook that touches six tools has six ways to fail. Budget engineering time to maintain playbooks every year, with a named owner and a regression test for each one, instead of treating the build as a one-time project.

The same logic applies when you buy operations from a provider. Ask whether detections and playbooks run in your SIEM tenant or the provider's, who owns the rule and playbook content when the contract ends, and whether automated actions require your approval. Our comparison of MDR, SOC as a service, and MSSP models shows who owns the tooling, the data, and the detection content in each.

BD Emerson's SOC as a service runs on Microsoft Sentinel or a comparable SIEM inside your own tenant, fed by EDR such as CrowdStrike or Microsoft Defender, identity logs, and cloud telemetry. The stack lives under your contracts, so the data, the licenses, and anything built on them stay yours if you change providers. If you are deciding whether your SIEM's native automation is enough, start with the detection layer: every detection we deploy is mapped to MITRE ATT&CK, tested before it goes live, and shipped with a triage runbook that a playbook can later automate.