Domain-Specific Automation — Why Generic SOC Playbooks Fail Sovereign Counterparties

The Playbook Trap

Generic incident response automation—the kind that lives in SOAR platforms, Splunk playbooks, and off-the-shelf orchestration templates—has become the structural guarantee that breaches will not be contained, and that when they are discovered, the defender's response window will be consumed by false positives and domain-irrelevant procedure.

The problem is not that automation is weak. It is that automation decoupled from the specific operational and data-flow reality of the organisation it defends is a tax on incident velocity. A National Infrastructure operator running SWIFT messaging does not benefit from the same detection-to-response chain as a SaaS platform processing user-generated content. A custodian holding securities settlement data does not need the incident response playbook of a retail bank. Yet the industry's standard remediation—purchase a SOAR, feed it your logs, template a response workflow—treats automation as a universal good, available off-the-shelf, pluggable into any environment. This assumption is not just inefficient. It is architecturally incoherent.

The Snowflake tenant cascade of late 2023, the Change Healthcare ransomware attack of early 2024, and the ongoing cascade of supply-chain compromises through SolarWinds, MOVEit, and similar software-as-root-cause incidents have all exposed a common failure mode: defender organisations had detection and alerting infrastructure in place, but lacked the automation substrate to act decisively within the blast radius and time constants of their specific adversary model and asset topology. When the responder must map a generic playbook onto a bespoke environment under pressure, the playbook becomes a liability.

PULSE's doctrine reverses this hierarchy. Automation is not bolted onto observation. Instead, automation is engineered into the data substrate itself—the flow of transactions, messages, cryptographic state, and access decisions that define the organisation's operational reality. This demands a redesign of how domain-specific processes (settlement clearing, securities custody, messaging authority, regulatory reporting) interact with security primitives. It is not a SOAR. It is a different architecture entirely.

The Industry Narrative: SOARs, Playbooks, and the Illusion of Closure

The canonical industry response to incident response latency is well-rehearsed. In 2020, following the SolarWinds Orion compromise—which exposed thousands of organisations to supply-chain reconnaissance and lateral movement—security leaders and vendors coalesced around the SOAR (Security Orchestration, Automation, and Response) category as the remedy. Platforms like Palo Alto Networks' Cortex XSOAR, Splunk Phantom (now Splunk SOAR), ServiceNow Security Operations, and Fortinet FortiSOAR promised to stitch together alert streams from multiple sources (SIEM, EDR, threat intelligence feeds), apply rule engines, and execute remediation playbooks without human intervention.

The logic is sound on its surface: if a known malware hash is detected on an endpoint, immediately isolate the device, kill the process, restore from backup, and notify relevant stakeholders. If a user logs in from an anomalous geography, revoke active sessions, force password reset, and escalate. If a database query pattern matches a known exfiltration technique (MITRE ATT&CK T1040, Exfiltration Over Network), block the session and log it.

By 2024, after the Medibank data breach (2022, involving inadequate segmentation and detection), the Optus credential theft (2022, APIs exposed without authentication), the LastPass vault compromise (2022, backup encryption key theft from developer machine), and the Latitude Financial breach (2023, exploitation of poorly-managed API gateways), most large financial services, healthcare, and critical infrastructure organisations had deployed some form of SOAR orchestration. Regulators—the FCA (Senior Managers and Certification Regime, SM&CR), the PRA (Prudential Regulation Authority), APRA (Australian Prudential Regulation Authority, CPS 234), MAS (Monetary Authority of Singapore, TRM framework), and increasingly the NIS2 Directive in Europe—began mandating detection and response capabilities as a baseline control, often implicitly endorsing the SOAR-plus-SIEM-plus-EDR stack as the standard architecture.

Yet between 2023 and early 2025, several high-impact incidents occurred despite the presence of these systems. The Snowflake tenant cascade (late 2023) involved credential harvesting and data exfiltration across multiple customer tenants; whilst many organisations had EDR and SIEM in place, the shared-tenancy model and the fact that the attack occurred at the authentication layer (before normal YARA / Sigma signatures could trigger) meant that generic playbooks could not differentiate between legitimate Snowflake customer activity and attacker reconnaissance. The Change Healthcare attack (early 2024) exploited a VPN endpoint; the organisation had standard EDR and intrusion detection, but the playbook response (isolate the device, kill the connection) was not specific to the fact that Change Healthcare is an intermediary in the US healthcare clearinghouse ecosystem—isolating the VPN meant halting prescription routing and claims processing for thousands of downstream pharmacies and providers. The responder had to choose between following the generic playbook (and causing operational failure) or not following it (and hoping the attacker did not escalate).

The pattern is consistent: the SOAR executes; the playbook runs; but the playbook is not tuned to the specific adversary model, data classification, and operational coupling that defines the organisation in question.

The Structural Failure: Automation Without Substrate Awareness

Generic playbooks fail because they are written for a generic organisation—an abstract entity with "users", "endpoints", "databases", and "networks"—rather than for a specific operational context defined by domain, asset topology, data residency, regulatory mandate, and threat model.

Consider a securities clearinghouse. A real-time settlement system processes thousands of transactions per second. Each transaction involves cryptographic verification, state mutation in a central ledger, and regulatory reporting. A SOAR playbook that says "if a database query looks suspicious, isolate the database" is not responding to the clearinghouse's actual threat model. The clearinghouse does not fear endpoint compromise of a trader's workstation (that is a concern, but not the primary one). It fears compromise of the settlement authority itself—specifically, the ability to either commit fraudulent transactions or to prevent legitimate ones from committing. A generic playbook has no way to distinguish between a query that is anomalous in the context of the settlement ledger and one that is simply anomalous in the aggregate. It will trigger alerts that do not correspond to actual operational risk, or it will fail to trigger alerts when the risk is real but masked by volume or legitimacy patterns.

Contrast this with a financial messaging counterparty running a SWIFT interface or a similar critical infrastructure node. Here, the threat model is different: compromise of the messaging endpoint, injection of false messages, or man-in-the-middle interception of cryptographic key material. A generic playbook that responds to "anomalous outbound traffic" by blocking the connection will again create an operational failure case. The playbook does not know that this particular outbound traffic is a legitimate SWIFT message refresh cycle, or that blocking it will cause downstream counterparties to time out and assume the institution is non-responsive.

The deeper problem is that generic SOAR platforms are designed to be control-plane tools. They sit above the operational infrastructure, observe events, and issue commands (kill process, disable account, block traffic). They are not embedded in the data plane. They cannot enforce policy at the layer where data and transactions actually flow. They observe and react; they cannot prevent.

This is the architectural ceiling that PULSE's doctrine identifies. Detection-and-response, however well-orchestrated, is inherently late. By the time a SOAR has assembled evidence, applied rules, and executed a playbook, the attacker has already moved. In the Change Healthcare incident, the playbook may have been triggered hours after initial lateral movement. In the Snowflake cascade, detection took days. In SolarWinds, weeks.

Post-breach resistance via architecture, not detection-and-response, means shifting the automation from the control plane (where it can only react) to the data plane (where it can enforce). This requires that the automation be domain-specific because each domain's data plane is different.

Domain-Specific Automation: Architecture, Not Orchestration

PULSE's approach to automation inverts the SOAR paradigm. Instead of a centralised orchestration engine that observes many domains through a common abstraction (alerts, events, tickets), the organisation designs automation directly into the operational substrate.

For a securities settlement system, this means embedding automated state-validation and transaction-reversal logic at the ledger layer itself. Before a transaction commits, the system executes a domain-specific verification that checks not just cryptographic correctness (which is standard) but also operational coherence: does this transaction fit the pattern of legitimate settlement activity given the current network state, the identities of the counterparties, and the regulatory constraints on this particular pair? If the answer is no, the transaction is held and flagged for human review, but the hold is enforced in the data plane—the transaction cannot proceed without explicit human override using a separate, out-of-band authentication channel. This is not a playbook. It is an invariant embedded in the system design.

For a SWIFT or similar critical messaging node, domain-specific automation means implementing a policy engine that is tightly coupled to the message-signing and routing logic. Before a message is routed to the network, the system checks not just that the signature is valid but that the message's logical intent (payment amount, destination bank code, currency) fits the organisation's established counterparty relationships. If a message attempts to route funds to a bank that is not a known settlement partner, or in an amount that exceeds reasonable thresholds for that counterparty, the system does not simply log it and wait for a SOAR to respond. It holds the message and requires intervention. Again, this is embedded in the data plane.

For healthcare or other domains where regulatory reporting is itself an operational function, domain-specific automation means encoding the regulatory schema (DORA, NIS2, APRA CPS 234, MAS TRM) not as a post-hoc compliance checklist but as a constraint on how data can be classified, stored, and exfiltrated. If a DORA-reportable event is triggered (e.g., attempted unauthorised access to a system holding customer financial data), the system does not alert a SOAR and wait for human action. It automatically initiates the incident-logging workflow, sets up the required evidence chain, and begins the clock on the 72-hour notification requirement. The regulator's timeline becomes an operational primitive, not a procedure.

These designs share several common principles:

Zero-knowledge substrate: The organisation's operations are designed so that the data required to execute a malicious action is not held in any single location or accessible via any single compromise. A trader cannot exfiltrate an entire clearing position. A messaging node operator cannot forge a transaction. A healthcare administrator cannot wholesale delete audit logs. This is not achieved through access control lists (which can be bypassed). It is achieved through cryptographic partitioning: the knowledge required to perform any given action is distributed across multiple systems, each with its own threat model.

Data-plane enforcement: Policy is not applied at the monitoring or alerting layer. It is applied where data actually moves. A SWIFT routing decision includes a policy check. A database transaction includes a validation step that is part of the write path, not a separate observer process.

Adaptive posture: The system continuously adjusts its operational behaviour in response to observed threat patterns, but this adjustment is done by tuning domain-specific parameters (e.g., the threshold for "anomalous transaction amount", the list of acceptable routing destinations, the cryptographic key rotation schedule), not by deploying new playbooks or alert rules. The system learns from its operational context without requiring external orchestration.

Continuous adversarial drift: The system assumes that attackers are actively trying to evade its detection. Instead of writing signatures for known attacks, the system enforces invariants that are hard-wired into the operational model itself. A SWIFT message that violates the logical structure of settlement cannot be processed, no matter how sophisticated the attacker's obfuscation. A ledger entry that violates the integrity constraint cannot be committed. This is not a signature. It is an invariant.

Regulatory Alignment: Why Sovereignty Demands Substrate Control

Regulators increasingly understand that generic compliance is not compliance. The SEC's 4-day rule (expedited notification of cybersecurity incidents) applies differently to a broker-dealer than to a custodian, because the data planes are different. APRA's CPS 234 (information security) explicitly distinguishes between "critical data" (which has higher integrity and availability requirements) and other data, and mandates that security controls be proportionate to criticality. The NIS2 Directive creates a two-tier system (essential services and important services), with different baseline requirements for each.

This regulatory differentiation implicitly endorses domain-specific security architecture. A financial institution that implements a generic SOAR and claims compliance is not meeting the letter or spirit of these regimes. DORA (Digital Operational Resilience Act) mandates that organisations have the ability to identify and respond to incidents "in real time". Real-time response to a generic alert generated by a SOAR is not real-time response to an actual operational threat. Real-time response means the system prevents the threat from reaching operational consequence, which requires domain-specific automation.

Furthermore, PULSE's focus on sovereign digital infrastructure is directly aligned with emerging regulatory doctrine around critical data residency, encryption key management, and supply-chain integrity. An organisation that outsources its incident response logic to a third-party SOAR vendor (which many do—Palo Alto Networks and Splunk operate SaaS versions of their SOAR products) is outsourcing the ability to respond to a breach of its own critical systems. This is a regulatory liability under NIS2, NYDFS Part 500 (third-party service provider requirements), and APRA's expectations around outsourcing governance.

Domain-specific automation, built into the organisation's own substrate and not dependent on external vendors, returns control over incident response to the organisation itself.

The Transition: From Playbook to Invariant

The move from generic playbooks to domain-specific automation is not a product purchase. It is a redesign of how the organisation embeds security into its operational primitives.

The first step is to map the organisation's actual threat model and data plane. This is not a NIST CSF assessment or an ISO 27001 audit. It is a technical deep-dive: what are the adversary's actual objectives (theft of transaction data, insertion of false transactions, denial of service to key counterparties)? What are the minimum privileges required for each operational function? Where can cryptographic enforcement be applied without breaking operational flow? Where must human judgment be retained?

The second step is to identify the domain-specific invariants that, if enforced, would prevent the organisation's threat model from reaching consequence. For a settlement system, this might be: "no transaction commits without cryptographic proof of intent from both counterparties", or "the ledger state is always verifiable against a distributed witness set". For a messaging system, it might be: "no message is routed outside the pre-authorised counterparty graph" or "all routing decisions are logged to an immutable audit trail before they execute".

The third step is to implement these invariants as control structures in the data plane itself, not as SIEM rules or SOAR playbooks. This may require re-architecture of the system (e.g., shifting to a message-queuing architecture that enforces routing constraints, or implementing a multi-signature transaction model), but the investment is proportionate to the criticality of the data.

The fourth step is to design the monitoring layer to support the domain-specific posture—i.e., to detect when the adversary is attempting to subvert the invariants themselves, not to generate generic alerts about "anomalous activity".

Invitation to Qualified Operators

Organisations holding or transferring the world's data and currency should request a confidential technical briefing from PULSE on designing domain-specific automation that is proportionate to their operational and regulatory context.