What is SOAR?

Microsoft's Sentinel documentation says SOAR is there to automate "any recurring and predictable enrichment, response, and remediation tasks" so analysts have time for investigation and hunting. In May 2025 CISA, Australia's ASD's ACSC and other partners published joint guidance on implementing SIEM and SOAR platforms; the practitioner part covers using them to speed up incident response by automating predefined actions based on detected anomalies.

What the three letters do

The Sentinel docs add two practical details. An automation rule can carry an expiration date, which is how you auto-close the noise from a penetration test that ends on Friday without leaving the rule running forever. And roles are separate: attaching a playbook to a rule, running one by hand and letting automation rules run playbooks are three different permissions (Microsoft Sentinel Contributor, Playbook Operator and Automation Contributor).

SIEM vs SOAR

The handoff between them is the entity. In Sentinel, entity mapping in the analytics rule is what turns a query result into the account, host and IP objects that a playbook can act on. A rule can define up to 10 entity mappings, and a single alert can carry up to 500 entities in total; anything over that limit is not extracted. If the detection never maps the sender address or the URL, the phishing playbook downstream has nothing to look up.

You do not strictly need a SIEM to run SOAR. A playbook can start from an EDR alert, a mail gateway or a reported-phish mailbox. In practice the SIEM is the usual feeder because it is where the alerts from every other tool already meet. SIEM use cases and best SIEM tools cover the detection side.

A phishing playbook, step by step

User-reported phishing is where most teams start: the volume is high, the checks are always the same, and many reports are harmless. Microsoft Defender for Office 365 Plan 2 ships this as automated investigation and response (AIR). A user submission is one of the alert types that starts an automated investigation, and Microsoft notes that AIR resolving an investigation by itself because no threat was found is common in user submission scenarios.

With Defender data in Microsoft Sentinel or in advanced hunting, the enrichment reads three tables:

1. EmailEvents finds the reported message by NetworkMessageId and then its copies in other mailboxes, with SenderFromAddress, Subject, AuthenticationDetails (the SPF, DKIM and DMARC verdicts), DeliveryAction and LatestDeliveryLocation.
2. UrlClickEvents answers who clicked. It joins on NetworkMessageId and returns AccountUpn, Url, ActionType (whether Safe Links allowed or blocked the click) and IsClickedThrough, which is true when the user went past the Safe Links warning.
3. AlertEvidence shows what other alerts already reference that message, through its own NetworkMessageId column, along with any account, device or URL they name.

// One reported message: its copies, who clicked, and alerts that reference it
let reported = "<NetworkMessageId from the incident>";
let lure = EmailEvents
| where NetworkMessageId == reported
| take 1
| project SenderFromAddress, Subject;
EmailEvents
| where Timestamp > ago(7d)
| join kind=inner lure on SenderFromAddress, Subject
| project NetworkMessageId, RecipientEmailAddress, DeliveryAction,
    LatestDeliveryLocation, AuthenticationDetails
| join kind=leftouter (
    UrlClickEvents
    | where Timestamp > ago(7d)
    | project NetworkMessageId, AccountUpn, Url, ActionType, IsClickedThrough, ClickTime = Timestamp
  ) on NetworkMessageId
| join kind=leftouter (
    AlertEvidence
    | where Timestamp > ago(7d) and isnotempty(NetworkMessageId)
    | summarize Alerts = make_set(Title, 10) by NetworkMessageId
  ) on NetworkMessageId
| project RecipientEmailAddress, DeliveryAction, LatestDeliveryLocation,
    AuthenticationDetails, AccountUpn, Url, ActionType, IsClickedThrough, ClickTime, Alerts

The query follows Microsoft's documented schemas for the three tables and has not been run by SOCSimulator against a live tenant. Matching on sender and subject is deliberately rough; Defender's own EmailClusterId groups similar messages more reliably when you have it. Clicks from mail in Drafts or Sent Items have no usable NetworkMessageId, so they cannot be joined back to EmailEvents this way.

The design decisions are in what the playbook does with the result:

The SOC playbooks guide and our investigation playbooks lay out the manual version of these steps, which is what you automate.

When a playbook gets it wrong

Simulated example generated by SOCSimulator Research. Hosts, incident numbers and times are invented; product and action names are Microsoft's.

02:14:07  Sentinel incident 4182 created   "Suspicious credential access"   Host: HV-NODE03   Severity: High
02:14:09  Automation rule "High severity endpoint -> isolate" runs playbook Isolate-MDE-Device
02:14:15  Defender for Endpoint action: Isolate device HV-NODE03 (Full)   Status: Succeeded
02:16:40  Monitoring: 14 virtual machines on HV-NODE03 unreachable (SQL-PROD01, APP-PROD02, ...)
02:31:02  Analyst review: alerting process is the signed backup agent on its nightly schedule
02:33:18  Release from isolation HV-NODE03; incident closed as benign positive

The playbook did what it was built to do: it treated severity as proof and isolated a hypervisor. Microsoft's isolation documentation warns about this case: isolating a server running Hyper-V blocks network traffic to all of its child virtual machines. The same page warns that devices behind web proxies may not recover from full isolation, and recommends selective isolation there. Microsoft's own automatic isolation, part of automatic attack disruption, only applies to end-user workstations. Splunk's playbook documentation adds one more failure: if the SOAR system restarts mid-run, the run is cancelled and the changes it already made stay in place. Nothing is rolled back.

Keep destructive actions (isolate, disable, delete) behind an approval step until the playbook has a track record. Scope containment by device group so servers never take the automatic path. And log every run so the post-incident review can see which action came from the playbook and which came from a person.

SIEM vs SOAR vs XDR

XDR correlates telemetry from its own sensors (endpoint, identity, email, cloud apps) and ships with response built in: Defender XDR investigates email threats automatically through AIR in Defender for Office 365 and can isolate devices without a separate SOAR product. Microsoft describes Sentinel as both a SIEM and a SOAR platform, and SOAR as a separate product earns its place mainly when your tools come from many vendors and something has to make them work together. EDR vs antivirus vs XDR covers the endpoint side, and SOC tools places all three in a working stack.