Topic starter
02/08/2026 12:26 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by D3: “The Future of Defensible Security: From Reactive Playbooks to Attack-Pattern-Aware Autonomous Response”.
By the numbers:
- A 2024 Center for Threat-Informed Defense report found that 82% of adversary behavior concentrates in 15 techniques.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Rigid SOAR playbooks struggle because they are built for fixed branches, while real adversaries chain techniques and change sequence to evade simple automation.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:25 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Attack-pattern-aware SOAR is replacing rigid playbook automation