SOAR Platform Evaluation and Procurement Guide for Australian Enterprises

A security orchestration, automation and response (SOAR) platform connects security tools and runs response steps without an analyst doing each one by hand. Bought well, it shortens the time between an alert and a containment action. Bought badly, it becomes a second console full of playbooks nobody trusts enough to switch on. Which of those you get is mostly settled during procurement. It depends on how precisely the organisation defines what it wants automated and who is accountable when automation acts.

CYBORIUM helps Australian organisations compare SOAR platforms, and the partners who implement them, through a structured vendor-neutral sourcing process. The selected provider pays CYBORIUM a capped fee. The client contracts directly with that provider, and CYBORIUM does not sell, deliver, operate or invoice the technology.

Decide what may run without a person

Before looking at products, list the response actions your team performs repeatedly. Sort them into three groups: actions that can run automatically, actions that need an analyst to approve, and actions that must stay manual. Enriching an alert with threat intelligence is usually safe to automate. Disabling an executive’s account or isolating a production server usually is not, at least not without approval.

This list becomes the core of the requirement. It also shows early whether a SOAR platform is the right purchase at all. If most of your candidate actions sit in the manual group, the automation already built into your SIEM, EDR or XDR platform may cover what is left. A separate SOAR licence then adds cost without much return.

Five areas that decide SOAR value

1. Integration depth for your actual stack

Give vendors your tool inventory, including versions and whether each is cloud or on-premises. Ask them to mark every integration as native and maintained by the vendor, community built, or custom work. A connector that can read alerts but cannot take a response action does not support a containment playbook. Ask which specific actions each connector supports.

2. Playbook reliability

Automation that fails silently is worse than no automation, because the team assumes the step happened. Ask how the platform handles an API timeout, an expired credential or a changed field name in a connected tool. Look for retry logic, failure alerts and a clear record of which step failed and why.

3. Approval and audit controls

Check that approval steps can be assigned by role, that approvals are logged with a time and a name, and that the case record can be exported. For regulated entities this record matters. APRA CPS 234 requires notification to APRA within 72 hours of becoming aware of a material information security incident. A reliable case timeline makes that assessment faster to defend.

4. Build and maintenance effort

Ask who writes and maintains playbooks after go-live. Low-code editors reduce the skill needed to build a workflow. They do not remove the need to test it when a connected product changes. Get an estimate of maintenance hours per month for the playbooks in your first release. Ask the vendor how it arrived at that figure.

5. Commercial model

SOAR pricing may be based on users, actions executed, playbooks, connectors or a bundle with a SIEM or XDR platform. Model the cost at your current alert volume and at two or three times that volume. If pricing is tied to executed actions, a successful automation programme can raise the bill, which is worth knowing before contract.

Where SOAR overlaps with SIEM and XDR

Many SIEM and XDR products now include automation features. Before running a SOAR evaluation, test whether your existing platform can already run the playbooks on your priority list. A separate SOAR platform usually earns its place when response needs to cross several vendors’ tools, when case management must sit outside any one detection product. It also earns its place when the organisation expects to change its detection platform and wants response logic that survives the change.

A comparable evaluation

Give every shortlisted vendor the same three to five scenarios, the same tool inventory and the same response template. Useful scenarios include a reported phishing email, a suspected compromised account and a malware detection on a laptop. Score written responses before any demonstration, then use the demonstration to confirm what was claimed. A practical scorecard covers:

• actions supported for each tool in your inventory;
• failure handling and alerting when a step does not complete;
• approval, logging and case export controls;
• playbook build and maintenance effort;
• data location, access controls and support arrangements; and
• three-year cost under agreed volume scenarios.

Proof-of-value design

Run the proof of value in your environment, against your tools, with the vendor’s engineer and your analyst in the same session. Build one playbook end to end, then break something on purpose: revoke an API key or change a field mapping. Record whether the platform notices, what it tells the analyst and how long recovery takes. That test says more about operating reality than a polished demonstration of a finished workflow.

Contract points to settle

The agreement should state who owns the playbooks the organisation builds, whether they can be exported in a usable form. It should also say what happens to case data at exit. Commercial schedules should define how actions, connectors or users are counted and how price changes with volume. If an implementation partner is involved, separate the platform vendor’s obligations from the partner’s build and support obligations. That way a failed playbook does not fall between two contracts.

CYBORIUM’s role in the decision

CYBORIUM can build the automation boundary, prepare the scenarios and response template, coordinate vendors, evaluate evidence, model cost at different volumes and support negotiation. The organisation keeps the decision and contracts directly with the provider it selects. Related guides cover SIEM evaluation and managed detection and response, which often form part of the same decision.

Updated 15 September 2026. This guide explains CYBORIUM’s procurement evaluation method. It does not provide legal or regulatory advice.

Standards and further reading

Automation claims are the hardest part of a SOAR evaluation to test, because every product demonstrates well on a scripted scenario. These three sources give you criteria a vendor cannot script around.

• MITRE ATT&CK. Name the specific techniques a playbook is supposed to detect and contain, then ask for the playbook against those technique IDs rather than a generic demonstration.
• NIST SP 800-61 Rev. 3. The incident handling lifecycle a SOAR platform is automating. If a playbook does not map to a phase in it, ask what it is actually for.
• ASD Essential Eight Maturity Model. Sets the maturity level your organisation is measured against, which determines how much of the response you are permitted to leave automated.

Last updated: 22 October 2026