TL;DR: Most SOAR platforms still behave like brittle macros, according to D3, while a 2024 Center for Threat-Informed Defense report found 82% of adversary behavior concentrates in 15 techniques. The real shift is from static workflow automation to attacker-sequenced response that is defensible, explainable, and adaptable.
At a glance
What this is: This analysis argues that traditional SOAR playbooks are too rigid for modern attack patterns and that response automation must follow adversary sequencing, not fixed if-then logic.
Why it matters: For SOC and GRC teams, the issue is not whether automation exists but whether it can explain, adapt, and withstand real attacker behaviour without creating governance blind spots.
By the numbers:
- A 2024 Center for Threat-Informed Defense report found that 82% of adversary behavior concentrates in 15 techniques.
Context
Security automation often fails when it treats incidents as linear ticket workflows instead of sequences of attacker behaviour. In practice, most SOAR environments still depend on static playbooks, manual context transfer, and brittle integrations, which makes them poor at following how adversaries chain techniques across tools and stages.
That governance gap matters because modern SOC work is increasingly about identity, process, and evidence as much as detection. When response logic cannot adapt to technique chaining, teams end up with automation that looks efficient on paper but still depends on human handoffs at the exact moment speed and defensibility matter most.
Key questions
Q: What breaks when SOAR playbooks are too broad?
A: Broad playbooks can disable legitimate users, block benign traffic, or create inconsistent incident handling when the trigger conditions are not well tested. The result is false containment, operational disruption, and loss of analyst trust in automation. Good playbooks stay narrow, measurable, and reversible.
Q: Why does attacker sequencing matter more than alert severity in SOAR?
A: Severity can tell you that something looks bad, but it cannot tell you whether several alerts belong to the same campaign. Sequencing matters because adversaries often use legitimate tools and common techniques in a deliberate order. If the SOC cannot follow that order, it will miss the real story and overvalue noise.
Q: What are the signs that SOAR automation is failing operationally?
A: The clearest signs are heavy manual upkeep, repeated handoffs between tools, shallow enrichment, and playbooks that need constant edits whenever attacker behaviour changes. If analysts still need to stitch together the case by hand, the platform is automating steps but not investigations.
Q: How should teams govern AI-driven response automation?
A: Teams should govern it like production software, with testable workflows, signed artifacts, policy gates, and rollback paths. They also need audit trails that show why each action was taken, not just what the system executed. Without that control layer, automation may be fast but cannot be trusted under scrutiny.
Technical breakdown
Why rigid SOAR playbooks break under attacker sequencing
Traditional SOAR playbooks are built as predefined branches: if this alert appears, run that script, notify that queue, then stop. That model works only when incidents are cleanly mapped to a known path. Real attacks rarely behave that way. Adversaries chain techniques, hide with living-off-the-land activity, and change order to avoid simple decision trees. When a playbook expects a single event and the attacker produces a sequence, the automation loses context and starts making local decisions without understanding the campaign.
Practical implication: Design response logic around attacker behaviour patterns, not isolated alert types.
How pattern-aware automation changes SOC investigation
Pattern-aware SOAR tries to correlate alerts into an evolving case, not a static workflow. That means mapping activity to adversary techniques, preserving case context across tools, and generating response steps that reflect the observed sequence rather than a prewritten script. The architectural shift is from task automation to investigation automation. In governance terms, that also improves traceability because the response can show why a branch was taken, what evidence supported it, and how the decision changed as new signals arrived.
Practical implication: Require response systems to retain investigative context and decision evidence across the full case lifecycle.
Why defensibility now matters as much as speed
Automation that cannot be explained becomes hard to trust, audit, or operationalise at scale. Security leaders need to justify why a response was taken, especially when the workflow can isolate systems, trigger containment, or escalate based on machine-generated logic. Defensibility therefore becomes a control property, not a reporting nicety. GitOps-style change control, signed artifacts, tests, and rollback paths turn response automation into something that can be governed like production software instead of improvised operations.
Practical implication: Treat response automation as governed code with testing, signing, and rollback controls.
Threat narrative
Attacker objective: The objective is to move through the environment while blending into legitimate administrative behaviour and avoiding static response logic long enough to achieve persistence or impact.
- Entry begins with common living-off-the-land activity that looks ordinary to brittle automation but fits an adversary’s chained sequence.
- Escalation occurs when attackers combine techniques such as scheduled tasks, scripting interpreters, and DLL hijacking to move beyond the first alert.
- Impact follows when the SOC responds to isolated events instead of the full pattern, allowing the campaign to progress faster than manual correlation can keep up.
Breaches seen in the wild
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Rigid SOAR is now a governance problem, not just an operations problem. When response logic is locked into static branches, the SOC can automate speed without automating judgement. That creates a control environment where the tooling may execute consistently but still fail to reflect how attackers actually move. The practitioner conclusion is clear: automation must be evaluated on adaptability and traceability, not just throughput.
Attack-pattern awareness is the missing concept in most response programmes. A SOC that maps activity to adversary technique sequences is governing behaviour, not just alerts. That matters because it reduces the chance that teams mistake alert volume for case understanding. The practitioner conclusion is to make sequence detection a first-class control objective, not a side effect of enrichment.
Defensible automation should be treated like production software. Signed artifacts, policy gates, testable workflows, and rollback paths are not implementation flourishes. They are the difference between a response action that can survive audit scrutiny and one that cannot be trusted when it matters. The practitioner conclusion is to bring change control into security response design from the start.
Living-off-the-land tradecraft exposes the limits of severity-based triage. When an adversary uses legitimate tools and common techniques, a platform that prioritises by alert score alone will often underread the campaign. That is why the control gap is not a lack of alerts but a lack of behavioural context. The practitioner conclusion is to align triage with technique chaining, not severity fields.
Attack-pattern-aware SOC design sharpens the boundary between automation and autonomy. Many teams call any workflow with AI assistance autonomous, but autonomy without defensibility is just opaque execution. The practical issue is whether the system can justify and govern each response decision. The practitioner conclusion is to demand explainable case generation before expanding machine-driven response scope.
What this signals
Attack-pattern-aware response is becoming the right unit of SOC design. Teams that still organise automation around alert severity are optimising for queue movement, not adversary containment. The better model is to connect enrichment, case building, and response to the attacker sequence the SOC is actually observing.
Defensibility now sits beside speed in the control hierarchy. Security teams cannot justify opaque response actions in regulated environments or when business operations are on the line. The practical implication is that every automated action should be explainable, reviewable, and reversible before it is allowed to scale.
SOAR programmes should be measured by investigative fidelity, not workflow count. A platform with hundreds of integrations can still be weak if it cannot tell a coherent attack story. Programme owners should therefore test whether the automation preserves context across tools and produces evidence that analysts can defend.
For practitioners
- Build response logic around attacker technique sequences Rework playbooks so they correlate chained behaviours such as scripting, scheduled tasks, and process masquerading rather than responding to each alert in isolation.
- Add evidence preservation to every automated decision Require each response branch to retain the triggering signals, mapped technique, and rationale so investigators can reconstruct why the system acted.
- Put change control around playbook generation Treat autogenerated response workflows as governed code with testing, policy gates, artifact signing, and rollback before production release.
- Reduce dependence on manual context passing Eliminate handoffs that force analysts to copy context between tools, and instead maintain a single case record that carries enrichment and sequence state.
Key takeaways
- Rigid SOAR playbooks struggle because they are built for fixed branches, while real adversaries chain techniques and change sequence to evade simple automation.
- The core evidence in the article is that 82% of adversary behaviour concentrates in 15 techniques, which makes attack-pattern awareness a practical SOC requirement.
- Defensible response automation needs preserved context, signed artifacts, policy gates, and rollback paths so response can be both fast and audit-ready.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0002; TA0006; TA0008 — Execution; Credential Access; Lateral Movement | The article centres on attacker technique chaining and response mapped to real adversary behaviour. |
| Recommendation — Map response logic to ATT&CK sequences and prioritise detection of chained techniques over isolated alerts. | ||
| NIST CSF 2.0 | DE.AE-02 — Anomalies and Events | Pattern-aware triage depends on correlating anomalous events into a coherent security case. |
| Recommendation — Correlate related events into cases so SOC automation follows behaviour patterns, not single alerts. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Defensible automation needs preserved artifacts and traceable decision records. |
| Recommendation — Preserve response artifacts and decision logs so automated actions remain auditable and reviewable. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | The article stresses traceable audit trails for automated response decisions. |
| Recommendation — Generate audit records for each automated response action and its triggering evidence. | ||
Key terms
- Attack-pattern-aware response: Security automation that groups alerts and actions around observed attacker behaviour rather than isolated events. It uses technique sequencing, context retention, and case generation to guide containment decisions and create response records that investigators can defend later.
- Defensible automation: Defensible automation is automated security action that can be explained, audited, and rolled back. It matters because operational speed alone is not enough if the organisation cannot prove why the system acted or recover cleanly when the action is wrong.
- Living Off The Land Technique: Living Off The Land Technique is an attack method where an adversary uses tools already present in a target environment instead of introducing obvious malware. It relies on legitimate system utilities, scripts, admin features, and trusted services to blend in with normal activity, making detection harder and forensic separation from routine operations more difficult.
- Playbook rigidity: The tendency of response workflows to depend on fixed if-then branches that break when incidents unfold in unfamiliar ways. Rigid playbooks create maintenance overhead and make automation less effective when attackers change order, use multiple tools, or suppress obvious signals.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org