A buyer’s guide · Operating since 2002
An analyst working a phishing report opens six consoles, copies a hash between three of them, checks who else received the message, and writes the same case note they wrote yesterday. None of that requires judgement. All of it takes minutes that compound across every alert of every shift.
SOAR removes that work. What it does not do is find anything — it automates the steps after a detection, and it is only ever as useful as the process it was given to encode.
The line
What is safe to automate, and what is not
Not a maturity ladder to climb. A line, drawn by how hard each action is to reverse.
Above the line, automate without hesitating
Enrichment, deduplication and case creation decide nothing. They gather context and put it where a person will see it. There is no scenario in which attaching an asset owner to an alert causes an outage.
This is also where most of the time saving actually is — not in the dramatic containment action, but in the minutes returned on every single alert, every shift.
Below it, the automation can be the incident
Isolating a host is the most valuable action available and the most dangerous. An automation that isolates a production database because a detection misfired has not contained an incident; it has caused one.
Confidence thresholds and exclusion lists — production systems, OT equipment, specific accounts — are not caution. They are the design, and they need agreeing with the people who own those systems before anything is enabled.
Playbooks
Six that earn their keep, in the order we build them
Concrete rather than categorical, because the useful question is not how many playbooks exist but what proportion of your real alert volume they touch.
Scroll the table sideways →
| Playbook | What it does | Why it pays | The honest caveat |
|---|---|---|---|
| Reported phishing | Pull the message, extract and detonate attachments and links, check who else received it, retract from every mailbox, close with a reply to the reporter. | Highest volume, lowest risk, fully reversible. | Start here. It is the playbook with the best ratio of time saved to trouble caused, and the reply to the reporter is what keeps people reporting. |
| Alert enrichment | Attach reputation, asset owner, user role, recent related alerts and prior cases before a human opens the ticket. | Saves analyst minutes on every single alert. | Boring and enormously valuable. It does not decide anything, which is exactly why it carries no risk. |
| Credential compromise | Terminate active sessions, force reset, review MFA methods added, check inbox rules and delegate permissions, list what the account touched. | Session termination is the step humans forget under pressure. | A password reset alone leaves an existing token working. Automating the full sequence removes that gap. |
| Malicious indicator blocking | Push a confirmed hash, domain or IP to firewall, proxy, DNS and endpoint tooling in one action. | Removes the cross-console tab-switching that wastes real minutes. | Needs an expiry and a rollback path. Blocklists without review dates become their own incident eventually. |
| Host isolation | Remove a host from the network while retaining an investigation path to it. | The most valuable and most dangerous action on this list. | Automate only above a confidence threshold, with exclusions for production and OT systems. Getting this wrong is an outage you caused. |
| Compliance evidence | Assemble timeline, actions taken, approvals and artefacts into a case record as the incident progresses. | Built during the incident, not reconstructed afterwards. | The reconstruction is what nobody has time for, so it silently does not happen. Doing it live is the whole point. |
Phishing first, every time. High volume, low risk, fully reversible, and it ends with a reply to the person who reported it — which is what keeps people reporting. It also produces a visible saving within weeks, which is what keeps a programme funded long enough to reach the harder work.
Straight answers
What buyers get wrong about SOAR
SOAR improves nothing about what gets detected
It automates the steps that follow a detection. If your detection coverage has gaps, SOAR makes you faster at responding to the incidents you already saw and does nothing whatsoever about the ones you did not. Buying it to fix a detection problem is the most expensive misunderstanding in this category — that problem lives in collection and telemetry.
You cannot automate a decision nobody has written down
Most failed SOAR programmes began by buying the platform and then discovering the process did not exist in a form anyone could encode. Automation does not create rigour; it multiplies whatever rigour is already there, in both directions. Writing the runbook first is unglamorous and it is the actual work.
“How many playbooks do you have?” is the wrong question
Playbook count is a vanity metric. Three playbooks covering eighty per cent of alert volume are worth far more than forty covering the interesting cases nobody sees twice a year. Ask what proportion of your actual incidents a playbook touches.
Automated containment can cause the outage
Isolating a host is the most valuable action on the list and the most dangerous. An automation that isolates a production database because a detection misfired has caused an incident rather than contained one. Confidence thresholds and exclusion lists are not caution — they are the design.
“Who maintains this in a year?”
Playbooks rot quietly. An API version changes, a connector breaks, and nobody finds out until the playbook fails during the incident it was built for. Maintenance is a standing responsibility, not a project phase.
The best first playbook is phishing
It is high volume, low risk, fully reversible, and it ends with a reply to the person who reported it — which is what keeps people reporting. It also produces a visible time saving within weeks, which is what keeps the programme funded long enough to reach the harder work.
Before you sign
Ten questions for any SOAR provider
Use these on us and on everyone else. Question one prevents the most common failure, and question ten tells you whether they have run an incident.
Do we have the runbook written down before we automate it?
The single most common cause of failed SOAR programmes. Automation makes an undocumented process faster and more wrong, at scale, at three in the morning.
Which actions can fire without a human, and what cannot they touch?
Ask for the exclusion list — production servers, OT equipment, executive accounts. An automation with no exclusions will eventually reach something it should not.
What threshold triggers automated containment?
“High confidence” is not a threshold. Ask what score, from which detections, with what false-positive rate behind it.
How is an automated action reversed, and how quickly?
Every automated action needs an undo that a tired person can perform at 3 a.m. without reading documentation.
Who maintains the playbooks as the estate changes?
Playbooks rot. An integration breaks silently when an API version changes, and nobody notices until the playbook fails during a real incident.
Which of our tools does this genuinely integrate with, at what depth?
A connector that only reads is not the same as one that can act. Ask which actions are available per tool, not which logos appear on a slide.
What do you measure — playbooks built, or analyst time returned?
Playbook count is a vanity metric. The number that matters is time saved per incident and the reduction in steps a human performs.
What happens when a playbook fails halfway through?
Partial execution is the dangerous state. Ask how it is detected, who is told, and what the system does with a half-contained incident.
Do we own the playbooks, and can they be exported?
Playbooks encode your process and your decisions. If they live only in a rented platform, that knowledge leaves with the contract.
What should we not automate?
A provider who wants to automate everything has not run an incident. The useful answer names something and explains why a human belongs there.
Working with us
How we run this
SOAR is how our analysts stop doing repeatable work by hand. It is not a platform we hand over and leave — the exceptions are ours to own, and the exceptions are where the incidents are.
Runbook before playbook
We write the decision down with your team first. If a process cannot be described in a sentence, automating it will not improve it.
Phishing first
Highest volume, lowest risk, visible saving within weeks. The programme needs an early win to survive to the harder playbooks.
Exclusions agreed up front
Production and OT systems are excluded from automated containment by default, and the list is signed off by the people who own them.
We own the exceptions
When a playbook fails halfway, an analyst picks it up. A half-contained incident nobody is watching is worse than no automation.
Measured in analyst time
Reported as time returned per incident, not as a count of playbooks built.
Playbooks are yours
They encode your process. Built in a form that transfers if the engagement ends.
Questions we get asked
SOAR, answered
What is SOAR?
Security orchestration, automation and response. It connects the tools you already run and executes agreed sequences of actions automatically when something is detected — enriching an alert, opening a case, disabling an account, blocking an indicator. The orchestration part matters as much as the automation: much of the value is simply removing the cross-console tab-switching an analyst does by hand.
What is the difference between SOAR and SIEM?
A SIEM detects — it collects logs, correlates them and raises alerts. SOAR acts on what has been detected. They sit either side of the same moment and neither substitutes for the other: a SOAR platform with poor detection behind it responds quickly to a fraction of what is happening, and a SIEM with no automation produces alerts a human must work through manually. See managed SIEM for the detection side.
How does SOAR differ from XDR?
XDR bundles detection and a set of vendor-written response actions across the sources that vendor supports. SOAR is vendor-neutral orchestration across whatever tools you own, including the ones the XDR vendor has never heard of. Organisations with a single-vendor estate often find XDR sufficient; mixed estates are where SOAR earns its cost.
What should we automate first?
Reported phishing, almost always. It is high volume, low risk, fully reversible, and it ends by replying to the person who reported it, which is what keeps people reporting in future. Alert enrichment is the close second — it decides nothing, so it carries no risk, and it saves minutes on every single alert rather than on the occasional dramatic one.
What should we not automate?
Anything hard to undo, until you have both a confidence threshold and an exclusion list. Host isolation, perimeter blocking and anything touching production or OT systems belong behind a human confirmation or very tightly bounded rules. Eradication and recovery stay human. The diagram above draws the line: automation is safe in inverse proportion to how hard the action is to undo.
Why do SOAR projects fail?
Because the platform is bought before the process exists. Automation does not create rigour, it multiplies whatever rigour is already present — so an undocumented, inconsistent process becomes a fast, consistent, automated version of the same confusion. Writing the runbook first is unglamorous and it is the actual work. The second cause is maintenance: playbooks rot as APIs change, and nobody notices until one fails during a real incident.
How many playbooks do we need?
Fewer than vendors imply. Three playbooks covering eighty per cent of your alert volume are worth far more than forty covering rare cases. The useful measure is what proportion of your real incidents a playbook touches, and how much analyst time each returns — not how many exist.
Does SOAR replace analysts?
No, and services sold on that basis disappoint. It removes the repetitive portion of their work — the lookups, the tab-switching, the copying between consoles — so the same people spend their time on judgement instead. The decisions that need a person are exactly the ones that were never automatable, and they are the reason you employ analysts.
Can SOAR work with the tools we already have?
That is the point of the orchestration half. What matters is integration depth rather than logo count: a connector that only reads data is not the same as one that can take action. Ask which specific actions are available for each of your tools before assuming a listed integration does what you need.
What happens if a playbook fails halfway?
Partial execution is the state that matters and it is the one rarely discussed. A half-contained incident — account disabled but session still live, host isolated but indicator not blocked — is worse than no automation because everyone assumes it completed. Failure detection, notification and a defined position on partial runs belong in the design.
Do we own the playbooks?
You should, and it is worth requiring in writing. Playbooks encode your process and your decisions, which is genuine institutional knowledge. If they exist only inside a rented platform, that knowledge leaves when the contract does.
How does this fit with your SOC service?
SOAR is how our analysts stop doing the repeatable parts by hand, not a product we hand you. In a managed engagement we build and maintain the playbooks, own the exceptions when they fire, and report what automation actually returned in analyst time — see managed SOC services.
Does SOAR help with compliance?
Genuinely, and in an underrated way. A playbook that assembles the timeline, the actions taken, the approvals and the artefacts as an incident progresses produces the evidence record during the event rather than reconstructing it weeks later. Reconstruction is what nobody has time for, so it quietly does not happen — which is exactly the gap an auditor finds.
How long before we see value?
The first playbook can be live in weeks if the process is already written down. If it is not, that discovery work comes first and is the more valuable half. Expect visible time savings from phishing and enrichment within the first month or two, and expect the harder containment playbooks to take longer because the thresholds and exclusions need agreeing with people who own the systems.
Next step
Tell us what your analysts do twice a day
Not your requirements — the repetitive thing. The lookup, the console they always have to open, the note they always retype. That is where automation returns time immediately, and it is a far better starting point than a platform evaluation. If the process is not written down yet, that is the first piece of work and we will say so.