Notifications
Clear all
Topic starter
02/08/2026 11:55 am
TL;DR: SOAR deployments typically cover only 30% to 40% of alerts, while 40% of alerts are never investigated and implementations can take 12 to 18 months to show meaningful ROI, according to Torq. Static playbooks and custom scripting are now the limiting factor, not the lack of automation ambition.
NHIMG editorial — based on content published by torq: AI SOC exposes why static SOAR playbooks no longer scale
By the numbers:
- Most SOAR deployments cover 30–40% of alerts.
- Legacy SOAR implementations take 12–18 months before showing meaningful ROI.
Questions worth separating out
Q: What breaks when static SOAR playbooks are asked to handle novel alerts?
A: Static playbooks break when an alert does not match the expected condition, the integration output changes, or the response path needs context the script never anticipated.
Q: Why do rigid automation models struggle with identity-led incidents?
A: Identity-led incidents require context about behaviour, privilege, and session legitimacy, not just a matching indicator.
Q: How do security and compliance teams know if SOC 2 automation is working?
A: SOC 2 automation is working when it keeps evidence current, control ownership visible, and audit requests organised without replacing testing.
Practitioner guidance
- Define the alert classes that still need human judgment Separate high-impact identity, containment, and remediation actions from low-risk enrichment tasks.
- Measure automation by coverage, not by playbook count Track the percentage of alerts investigated end to end, the number of cases that stall in queues, and the time required to operationalise a new use case.
- Audit playbooks for brittleness at integration boundaries Review workflows that fail when APIs change, data fields shift, or a threat deviates from the expected path.
What's in the full article
Torq's full article covers the operational detail this post intentionally leaves for the source:
- The platform comparison table that breaks out alert coverage, maintenance burden, time-to-value, and human-in-the-loop design.
- Customer migration examples showing how teams moved from legacy SOAR to AI SOC in days or weeks.
- The implementation and ROI claims behind live customer deployments, including operational timelines and analyst-hours saved.
- The FAQ section that explains how the vendor positions AI SOC as a replacement for playbook-heavy workflows.
👉 Read Torq's analysis of SOAR limits and AI SOC operations →
AI SOC vs SOAR: where does security automation break down?
Explore further
02/08/2026 1:03 pm
Static-playbook automation has become a governance ceiling, not just a tooling limit. When a SOC can only automate what has already been scripted, coverage stops expanding as soon as new attack patterns appear. That leaves analysts to absorb the tail of unknown, multi-stage, and identity-led incidents manually. The issue is structural, and it is why modern SOC design now needs to be judged by coverage, adaptability, and auditability together.
A question worth separating out:
Q: Which controls matter most when AI agents can take response actions?
A: The key controls are graduated autonomy, full audit logging, and policy-backed approval gates for higher-impact actions. Teams should also separate read access from write authority so agents can analyse broadly without being able to change protections or trigger irreversible remediation on their own.
👉 Read our full editorial: AI SOC exposes why static SOAR playbooks no longer scale
