“Decision support” comes up in almost every SOAR demonstration. A recommended action appears on screen, a risk score sits beside it, and the presenter calls it decision support. Yet buyers, analysts, and vendors rarely mean the same thing by the term.
That gap matters. If a team cannot define decision support, it cannot test it, compare it, or hold it to a standard.
In this NewEvol guide, we set out a practical definition, separate decision support from automation, and describe what a decision support system SOAR teams can trust should actually provide. It is written as a reference point for SOC analysts, security managers, and CISOs evaluating security orchestration and automation.
What Is Decision Support in SOAR?
In a SOAR environment, decision support is the layer that helps an analyst understand an incident and choose a response before any action is taken. It gathers relevant evidence, relates it to past incidents, suggests a next step, explains why, and states how confident it is.
Its output is not an action. Its output is a better-informed analyst.
A simple test: if a capability changes what the analyst knows, it is decision support. If it changes the state of a system, such as blocking an IP address or disabling an account, it is automation.
Automation vs. Decision Support: Executing vs. Informing
The clearest way to separate the two is this:
Automation executes a decision that has already been made. Decision support informs a decision that a person is about to make.
A playbook that isolates an endpoint when a confirmed ransomware indicator appears is automation. Someone decided in advance that this condition warrants this action, and the playbook carries it out quickly and consistently.
Decision support works earlier, in situations where the right response is not yet clear: the evidence is mixed, the asset is business-critical, or the pattern is unfamiliar. Here, SOAR decision support helps the analyst reach a decision that automation can then execute. One answers “What should we do?” The other answers “How do we do it reliably?”
What a Decision-Support Layer Actually Provides
A useful decision-support layer makes four contributions. Each should be visible to the analyst, not hidden inside a single score.
1. Assembled context
Without support, gathering context means searching across the SIEM, identity provider, endpoint console, firewall logs, and threat intelligence feeds. Decision support brings that incident context together in one view:
- the triggering alert and related alerts
- identity data, such as user role, privileges, and recent sign-ins
- endpoint and network activity around the event
- threat intelligence matches
- notes and outcomes from previous investigations
The key word is relevant. More data is not better context. A good layer selects what bears on this incident and shows where each item came from.
2. Similar incident history
Incident history gives analysts reference points. If three similar alerts on the same server turned out to be a scheduled backup job, that is useful. If a similar pattern last quarter was credential theft, that is useful too.
History is supporting evidence, not proof. Two incidents can look alike and still need different responses because the user, asset, or timing has changed. The system should show what made them similar and how each was resolved, then leave the comparison to the analyst.
3. Recommended action with reasoning
Decision support can suggest a next step: investigate further, collect more evidence, escalate the incident, or isolate an endpoint.
A recommendation without reasoning is just an action button. Analysts need to see why it was generated: which evidence supports it, which rule or model produced it, and what would change it. That lets them accept, adjust, or reject it, and lets reviewers understand the decision later.
4. Stated confidence level
Confidence tells the analyst how much weight a recommendation deserves. It helps separate strong, consistent evidence from a thin or conflicting picture.
Confidence is not certainty. A high-confidence recommendation can still be wrong. What matters is that uncertainty stays visible. When evidence is weak or contradictory, the system should say so plainly rather than present a confident-looking answer.
Why Analyst Accountability Is a Design Requirement
Keeping the analyst accountable is not a limitation of decision support. It is a requirement.
Security decisions often depend on factors a system cannot fully see:
- business impact, such as isolating a server during a payment run
- incomplete or conflicting evidence
- unusual but legitimate activity, such as an executive traveling abroad
- regulatory and contractual obligations
- organizational context, such as a change window or an acquisition
The flow should look like this:
Data → Context → Recommendation → Analyst Decision → Action
Decision support covers the first three steps. The analyst owns the decision. Automation typically operates after that point, executing what the analyst approved or what the organization defined in advance. The aim is to strengthen analyst decision-making, not replace it.
What Decision Support Should Never Do Silently
Some behaviors are acceptable only when the analyst can see them. A decision-support layer should never silently:
- change an incident’s severity without explaining why
- execute a containment action without authorization
- suppress or close an alert without a visible reason
- modify response workflows without informing the analyst
- hide evidence that contradicts its recommendation
- present an uncertain recommendation as a certain conclusion
- treat historical similarity as definitive proof
- make a material security decision without a human approval point
The common thread is transparency. Every recommendation, change, and action should be traceable: what proposed it, on what evidence, and who approved it. That traceability supports post-incident review, audits, and the trust analysts need before they rely on any recommendation.
Practical SOC Examples
The three scenarios below show where decision support ends and automation begins. In each one, the system informs the decision and automation executes it only after approval.
|
Suspicious login |
Malware alert |
Potential account compromise |
|
|---|---|---|---|
|
What the system knows |
Sign-in from a new country on an unrecognized device; MFA passed; user normally signs in from one office |
Endpoint tool flags a file on a finance workstation; hash matches a known malware family; four similar past incidents |
New mailbox rule forwards mail externally, created after an unusual sign-in; user has payment system access |
|
What it recommends |
Investigate further before any account action |
Isolate the endpoint and collect forensic evidence |
Escalate, temporarily restrict access, and collect mailbox audit logs |
|
Why |
New location and device are risk signals, but passed MFA and no follow-on activity weaken the case for compromise |
File hash match, plus three of the four similar past incidents were confirmed malicious |
Forwarding rules after suspicious sign-ins match common takeover patterns; privileged access raises impact |
|
Confidence |
Moderate: evidence is mixed |
High: the one past false positive (a testing tool) is shown alongside |
Moderate to high: no confirmed data loss yet |
|
What the analyst decides |
Contacts the user, confirms business travel, closes with a note |
Approves isolation after confirming no critical process runs on the device |
Escalates and approves the restriction; asks for more logs before a password reset |
|
What automation executes after approval |
Records the outcome and updates the user’s known locations |
Isolates the device, collects artifacts, opens a ticket |
Removes the forwarding rule, revokes active sessions, gathers logs |
Why Security Analysts Need Decision Support
SOC teams work under pressures that make good decisions harder:
- Alert volume: more alerts than analysts can investigate in depth
- Fragmented data: evidence spread across many consoles
- Investigation time: time spent finding facts instead of weighing them
- Inconsistent decisions: two analysts handling the same alert differently
- High-severity pressure: critical incidents leave little time to think
- Missing history: past investigations buried in closed tickets
- Junior analysts: need structured guidance while they build experience
- Experienced analysts: need faster access to the evidence that matters
Speed is a benefit, but it is not the main goal. The larger goal is decisions that are better, more consistent, and easier to explain to a manager, an auditor, or a regulator.
Decision Support vs. Automated Response
|
Area |
Decision Support |
Automation |
|---|---|---|
|
Primary purpose |
Helps inform a decision |
Executes a defined action |
|
Human role |
Analyst evaluates and decides |
Analyst may approve, or define the rule beforehand |
|
Context |
Provides relevant evidence and reasoning |
Uses predefined or triggered conditions |
|
Recommendation |
Yes |
Not necessarily |
|
Confidence |
Can communicate uncertainty |
Usually executes according to configured logic |
|
Accountability |
Analyst remains responsible for the decision |
Responsibility depends on workflow design |
Neither approach is inherently safer. Well-designed automated response is the right choice for repeatable, well-understood actions. Decision support is the right choice when judgment is needed. Mature security operations use both, with a clear handoff between them.
Where Decision Support Fits in the SOAR Process
Detection → Investigation → Decision Support → Analyst Decision → Orchestration/Automation → Response → Review
Decision support is the bridge between threat investigation and automated response. It turns investigation findings into a clear, explained choice, and the analyst’s decision then triggers orchestration.
This matters for buyers. SOAR is often described only as a way to run playbooks. A mature security operations setup also helps analysts decide which playbook fits before anything runs. The review stage then adds each outcome to incident history, giving future recommendations better reference points.
What Good Decision Support Looks Like
Use these principles as a checklist when you evaluate any decision support system SOAR vendors demonstrate:
- Context before recommendation: the analyst sees the evidence first
- Evidence before conclusion: every conclusion points to its sources
- Reasoning alongside recommendations: no unexplained action buttons
- Confidence instead of false certainty: weak evidence is labeled as weak
- Human approval for consequential decisions: containment and closure need a named approver
- Full visibility: the analyst can see everything the system recommended or changed
- Traceability: decisions and actions can be reconstructed after the incident
- Separation of recommendation and execution: suggesting an action never triggers it by default
If a demo cannot show where a recommendation came from, treat it as automation with a friendlier label.
Key Takeaways
- Decision support informs a decision; automation executes one.
- Its four core contributions are assembled context, similar incident history, a recommendation with reasoning, and a stated confidence level.
- Analyst accountability is a deliberate design requirement, not a gap to be engineered away.
- Nothing consequential should happen silently: severity changes, closures, and containment all need visible reasons.
- Decision support and automation work best together, with a clear handoff at the analyst’s decision.
Final Thought
Decision support is the layer between security evidence and responsible action. It does not decide for the analyst. It makes sure that when the analyst decides, the context, history, reasoning, and uncertainty are all in plain view.
Frequently Asked Questions
1. What is decision support in SOAR?
It is the capability that helps an analyst evaluate an incident and choose a response. It does this by assembling evidence, referencing similar incidents, recommending a next step with reasoning, and stating confidence. It informs action rather than taking it.
2. How is decision support different from automation?
Automation carries out a choice that was already made, either by a person or by a predefined rule. Decision support helps a person make that choice. Many workflows use decision support first and automation second.
3. Why do SOC analysts need decision support?
It cuts the time spent collecting evidence across tools and gives every analyst the same starting point. That leads to more consistent decisions, especially during high-pressure incidents.
4. What information should SOAR decision support provide?
At minimum: relevant incident context with sources, similar past incidents and how they ended, a recommended action, the reasoning behind it, and a confidence level. Contradictory evidence should be shown as well.
5. Should decision-support systems automatically execute security actions?
Not on their own authority for consequential actions. An organization can choose to pre-approve low-risk, well-understood actions as automation, but that should be a documented policy decision that can be reviewed.
6. Why is confidence important in security recommendations?
It tells analysts how far to rely on a recommendation and when to dig deeper. Without it, a weak suggestion and a well-supported one look identical.
7. Can decision support and automated response work together?
Yes. Decision support helps the analyst decide, and automation then executes approved steps quickly and consistently. Outcomes from both feed back into incident history for future investigations.
