Buying SOAR

Buyer's guide.

Evaluation criteria

SOAR evaluation is the discipline of comparing integration breadth, playbook flexibility, and operational fit together. One axis alone produces bad picks; teams that score on integration count without testing operational fit end up with a tool the SOC will not use.

• Integration breadth. SIEM, EDR, ticketing, and communication-tool connectors per vendor. SOAR depends on connecting to the existing stack; missing connectors become weeks of custom integration work.
• Playbook flexibility. Pre-built plus custom mix. Most teams need both; pre-built covers the standard cases, custom handles the team's actual workflow.
• Operational fit. SOC workflow match per team. Big mismatches break adoption regardless of how good the playbook library looks in a demo.
• Proof-of-value. 30 to 90 day POC against the team's real alerts. Catches integration gaps and workflow mismatches before the purchase order signs.

Major options

The market has narrowed to a few credible picks. Each fits a different shape of org; the choice is rarely about features alone.

• Splunk SOAR (Phantom). Mature, Splunk-integrated, broad-ecosystem option. Default pick for teams already on Splunk for SIEM.
• Palo Alto Cortex XSOAR. Enterprise-focused with a rich playbook library. Expensive but full-featured; the right pick when the playbook library is the deciding axis.
• Tines, Torq. Modern UX with YAML-driven workflows. Newer entrants growing rapidly; lower implementation friction for teams without a dedicated SOAR engineer.
• Workflow-as-code support. Version-control fit per vendor. Workflows live in git, get peer-reviewed, and roll back like code; without it, change review is a screenshot in a Jira ticket.

Scope of automation

Scope decides risk. Triage, investigation, and response each have different blast radius; the right scope grows over time as trust accrues, not all at once.

• Triage automation. Enrichment, classification, and severity assignment per alert. High value, low risk; the natural starting point for every program.
• Investigation automation. Context pull, playbook run, and finding surface per incident. Reduces analyst time and standardises the questions asked during triage.
• Response automation. Containment per incident: isolate host, disable account, block IP. High risk; requires careful approval gates and a tested rollback path.
• Approval gate per action. Explicit human approval on response actions until the action has run a few hundred times without incident. Catches automation overreach before it produces a self-inflicted outage.

Rollout pattern

The rollout is staged by risk. Triage first, response last; trust earned at each stage funds the next, and reversing the order is how SOAR programs get cancelled in their first year.

• Start with triage and investigation. Low-risk automations first per program. Builds trust with analysts and surfaces integration issues while the blast radius is bounded.
• Response automation gradually. Deliberate addition per automation. Review each new response action against the false-positive rate of the alerts that trigger it.
• Monthly outcome review. False-positive rate, missed cases, and analyst time savings per month. Tune accordingly; cancel automations that do not earn their seat.
• Rollback plan per rollout. Disable switch per automation. Recovery from a misbehaving playbook is one click rather than a code change.

Cost considerations

Cost has two dials: licence and implementation. Both add up; the implementation tail is the one that surprises finance, not the licence.

• Per-action pricing common. Per-action billing per vendor. High-volume automations can be expensive; tune the trigger criteria to avoid runaway costs from noisy alert sources.
• Implementation cost beyond licence. Weeks of build per integration, real and often understated. Budget two to four times the licence cost for the first year.
• Vendor-managed playbooks versus custom. Maintained library per vendor. Trade flexibility for ongoing maintenance; vendor-maintained playbooks update with the stack but constrain customisation.
• Named program owner. One responsible team. Supports operational reviews and prevents the SOAR program from becoming "everyone's job and therefore no one's".