SOAR is Automation Without Authority — The Paradox of Orchestrated Incident Response

The promise of SOAR—security orchestration, automation, and response—rests on a foundational contradiction: you cannot automate a decision you do not have the authority to execute, nor can you orchestrate systems whose behaviour you do not fundamentally control.

The Industry Narrative: SOAR as the Automation Panacea

The market for security orchestration and automation platforms has grown steadily since Gartner's 2015 SOAR quadrant first codified the category. Tools like Splunk Phantom (now Splunk SOAR), Palo Alto Networks Cortex XSOAR, Demisto (acquired by CrowdStrike), and Rapid7 InsightConnect promised to dissolve the productivity crisis in security operations centres—to reduce dwell time, eliminate alert fatigue, and enable analysts to focus on high-value reasoning whilst machines handled the mechanical work of containment and forensics.

The technical vision was coherent: ingest alerts from multiple detection layers (SIEM, EDR, firewalls, DNS filtering, DLP); normalise those signals into a common event format; apply pre-built or custom playbooks that automatically perform actions like isolating hosts, disabling accounts, blocking IPs, collecting artefacts, and escalating to human analysts when judgment was required. Vendors published impressive case studies: X per cent reduction in mean time to respond (MTTR), Y per cent fewer false positives handled manually, Z per cent of incidents closed without human touch.

Real-world deployments, however, revealed the structural weakness. The Change Healthcare ransomware incident (January 2024), attributed to a variant of the BlackCat/ALPHV ransomware family, exposed the fact that even sophisticated healthcare organisations with layered detection stacks could not respond at the speed SOAR promised. The attacker exploited a critical vulnerability (CVE-2024-24919, in their MOVEit Transfer instance) and achieved domain compromise within days—far faster than playbooks could be validated, tested, and executed without human authority. The $22 million settlement, plus ongoing regulatory scrutiny from HHS, underscored that orchestration alone cannot outpace adversary speed when each automated step still requires implicit human trust in the underlying decision logic.

Similarly, the Snowflake tenant cascade of 2024—where compromised credentials across multiple Snowflake customers led to data exfiltration affecting Ticketmaster, LendingClub, and others—demonstrated that even environment-specific credential isolation, a textbook SOAR use case, cannot contain lateral movement once the authentication boundary has been compromised. Automated playbooks that relied on querying Snowflake API endpoints for isolation became part of the attack surface itself. The incident revealed that orchestration assumes a stable, trustworthy control plane; it offers no defence when the very systems being orchestrated have been subverted.

The Structural Paradox: Automation Without Authority

SOAR's fundamental limitation is architectural, not operational. A SOAR platform sits between detection (where alerts originate) and action (where remediation happens), but it inherits the worst properties of both:

From detection, it inherits signal debt. SIEM tuning, EDR telemetry ingestion, and log normalisation are expensive, noisy, and never complete. A playbook built to respond to a Sigma rule (e.g., SIGMA ID 53ba33fd-8a77-4d3a-ba97-4d46a9dd1fe2, detecting parent-child process anomalies) is only as good as the rule itself. If the SIEM fails to detect the attack pattern—or worse, detects it hours after compromise—SOAR automation becomes a formality applied to stale data. The MGM Resorts and Caesars Entertainment breaches (September 2023), attributed to initial access via social engineering and MFA bypass, went undetected for weeks despite EDR and SIEM infrastructure. Neither SOAR orchestration of credential revocation nor playbook-driven isolation matters when the dwell time is measured in days and the control plane has already been compromised.

From action, it inherits authority opacity. A playbook that automatically disables a user account, isolates a host, or blocks a domain must rely on the legitimacy of the downstream system—the Active Directory instance, the EDR agent, the firewall API—being uncompromised. Yet SOAR provides no cryptographic proof that the action was executed as intended, no zero-knowledge assertion that the target system actually complied, and no persistent record that cannot be tampered with post-breach. During the Medibank breach (October 2022), attackers with valid credentials could have triggered false-positive SOAR responses that actually accelerated their lateral movement by forcing isolation of monitored hosts, creating blind spots in telemetry. The playbook had no way to distinguish between a legitimate analyst action and an attacker triggering the same API call.

The deeper issue: SOAR orchestrates at the control plane, not the data plane. It tells systems what to do, but it cannot verify what they actually do, nor can it prevent a compromised downstream system from lying about compliance. An EDR agent told to isolate a host can report success whilst covertly exfiltrating data. A firewall API told to block a subnet can appear to comply whilst maintaining a hidden route via a secondary interface. SOAR has no substrate-level veto over the outcome.

Why Reactive Automation Deepens the Trap

The industry response to SOAR's limitations has been to improve playbooks, add more integrations, and invest in orchestration logic—doubling down on the very architectural pattern that created the problem.

Vendors now promote "intelligent SOAR" features: machine learning to prioritise alerts, predictive playbook suggestions, and cross-platform correlation. But intelligence applied to a fundamentally reactive architecture is merely faster reaction to stale signals. The NIST Cybersecurity Framework (CSF) formalises this as the Respond and Recover functions, but even NIST acknowledges that Respond must be preceded by Detect—and detection, in every production environment, is inherently lagging. A playbook that executes in 30 seconds against an alert generated 2 hours after the adversary's initial action has not improved the outcome; it has only reduced the variance in how slowly the organisation loses control.

NIS2 compliance obligations (Directive (EU) 2022/2555, now binding on essential service operators across the EU and critical infrastructure owners) mandate incident response capability, including rapid isolation and notification requirements. Many organisations interpret this as "deploy SOAR and tune SLAs"; in fact, NIS2 Article 20(5) requires operators to implement measures for continuity and resilience during incidents, not after detection. SOAR's orchestration of post-breach response is orthogonal to this requirement. A SOAR playbook that locks down a compromised domain controller does nothing to preserve the integrity of a zero-knowledge backup that was never exposed to the control plane in the first place.

The PULSE Principle: Post-Breach Resistance via Architecture

The PULSE doctrine inverts the problem: instead of automating response to compromised systems, eliminate the architectural surfaces where compromise propagates.

Zero-knowledge substrate. Data and cryptographic material should not exist in the control plane—not in SIEM databases, not in EDR telemetry stores, not in SOAR orchestration logs. Instead, each operational domain (payment processing, customer data, healthcare records) should maintain a mathematically isolated substrate where the only information available to centralized monitoring is whether a specific, pre-defined invariant holds (e.g., "all account balance changes were signed by the correct private key" or "all data access was logged to an immutable, off-path sink"). The SOAR equivalent is not orchestration; it is cryptographic assertion. When an invariant is violated, the system does not try to respond; it automatically reverts to a known-good state, defined entirely within the substrate itself.

Data-plane veto over control-plane instruction. An isolated domain should execute a SOAR playbook (or any external instruction) only if the instruction passes a local verification gate—e.g., the signature is valid, the timestamp is recent, and the instruction does not contradict a prior, still-valid constraint. The Snowflake incident would have been contained if the data-plane (the Snowflake instance) had refused any query that attempted to export customer data outside a pre-authorised channel, regardless of the credential validity or the SOAR playbook's orchestration.

Continuous adversarial posture drift. Rather than deploying a static playbook (the SOAR model), deploy a continuously shifting set of domain-specific primitives that change their behaviour in response to threat signals, without requiring human authorisation or SOAR orchestration. If EDR detects a known ransomware behaviour, the file system does not wait for a playbook to complete; it automatically shifts to read-only mode for all non-privileged processes, enforced at the kernel level. If DNS exfiltration patterns are detected, the DNS resolver does not queue an alert; it atomically splits the network into isolated query domains, each with its own TTL and response cache. These are not SOAR actions; they are domain-specific primitives, baked into the substrate.

Legibility and auditability without trusted intermediaries. Every state change within the substrate—every isolation, every credential revocation, every data access—is logged to a cryptographically signed, append-only ledger that is external to the substrate itself. This ledger cannot be tampered with post-breach because it is not stored in the SIEM, the SOAR platform, or the compromised domain. It is verified independently by signatories external to the attack surface. When a regulator (HHS, ICO, FCA under SM&CR, SEC under the 4-day rule, or APRA under CPS 234) demands proof that a specific containment action occurred, the organisation produces a signed ledger entry that the adversary could not have forged.

What Operators Must Demand from New Infrastructure

The question for infrastructure architects is not "which SOAR platform should we deploy?" but rather: "What properties must our infrastructure guarantee before any incident response becomes necessary?"

A post-breach-resistant architecture satisfies these properties:

1. No single control plane can compromise all data planes. Compromise of a SIEM, SOAR platform, or centralised EDR console does not grant an attacker write access to any operational domain.

1. Playbooks execute under cryptographic constraint. Any automated action (account disablement, host isolation, data export) is verified against a substrate-local policy before execution. The policy is not stored in SOAR; it is stored in the domain where the action takes effect.

1. Dwell time is immaterial. If an attacker remains undetected for 30 days, the impact is bounded by the fact that the attack surface—the amount of data or capability they could have accessed—is cryptographically limited by the substrate design. SOAR's MTTR becomes a secondary concern.

1. Incident response does not rely on systems you do not control. If containment requires quarantining a database, the database itself—not the SOAR platform—must have the authority and the technical capacity to refuse queries that violate the quarantine.

This is not a call to eliminate SOAR wholesale; it is a recognition that SOAR is a tool for orchestrating responses to detected incidents, not a tool for preventing breaches from propagating. Organisations that have deployed SOAR without addressing the substrate architecture are automating the mechanics of surrender.

Regulator Signals and the Coming Reset

Regulators are beginning to signal dissatisfaction with detection-and-response as the primary control. FCA Senior Manager Certification Regime (SM&CR) and DORA (Digital Operational Resilience Act) requirements demand that critical systems remain operational during an attack, not just recover afterwards. APRA CPS 234 (prudential standard for information security) explicitly requires "resilience" and "recovery", not just "response". NIS2's mandatory incident notification timeline (72 hours to national authorities) implicitly assumes that containment happens faster than that, or that the infrastructure is designed to limit blast radius without requiring SOAR orchestration.

The Change Healthcare incident cost $22 million in settlements plus ongoing regulatory fines under HIPAA Breach Notification Rule. The Snowflake cascade triggered state-level investigations and data subject notifications across three continents. These costs are not proportional to the sensitivity of the data breached alone; they are proportional to the lack of resilience demonstrated during the breach. SOAR's reduction in MTTR from 6 hours to 2 hours is irrelevant when regulators expect containment to be automatic, built into the infrastructure itself.

Closing the Feedback Loop

The path forward requires operators to reject the false dichotomy of "detection-and-response" versus "do nothing". The third option—architecture that resists post-breach propagation before any response mechanism engages—is not theoretical. It requires rethinking how data is stored, how credentials are issued, how access decisions are made, and how state changes are certified. SOAR has no role in that redesign, except as a tool for orchestrating the mundane tasks of a fully contained incident.

Qualified operators seeking to understand how post-breach-resistant architecture differs from orchestration-dependent models should request a technical briefing under NDA.