SOAR vs SIEM: Automation vs Detection and Where They Overlap

SOAR and SIEM are often bought as rivals, yet one finds problems and the other acts on them, and a SOAR built on a weak SIEM simply automates bad alerts faster. A SIEM collects, normalises and correlates logs and raises alerts. SOAR (security orchestration, automation and response) takes alerts and cases and runs playbooks: enrichment, ticketing, notifications and containment through other tools. Modern platforms blur the line, with SIEMs adding automation rules and SOAR products adding case management and analytics, which is why the comparison still confuses buyers. This guide compares the two as concepts, explains where they overlap, and gives decision guidance on sequence, scope and safe automation. It is for SOC managers, security engineers and architects deciding what to build next.

Key takeaways

• SIEM detects, SOAR acts. The SIEM's job is visibility, correlation and alerting; SOAR's job is to orchestrate the response to those alerts across many tools.
• Build the SIEM first. ASD and CISA's joint guidance recommends properly implementing and tuning a SIEM, with accurate alerting, before adding a SOAR, and calls SOAR generally unsuitable for immature environments.
• Automate enrichment before containment. Lookups, deduplication and ticketing carry little risk; isolating hosts or revoking credentials needs high-confidence triggers and approval gates.
• The SOAR is a powerful non-human identity. It holds API credentials for EDR, identity, email and firewall tools, so its service accounts need least privilege, vaulting and monitoring.
• Overlap is real but partial. SIEM automation rules can cover simple workflows; a dedicated SOAR earns its cost when playbooks span many tools, need case management, or run at high alert volume.

The short answer

If you do not yet have reliable detection, invest in the SIEM. If your SIEM produces trustworthy alerts but analysts spend most of their time on repetitive enrichment, ticketing and simple containment, add SOAR or use your SIEM's built-in automation. The joint guidance Implementing SIEM and SOAR Platforms (ASD's ACSC with CISA and partners, 27 May 2025) puts it plainly: a SIEM focuses on visibility, detection and alerting; a SOAR focuses on automating response actions based on detections, and typically depends on a well-functioning SIEM. Automation complements responders, it does not replace them. For depth on each, see the SIEM Guide and the SOAR and Security Automation Guide.

Side-by-side comparison

Where they overlap

• Automation rules in the SIEM: many SIEMs can run simple actions on an alert, such as assigning, tagging, creating a ticket or calling a webhook. For a small team with a handful of workflows, this may be enough.
• Case management: both may offer incident queues. Pick one place where analysts work and close cases, or metrics split and work is duplicated.
• Enrichment: SIEMs enrich at ingest (threat intelligence, asset and identity context); SOAR enriches at response time by calling external services. Avoid doing the same lookup twice.
• Combined platforms: some products package SIEM, SOAR and XDR together. The functions still exist separately inside: assess each against this page's criteria. The SIEM vs XDR comparison covers the detection side.

Worked example: one alert, two platforms

A user reports a suspicious email and, minutes later, the SIEM correlates a sign-in to the same account from an unfamiliar country with a new inbox forwarding rule. Following the alert through both platforms shows where each one's job ends.

1. SIEM: ingests the email gateway log, the identity provider sign-in log and the mailbox audit event; a correlation rule joins them on the user and raises one high-severity alert mapped to ATT&CK initial access and collection.
2. SOAR, tier 1: opens a case, pulls the user's role and manager from the directory, checks the sender domain and any URLs against threat intelligence, and searches other mailboxes for the same message.
3. SOAR, tier 3 with approval: proposes purging the message from all mailboxes, revoking the user's sessions and refresh tokens, and removing the forwarding rule; the analyst approves with one click.
4. Analyst: confirms the scope, resets the password through the identity team, and decides whether data was exposed and whether notification rules apply.
5. SIEM, afterwards: holds the full record for the investigation and any regulator questions, and a new detection is written if the attack slipped past an existing rule.

Without the SIEM there is no correlated alert to start from; without SOAR the same work happens, but by hand, taking longer and with less consistent records of each step.

What to automate, and how safely

The ASD practitioner guidance lists automated responses used mainly for living-off-the-land intrusions: system quarantine, segregating or blocking network traffic, credential revocation, and EDR integration to block tools or scripts in real time. It also warns that misconfigured automation can flag normal activity as malicious and isolate it, disrupting services. Tier actions by blast radius.

Service accounts deserve their own care: disabling one can stop a business process, so playbooks should look up the owner and dependencies before acting, and rotate the credential rather than only disabling it where the account is still needed. See the SOAR and Security Automation Guide for approval gate design.

Each option in depth

For each option below: the threat it is built for, how it fails, the controls that make it work, when to choose it and a worked example.

SIEM

Threat model. The SIEM answers the visibility question: has something happened, and where? Its threats are blind spots, log tampering and alert volume that buries real incidents.

Failure modes. Rules never reviewed as the threat model changes; ingestion costs that force teams to drop useful sources; and empty query results read as proof of safety, a pitfall the ASD and CISA practitioner guidance calls out.

Controls. Log repository first, SIEM second; consistent alert naming against ATT&CK; regular testing of well-known techniques; and documented retention, starting from at least one year for administrative and security events and 90 days for informational logs, adjusted to risk.

Decision criteria. Invest in the SIEM first. The same guidance says SOAR is usually unsuitable for immature environments and that effective SIEM log analysis takes priority.

Worked scenario. A team with no playbooks spends its first quarter cutting noisy rules and tuning ten high-value detections. Only then does triage time fall enough to show which steps are worth automating.

SOAR

Threat model. SOAR acts on detections: quarantining systems, blocking traffic and revoking credentials. That power is its threat model. It holds privileged credentials to many systems, and a wrong or manipulated alert can make it disrupt the business.

Failure modes. The ASD guidance warns that a misconfigured SOAR may treat normal behaviour as an incident and cause service disruption, and that automation does not replace human responders. Over-broad service accounts, untested playbooks and no record of who approved an action are the common gaps.

Controls. Give each SOAR integration its own least-privilege credential and rotate it; require human approval for disruptive actions until a playbook has a clean record; ask legal, governance and compliance staff to assess regulatory consequences of automated response, as the guidance advises; and confirm the SOAR is actioning alerts as intended.

Decision criteria. Add SOAR when detections are trustworthy, the same response steps repeat daily, and you can name an owner for every playbook.

Worked scenario. A phishing playbook enriches reported emails and pulls matching messages from mailboxes automatically, but disabling an account still waits for an analyst click. After three months with no false disables, the team automates disabling only for confirmed malicious sign-ins from known bad infrastructure.

Where identity fits

A SOAR platform is one of the most privileged non-human identities in the estate. To isolate hosts, purge mail and revoke sessions it holds API keys, OAuth client secrets or service principal credentials with write access to EDR, email, identity and firewall systems. Store those credentials in a secrets manager, scope each connector to the minimum permissions its actions need, prefer short-lived tokens or workload identity federation over long-lived keys, and send the SOAR's own action log to the SIEM so another system watches it. If the SOAR is compromised, an attacker inherits all of that reach. See If your SOAR platform is compromised and the Secrets Management Guide.

When to use each

• SIEM only, or SIEM with built-in automation: small teams, low alert volume, few security tools to orchestrate, detection still being tuned.
• Add a dedicated SOAR: alert volume exceeds what analysts can triage; five or more tools take part in common responses; you need consistent evidence of every action for regulators or customers; you run 24/7 and want consistent out-of-hours handling.
• Delay SOAR: no SIEM baseline, a high false positive rate, no documented runbooks to automate, or no engineer to maintain integrations. The ASD guidance notes that platforms go unused when staff distrust automation or lack expertise to maintain it.
• Outsourced operations: if a provider runs detection and response, confirm who owns playbooks and which actions they may take; see MDR vs MSSP.

Small versus large organisations

Smaller organisations usually get more value from tuning SIEM rules and using the SIEM's own automation for ticketing and notification. Large SOCs with tiered analysts, many tools and strict audit needs gain from a dedicated SOAR with versioned playbooks, case management and a full action log. In both, playbooks should be written down first as runbooks, which the SOC Runbook Template supports; automating an undocumented process only hides it.

Cost and staffing

The ASD guidance notes that most SIEM pricing follows the volume of data ingested, that ingestion tends to grow, and that both platforms need skilled staff, often several people full time, plus continual training. SOAR adds a different cost: engineering time to build and maintain integrations as vendor APIs, credentials and processes change. Budget for that maintenance from the start, and count analyst hours saved only for playbooks that are actually running. A playbook that breaks quietly costs more than no playbook, because the team believes the work is being done.

Implementing in the right order

1. Stabilise detection. Tune SIEM rules until the top alert types have a known true positive rate; retire rules nobody acts on.
2. Document runbooks. For the five highest-volume alert types, write the manual steps, decision points and evidence to keep. A shared format such as OASIS CACAO Security Playbooks v2.0 (Committee Specification 01) helps where playbooks are exchanged between teams or tools.
3. Automate tier 1 first. Enrichment, deduplication and ticketing; measure analyst time saved.
4. Add tier 2 and 3 in shadow mode. Let playbooks record the action they would have taken, compare with analyst decisions for several weeks, then enable approval-gated execution.
5. Put playbooks under change control. Version them, peer review changes, test in a staging tenant, and include legal or GRC staff where an action has regulatory effect, as the ASD guidance recommends.
6. Test continuously. Replay known techniques end to end and confirm the SIEM alerts and the SOAR action runs as intended, with no pipeline bottlenecks.

Rollback: every containment playbook needs a paired reversal playbook, and a kill switch that sets all automated actions back to approval-only during an outage or suspected compromise.

Detection and measurement

• Mean time to respond for automated versus manual cases of the same alert type.
• Analyst minutes per alert before and after each playbook goes live.
• Automation accuracy: share of automated containment actions later judged correct, and the count reversed.
• Playbook failure rate: runs that errored on a broken integration, expired credential or API change.
• SIEM alert true positive rate, which caps what any automation can achieve.
• Coverage: share of alert volume handled by at least one playbook.

Alert on the SOAR itself: connector credential failures, playbook edits outside change windows, and spikes in disruptive actions.

Common failure patterns

• Buying SOAR to fix a noisy SIEM. Automation multiplies whatever quality the alerts already have.
• Auto-containment on single weak signals, isolating executives' laptops or production servers on a false positive.
• Over-privileged connectors using global admin or full API scopes because they were quicker to set up.
• Playbooks nobody maintains, silently failing after an API or credential change.
• Two case queues, one in the SIEM and one in the SOAR, so metrics and ownership split.
• Disabling a service account without checking dependencies, causing an outage worse than the alert.

Framework mapping

NIST SP 800-61 Rev. 3 (April 2025) frames incident response as part of risk management under CSF 2.0; use it to place both tools within your response plan.

Decision checklist

• Do your top five alert types have a measured true positive rate?
• Are runbooks written for them, with decision points and owners?
• How many tools must be touched in a typical response?
• Can your SIEM's built-in automation cover the workflows you need?
• Who will maintain integrations and credentials when APIs change?
• Which actions may run without a human, and who signed that off?

Practitioner checklist

• Measure SIEM alert quality before scoping any automation.
• Write runbooks for the highest-volume alerts and automate enrichment first.
• Classify every action by tier, with trigger confidence, approver and rollback.
• Run new containment playbooks in shadow mode before enabling them.
• Vault SOAR connector credentials, scope them to least privilege and rotate them.
• Forward SOAR action logs to the SIEM and alert on unusual actions.
• Keep one case queue and one set of response metrics.
• Pair each containment playbook with a tested reversal and a global kill switch.

Standards and references

• ASD's ACSC: Implementing SIEM and SOAR Platforms, Executive Guidance
• ASD's ACSC: Implementing SIEM and SOAR Platforms, Practitioner Guidance
• CISA: Guidance for SIEM and SOAR Implementation
• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• OASIS: CACAO Security Playbooks Version 2.0
• NIST: SP 800-92 Rev. 1 (Initial Public Draft), Cybersecurity Log Management Planning Guide
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls

Related NHI Mgmt Group resources: SOAR and Security Automation Guide · SIEM Guide · SIEM vs XDR · Security Automation Maturity Model · SOAR Buyer's Guide