Continue your mission
A practitioner's guide to evaluating, selecting, and deploying Security Orchestration, Automation, and Response platforms. Covers the major platforms, selection criteria, implementation methodology, build vs. buy tradeoffs, and ROI measurement.
Security Orchestration, Automation, and Response (SOAR) is a category of security technology that enables SOC teams to coordinate tools, automate repetitive tasks, and manage the full lifecycle of security incidents from a single platform. The term was coined by Gartner in 2017 to unify three previously distinct capabilities: security orchestration (connecting tools via APIs), security automation (executing tasks without human intervention), and incident response case management (tracking, documenting, and resolving incidents).
The problem SOAR solves is a structural one. Modern SOC teams operate across dozens of disconnected tools: SIEM, EDR, threat intelligence platforms, ticketing systems, email security gateways, firewall management consoles, and identity providers. When an alert fires, an analyst manually queries each tool, pivots between interfaces, copies data into tickets, and executes remediation steps one at a time. This manual workflow does not scale. Alert volumes across the industry have grown faster than analyst headcount for over a decade, and the mean time to triage, the elapsed time between alert creation and analyst determination, has climbed alongside them.
SOAR addresses this by encoding analyst decision logic into automated playbooks. When a phishing email arrives, a SOAR platform can extract indicators, query reputation sources, check endpoint telemetry, and block infrastructure, all before a human sees the ticket. What took forty-five minutes of analyst time can take under two minutes of automated processing, with the human reviewing output rather than collecting input.
SOAR is not a replacement for skilled analysts. It is a force multiplier that lets experienced practitioners focus on ambiguous, high-stakes decisions while the platform handles the deterministic, repeatable ones.
---
A SOAR platform has four core components working together.
The integration layer connects the platform to every other tool in the security stack via pre-built connectors (typically API-based). The breadth of this integration library is one of the most important differentiators between platforms. A platform with 300 native integrations requires far less custom development than one with 80.
The playbook engine is the automation runtime. Analysts or engineers define playbooks as workflows (visual flowcharts, code, or a hybrid) that describe exactly what the platform should do when a specific trigger occurs. A phishing playbook might branch based on the result of a URL reputation check: if malicious, execute block and quarantine; if benign, mark false positive and update filter rules; if inconclusive, escalate to analyst.
The case management system tracks every incident from creation through resolution. It stores all automated actions taken, analyst notes, timeline events, and remediation outcomes. This is distinct from SIEM case management: SOAR case management is action-oriented, not just logging-oriented.
The threat intelligence integration layer enriches indicators and events with external context. Most SOAR platforms can query threat intelligence platforms (TIPs) like MISP, ThreatConnect, or Anomali as part of playbook execution, so every alert arrives with reputation data, threat actor associations, and historical sighting information already populated.
Palo Alto XSOAR (formerly Demisto, acquired 2019) is the market incumbent. It carries the most extensive integration library in the category (over 700 content packs), supports sophisticated playbook logic including loops, sub-playbooks, and custom Python scripts, and has the deepest enterprise deployment base. The tradeoff: XSOAR playbooks use a custom graphical editor that becomes complex at scale, and the platform requires significant engineering investment to operate well. It is the right choice for mature SOC organizations with dedicated automation engineers.
Splunk SOAR (formerly Phantom, acquired 2018) competes directly with XSOAR and integrates tightly with Splunk SIEM. Playbooks are Python-based, which appeals to teams with development capability. If your SIEM is Splunk, SOAR creates a tightly coupled detection-to-response pipeline. The licensing model is per-automation-action, which can produce cost surprises at scale.
Swimlane differentiates on case management quality. Its turbine architecture separates the automation engine from the UI, enabling high throughput at scale. It has strong reporting capabilities and a code-optional playbook builder, making it more accessible to analyst-tier operators. Organizations that care as much about case metrics (MTTR, analyst workload, escalation rates) as about automation throughput tend to prefer Swimlane.
Tines represents a newer architectural philosophy. Rather than the traditional playbook model, Tines uses "stories," a visual workflow builder with no proprietary scripting language. Every action in a story is either an HTTP request, a formula, or a condition, which means any analyst who understands web APIs can build automations without learning a platform-specific SDK. The low-code model reduces the engineering barrier significantly, though complex branching logic can become verbose. Tines is the right choice for teams without dedicated automation engineers who still need meaningful automation coverage.
Shuffle is the open-source option. Docker-based and community-supported, Shuffle provides a SOAR-like capability at near-zero licensing cost. Integration quality varies with community contribution. It is appropriate for smaller organizations with engineering capability and cost constraints, or as a testing environment before committing to a commercial platform.
When evaluating any SOAR platform, audit your existing tool stack against the platform's native integration list before procurement. A connector that already handles authentication, pagination, and error handling saves twenty to forty engineering hours compared to building a custom integration. Prioritize platforms with pre-built integrations for your SIEM, your EDR, your email security gateway, your identity provider, and your ticketing system. Those five categories cover the majority of playbook actions in most SOC environments.
---
The cybersecurity workforce shortage is well-documented. CyberSeek data consistently shows hundreds of thousands of unfilled security roles in the United States alone. Organizations cannot hire their way out of alert volume. SOAR allows a team of ten analysts to handle the alert throughput that previously required twenty, by removing the manual triage work that consumes the majority of analyst time during a shift.
The business case is straightforward: if a SOAR playbook reduces phishing triage time from forty-five minutes to two minutes, and the SOC handles 200 phishing cases per month, that is 8,600 analyst-minutes (roughly 143 analyst-hours) recovered per month. At a fully-loaded analyst cost of $75/hour, that is approximately $10,750 per month in recovered capacity, or $129,000 annually, from a single playbook targeting a single use case.
Without automation, SOC teams triage in order of alert arrival rather than by actual severity. Analysts get fatigued processing high-volume, low-complexity alerts (phishing, basic malware, failed authentication) before they ever reach the sophisticated, low-volume attacks (lateral movement, living-off-the-land techniques, supply chain indicators) that actually represent existential risk. Alert fatigue leads to missed detections. Missed detections lead to breaches. SOAR is not a productivity tool: it is a risk reduction mechanism.
The most common SOAR failure mode is over-scoping on initial deployment. Organizations procure a platform, assign an ambitious automation roadmap covering thirty use cases, spend six to nine months building playbooks, and deploy a system that is simultaneously complex and fragile. The correct approach is the opposite: start with three to five high-volume, well-understood use cases where the decision logic is deterministic, measure improvement, and expand only after the core use cases are stable.
A second misconception is that SOAR automates security decisions. It automates security actions based on pre-defined decision logic. The difference matters. Analysts still define what constitutes malicious, what constitutes suspicious, and what constitutes benign. SOAR executes that logic at machine speed, but the intelligence behind it is still human.
---
Phase one is use case selection. Identify the three to five highest-volume, most-understood workflows in your current SOC operations. Phishing triage is almost always the right first use case: it is the highest volume alert category in most environments, the decision logic is well-defined, the integrations required (email security, URL reputation, file hash lookup, mailbox quarantine) are standard, and the ROI is immediately measurable.
Phase two is process documentation before automation. Map every manual step in the current process, including every tool queried, every decision made, and every action taken. If the process is not documented and consistent, automation will encode the inconsistency. Document first; automate second.
Phase three is integration buildout. Deploy only the integrations required for the first use case. Resist the temptation to connect every tool in the stack before the first playbook goes live. Scope management here directly determines deployment timeline.
Phase four is playbook development in a staging environment. Test against synthetic and historical alert data. Validate decision logic, test error handling for API failures, and ensure audit logging captures every automated action. Every automated action must be logged with timestamp, action taken, result, and the playbook version that executed it.
Phase five is phased rollout. Run the playbook in "shadow mode" for one to two weeks, meaning it executes the analysis and logs what it would have done, but takes no automated action. Compare shadow-mode outputs to analyst decisions during the same period. Tune for accuracy before enabling automated actions.
Baseline metrics to capture before deployment: average time-to-triage per use case (in minutes), monthly alert volume per use case, and analyst fully-loaded hourly rate.
Post-deployment metrics: automated time-to-triage (typically seconds to low minutes), analyst review time per automated case, escalation rate (percentage of cases requiring human intervention), and false positive rate.
ROI formula: (pre-automation analyst minutes - post-automation analyst review minutes) x monthly volume x (hourly rate / 60) = monthly savings. Apply this per use case and sum across the automation portfolio to produce aggregate ROI.
Full SOAR platforms (XSOAR, Splunk SOAR) offer maximum capability and integration breadth but require dedicated automation engineers (typically with Python skills) to build and maintain playbooks. Budget 0.5 to 1.0 FTE for playbook development and maintenance for the first year.
Low-code platforms (Tines, Torq) trade some capability depth for accessibility. An experienced SOC analyst without software engineering background can build functional automations using these platforms. The development velocity is higher and the bus-factor risk (single engineer who knows the platform) is lower. The tradeoff is hitting capability ceilings for complex orchestration scenarios.
Open-source (Shuffle) trades vendor support and integration quality for cost. Appropriate for organizations with internal engineering capability and budget constraints.
---
SOAR sits at the operational core of CDA's Threat Intelligence & Defense (TID) domain. TID is the atmosphere layer of the Planetary Defense Model: it represents the organization's active sensing and response capability, the layer that detects incoming threats before they reach the defended surface.
CDA's TID methodology is Predictive Defense Intelligence (PDI): "See the threat before it sees you." SOAR is the execution layer of PDI. PDI without automation is intelligence that cannot act fast enough. Detection-to-response latency measured in minutes or hours (the manual SOC reality) gives adversaries operating windows that organized threat actors actively exploit. SOAR closes that window.
In the CDA campaign model, SOAR implementation maps to C-HARDEN and C-DRILL campaign phases. C-HARDEN establishes the automation infrastructure and baseline playbooks. C-DRILL validates that the platform performs under simulated attack conditions, including testing that playbooks fire correctly, escalations route properly, and audit logs capture every action taken.
CDA's approach to SOAR implementation diverges from conventional consulting methodology in one important respect: we build the measurement framework before the first playbook deploys. Most organizations automate first and measure later. CDA measures first (establishing baselines for MTTR, analyst hours per use case, and alert throughput) so that every automation can be evaluated against a concrete ROI calculation. This turns SOAR from a technology investment into a measurable business outcome.
For organizations in the CDArmy workforce program, SOAR playbook development and maintenance is a certifiable skill tracked under TID missions. Analysts who demonstrate proficiency in at least two production playbooks with documented ROI earn mission credit toward TID campaign advancement.
---
---
---
docs/canon/pdi-predictive-defense-intelligence.mdCDA Theater missions that address topics covered in this article.
Written by Evan Morgan
Found an issue? Help improve this article.