What Is SOAR? Security Orchestration, Automation and Response

Orchestration is the integration layer. A SOAR platform holds connectors to the tools an organization already runs — the SIEM, endpoint detection, firewalls, identity provider, email gateway, ticketing system, threat-intelligence sources, cloud consoles — and can query and command each through its API. This is unglamorous and it is where most of the platform's value and most of its maintenance sit, because a workflow can only do what its connectors permit.

Automation is the execution of defined steps without a human in the loop. It covers enrichment, which gathers information and changes nothing, and action, which changes something in the environment: isolating a host, disabling an account, blocking an address, pulling a message from mailboxes. The distinction between the two is the single most important line in a SOAR design, because enrichment is nearly risk-free and action is not.

Response is the case-management and coordination half. The platform maintains an incident record, assembles the evidence collected, tracks who did what and when, escalates on defined criteria, and produces the timeline that an after-action review or a regulator asks for. Teams that already run mature ticketing sometimes underrate this component, and then discover that a general-purpose ticket has nowhere sensible to put a process tree or a set of indicators.

Phishing is the canonical example because it is high-volume, highly repetitive and genuinely automatable. A user reports a suspicious message. The playbook parses the email, extracts the sender, links and attachments, and checks each against threat-intelligence sources. It detonates the attachment or the URL in a sandbox and records the verdict. It searches the mail gateway for every other recipient of the same message. If the verdict is malicious, it removes the message from all mailboxes, blocks the sender and the destination, checks endpoint telemetry for anyone who clicked, opens a case with everything attached, and replies to the reporter. Work that occupies an analyst for twenty to forty minutes finishes in under two, and the twentieth report of the morning is handled exactly like the first.

The same pattern applies elsewhere. A malware alert triggers host isolation, memory and process collection, hash reputation lookup and a search for the same indicators across the estate. A suspicious login triggers geolocation and travel-feasibility checks, a review of recent activity for that identity, a session revocation, and a request for the user to confirm. A vulnerability disclosure triggers an asset query for affected versions and opens remediation tickets against the owners.

The structural insight is that most playbooks are mostly enrichment. Gathering, correlating and presenting evidence is where the time goes, and automating only that half — leaving every environment-changing action to a human — already recovers the majority of the benefit at close to zero risk. Teams that start there tend to succeed; teams that start by automating containment tend to build something nobody is willing to switch on.

A SIEM aggregates and correlates log data from across an environment, applies detection rules, raises alerts and retains the record for investigation and compliance. It is a detection and visibility layer, and it does not act on what it finds. A SOAR platform sits downstream of that: it consumes the alert, orchestrates the tools that can do something about it, and manages the resulting case. The division is clean — the SIEM decides that something is worth attention, and the SOAR decides and executes what happens next.

XDR overlaps with both and comes at the problem from the other direction. Rather than integrating whatever an organization already owns, it ships pre-integrated detection and response across one vendor's endpoint, network, email, identity and cloud telemetry, with automated response built in. That is faster to deploy and less flexible: the automation reaches the vendor's own products well and third-party tools less well, which is precisely the gap SOAR exists to cover in a heterogeneous estate.

Managed detection and response is orthogonal to all three because it is a service rather than a product — human analysts, often running a stack that includes some or all of the above, delivering monitoring and response as an outsourced capability. An organization can reasonably buy a SIEM for breadth and retention, use an XDR platform for depth on the endpoints, add automation for the repetitive work, and contract MDR to staff the overnight rota, and none of those decisions makes the others redundant.

Integration maintenance is the first and largest problem. Every connector is a dependency on somebody else's API, and APIs change. A platform with forty integrations has forty things that can break quietly, and a playbook that fails at step six leaves an incident half-handled — arguably worse than not automating it, because the team believes it was handled. Budget ongoing engineering time rather than a one-off implementation project, and insist on error handling and alerting inside the playbooks themselves.

Trust is the second. Automated actions that change the environment carry blast radius, and nobody sensible authorizes automatic isolation of a domain controller or automatic disabling of an executive's account. The workable pattern is graduated: automate enrichment freely, automate low-impact actions on low-value assets, and require approval for anything that could take down something important — with the approval step inside the playbook so the rest of the work is already done when the human arrives. Some categories should stay manual permanently, and saying so in the design is a sign of maturity rather than timidity.

The third is that automation amplifies whatever it is fed. A SOAR platform wired to a poorly tuned SIEM will execute thousands of playbooks against false positives, consuming API quota and analyst attention faster than the manual process it replaced. Detection quality is a prerequisite, not something automation fixes. And playbooks rot: applications get replaced, processes change, and a playbook written eighteen months ago may be quietly querying a system that was decommissioned. Reviewing and testing them on a schedule is part of owning the platform.

Gartner never published a Magic Quadrant for SOAR — the market was covered by a Market Guide, with editions running through 2023 before that coverage began folding into Gartner's SIEM research — and the direction of travel in the market is clear: orchestration and automation capability is increasingly delivered inside SIEM, XDR and detection platforms rather than purchased as a separate product, and AI-assisted investigation features are being layered on top of both. For a buyer, that mostly changes the shape of the procurement rather than the requirement — the questions to ask are which of your existing platforms already includes automation, how good its third-party integrations are, and whether a dedicated tool is still needed to reach the products the incumbent does not cover well.

The reason to be careful with the 'SOAR is dead' framing is that the underlying need has not moved. Alert volumes have not fallen, analyst supply has not improved, and the mechanical portion of investigation work is as mechanical as it ever was. Whether the automation engine is a standalone platform or a module inside the detection stack, something has to do the enrichment, hold the case and execute the repeatable steps consistently.

The practical evaluation criteria are therefore about capability rather than category. How many of your actual tools have first-class, maintained connectors. Whether playbooks can be built and tested by the people who run the SOC or require specialist developers. What happens when a step fails. Whether approval gates are native. Whether the licensing meters actions, workflows or analysts, because that decides whether the platform is affordable at the volume you would actually run it.

Automation now appears explicitly in government procurement guidance. In May 2025 CISA, with Australia's ACSC and international partners, published a three-document package on implementing SIEM and SOAR platforms: executive guidance framing the decision, practitioner guidance covering deployment, and a separate document on prioritizing which logs to ingest. It is vendor-neutral, freely available, and a reasonable scoping reference for an organization writing requirements rather than reading marketing.

The revised incident-response guidance points the same way. NIST SP 800-61r3, published in April 2025, restructures incident response around the Cybersecurity Framework 2.0 functions, which places Respond and Recover alongside Detect rather than treating response as a downstream afterthought. An organization documenting its incident-response capability against that structure will find it easier to say what its automation does than to say that it has some.

One caution specific to regulated environments. Automated actions that change access, isolate systems or delete messages are consequential, and the audit record of who or what authorized them is part of the control. Confirm that the platform logs the decision, the approval and the executed action in a form your auditors can read, and that its own administrative access is governed as tightly as the tools it commands — a system that can disable any account and isolate any host is one of the highest-value targets in the environment.