Summarize the Content of the Blog
Key takeaways
A SOAR use case is worth automating only if it clears three bars: it happens often, the steps are the same each time, and the steps are mechanical rather than decisions.
Enrichment use cases almost always rank first, because they are pure toil that happens constantly and require no judgment to automate.
Response use cases (block, quarantine, disable) come next, usually behind a human approval gate until trust is earned.
Splunk's own guidance is to send SOAR only events that need work done. The best use-case list is short and deliberate, not exhaustive.
How to rank a SOAR use case
Most SOAR advice hands you a list of use cases. That is the wrong starting point, because whether a use case is worth automating depends entirely on your environment, not on someone else's list. A phishing playbook is a strong win for a team drowning in phishing reports and pointless for a team that gets three a month.
So rank, do not list. Score each candidate on three axes.
Volume. How often does this happen? High volume means the time saved multiplies into something real. Low volume means it does not, no matter how clever the automation.
Repeatability. Are the steps the same every time? A task with consistent steps codifies cleanly into a playbook. A task that varies every time resists automation and produces brittle playbooks.
Judgment. Are the steps mechanical or decisions? Mechanical steps automate safely. Decision steps should stay with a human, at least until the pattern is well understood.
A use case that scores high on all three is a strong candidate. A use case that scores low on any one is usually not, and the axis it fails on tells you why. This scoring approach is the same one behind the buyer-level view in Splunk SOAR Services: Where Automation Delivers ROI.
The use cases that almost always pay off
These clear all three bars in most environments.
Alert enrichment. When an alert fires, a playbook gathers the context an analyst would otherwise collect by hand: reputation data on IPs and domains, asset and identity details, related recent activity, threat-intel matches. This is the highest-value SOAR use case in most SOCs, because it happens on every alert, the steps are identical, and none of it is a decision. The analyst opens an already-enriched case instead of starting from a bare alert.
Phishing triage. User-reported phishing is high-volume and highly repeatable: extract the email, check sender and links, detonate attachments safely, search for other recipients. The decision, is this malicious and what do we do, stays human, but everything before it automates cleanly.
Indicator lookups. Checking an indicator against threat intelligence and internal history is pure mechanical repetition, and it happens constantly across investigations.
Case creation and population. Automatically creating a case, attaching the relevant artifacts, and applying the right workbook template turns the administrative overhead of starting an investigation into zero clicks. Splunk SOAR's case management uses workbooks to codify processes into reusable templates, which is what makes this consistent rather than ad-hoc.
The build detail for the response-oriented patterns, phishing, malware, suspicious login, threat-intel correlation, and IT handoff, is documented step by step in Splunk SOAR Playbook Patterns That Cut MTTR.
The use cases to approach carefully
These can pay off, but they carry a decision, so they need a human in the loop at first.
Containment actions. Blocking an IP, quarantining a host, disabling an account. These are high-value because they shrink the attacker's window, but they can also disrupt the business if triggered on a false positive. The standard pattern is to automate the preparation and gate the action behind an analyst approval, then remove the gate for narrow, well-understood cases once trust is established.
Automated remediation. Clearing a threat, killing a process, rolling back a change. Powerful and unforgiving. Introduce these for specific, well-defined scenarios with clear rollback, not broadly.
The principle: automate the work up to the decision freely, and gate the decision itself until the pattern has proven safe. This is how mature SOAR programmes expand automation without accumulating risk.
The use cases to leave to analysts
Some work should not be automated, and recognizing it prevents wasted effort.
Rare events. A playbook for something that happens twice a year costs more to build and maintain than it will ever save. Leave it manual and document a runbook instead.
Novel or ambiguous situations. If the right response depends on context that changes each time, there is no stable process to codify. Automation of the ambiguous produces automation nobody trusts.
High-stakes judgment. Deciding whether to declare a major incident, whether to notify regulators, whether to take a critical system offline. These are decisions with consequences that demand human accountability, and Splunk's own guidance is clear that SOAR does not replace experienced analysts.
The discipline of knowing what not to automate is what separates a SOAR programme that builds trust from one that overreaches and gets switched off.
How to build your own shortlist
A practical exercise you can run in an afternoon.
List the tasks your analysts do most often. For each, mark volume (high or low), repeatability (consistent or variable), and judgment (mechanical or decision). Sort by the ones that are high-volume, consistent, and mechanical. That sorted list is your SOAR roadmap, and it will almost certainly start with enrichment.
Build the top item first, measure the analyst time it returns, and use that result to justify the next. This sequenced, evidence-led approach is what keeps a SOAR programme funded and trusted, rather than stalling after an over-ambitious first playbook.
bitsIO, a four-time Splunk Partner of the Year and Splunk Elite Partner, runs exactly this scoring exercise at the start of a SOAR engagement through its Splunk SOAR practice, and connects it to detection quality upstream in Splunk Enterprise Security.
