Keep deterministic, low-variance actions in SOAR when the trigger and the response are both stable, such as ticket creation or account disablement. Move investigative work with high branch variance toward dynamic reasoning, provided the system is grounded in real tool output and tightly constrained for action.
Why This Matters for Security Teams
SOAR works best when teams use it for repeatable decisions, not for every security task that feels automatable. The real question is whether a workflow has a stable trigger, a predictable set of inputs, and a bounded response that can be safely executed without human interpretation. That distinction matters because brittle automation can create silent failure, while under-automation leaves analysts buried in routine work.
Security teams often overestimate how consistent their processes really are. A ticket closure, user disablement, or enrichment lookup may look simple on paper, but exception handling, business context, and asset criticality can quickly change the correct response. A control framework such as the NIST Cybersecurity Framework 2.0 is useful here because it pushes teams to think in terms of governance, response consistency, and measurable control outcomes rather than tool-specific habits.
In practice, many security teams discover their SOAR boundary only after an automated action has been taken against the wrong account, wrong asset, or wrong alert class, rather than through intentional workflow design.
How It Works in Practice
A practical decision model starts by scoring each workflow against three questions: how stable is the trigger, how deterministic is the response, and how costly is a mistake. If all three are favorable, the workflow usually belongs in SOAR. If the trigger is ambiguous, the response depends on open-ended investigation, or the impact of a bad action is high, the workflow should stay human-led or move to a tightly constrained reasoning layer with explicit guardrails.
Deterministic SOAR candidates typically include alert triage steps, enrichment, account suspension, indicator blocking, and ticket routing. These actions work because they rely on known conditions and preapproved playbooks. By contrast, workflows that require contextual interpretation, cross-source hypothesis testing, or exception adjudication are better handled by analysts or by AI-assisted investigation that is grounded in live tool output and limited to read-only or approval-gated actions. For teams building governance around this boundary, guidance from the NIST Cybersecurity Framework 2.0 and the CISA resources and tools is useful for mapping repeatable response processes to measurable operational controls.
Useful operational filters include:
- Use SOAR when the playbook can be expressed as a finite decision tree.
- Keep humans in the loop when false positives require business context to resolve.
- Require approval gates for actions that affect identity, production availability, or regulated data.
- Log every automated step so analysts can reconstruct why the system acted.
- Retire workflows that need frequent manual overrides, because they are not truly stable enough for full automation.
This guidance breaks down in highly heterogeneous environments where asset identities, ownership metadata, and alert quality are inconsistent across cloud, endpoint, and SaaS systems.
Common Variations and Edge Cases
Tighter automation often increases operational risk, so organisations must balance speed against the cost of a mistaken response. That tradeoff is especially visible in identity actions, where account disablement may be safe for a commodity endpoint but disruptive for shared service access, privileged administrators, or break-glass accounts. For those cases, a constrained approval workflow is usually better than full automation.
There is no universal standard for exactly which workflows must stay in SOAR, and current guidance suggests that teams should classify workflows by repeatability rather than by team preference. A routine action can still be excluded from SOAR if the surrounding process is unstable, while a complex investigation may be partially automated if the system only performs collection and summarisation. The key is to separate decision support from decision execution.
Teams should also revisit the boundary as processes mature. A workflow that starts as analyst-led may become safe for SOAR after enough evidence accumulates, while an automated workflow may need to move back to human control if the exception rate rises or the threat landscape changes. For more on attack patterns and detection logic that often influence this boundary, see the MITRE ATT&CK knowledge base and the NIST AI Risk Management Framework when AI-assisted analysis is part of the workflow.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RS.RP-1 | SOAR workflow choice should align to repeatable response processes. |
| MITRE ATT&CK | T1078 | Identity-driven response workflows often hinge on valid account abuse patterns. |
| NIST AI RMF | AI-assisted investigation needs governance, accountability, and bounded action. | |
| OWASP Agentic AI Top 10 | Agentic tools can overstep if SOAR boundaries are not tightly controlled. | |
| CSA MAESTRO | Agentic security operations need orchestration controls and safe execution boundaries. |
Automate only response steps that can be rehearsed, measured, and consistently executed.
Related resources from NHI Mgmt Group
- How should security teams decide when to use copilots versus AI that owns IAM workflows?
- How should security teams decide whether JIT access is safe for non-human identities?
- How should security teams handle leaked secrets across developer workflows?
- How should security teams govern AI agent identities in MCP workflows?
