DORA is Quietly Eating European Compliance — What Operators Should Know

The Digital Operational Resilience Act Will Dismantle Your Compliance Theatre, and No One is Ready

The European Union's Digital Operational Resilience Act (DORA) arrives on 17 January 2025 not as a technical standard but as an architectural indictment: your compliance function cannot coexist with operational resilience, and regulators have finally stopped pretending otherwise.

For fifteen years, European financial institutions have paid for layered detection-and-response architectures—Security Information and Event Management (SIEM) platforms, Endpoint Detection and Response (EDR) systems, Data Loss Prevention (DLP), firewalls, intrusion detection systems—and documented their compliance via audit reports, penetration tests, and signed ISO 27001 certifications. The industry narrative has held that risk is managed through process: threat hunting, incident response playbooks, evidence retention, and periodic tabletop exercises. DORA is not revising that narrative. It is killing it.

The Act's operational resilience mandate—enforceable across banks, investment firms, cryptocurrency custodians, and critical third-party service providers under European Banking Authority (EBA) and European Securities and Markets Authority (ESMA) supervision—introduces a structural requirement that legacy control architectures cannot satisfy: organisations must demonstrate continuous resistance to operational disruption, not merely prove they detected an intrusion after it occurred. That distinction is the central tension this article exists to expose.

The Regulatory Escalation: From Compliance Ticketing to Resilience Measurement

DORA operationalises what regulators learned from a cascade of high-impact failures between 2020 and 2024. The SolarWinds compromise (2020) revealed that supply-chain integrity controls were security theatre—vendors with apparent security maturity shipped trojanised software into thousands of enterprise networks. The LastPass breach (2022) demonstrated that companies holding cryptographic material could be compromised at scale, destroying customer trust in the fundamental architecture they promoted. The Optus incident (2022) and Latitude (2023) showed that customer data protection regulations were toothless when encrypted vaults were accessible to authenticated insiders. The Synnovis ransomware attack cascading into NHS digital service collapse (2024) proved that even critical national infrastructure lacked post-breach recovery architecture.

These incidents did not fail because organisations lacked SIEM rules or EDR sensors. LastPass had sophisticated detection capabilities. Optus employed reputable security firms. Synnovis was accredited under UK information security standards. They failed because the control architecture was built on assumption of prevention—the fantasy that detection-and-response workflow would contain breaches before data exfiltration. It did not.

DORA's regulatory machinery crystallises this failure into law. The Act establishes four operational resilience pillars: Governance and Organisation, ICT Risk Management, ICT-Related Incident Reporting and Disclosure, and Digital Operational Resilience Testing. The fourth pillar—mandatory in-the-wild security testing, threat-led penetration testing (TLPT), and red-team exercises—is the mechanical shift. Organisations must now demonstrate ongoing resilience against adversarial pressure. This is not a checkbox audit. The EBA and ESMA have published detailed implementing technical standards (ITS) requiring testing at least once every three years, with testing scopes covering asset inventories, supply-chain risk, third-party dependencies, and incident recovery capabilities. The UK Financial Conduct Authority (FCA) has published mutually compatible guidance, and the Swiss Financial Market Supervisory Authority (FINMA) has signalled alignment.

The ambition is clear: regulators want to shift the operational burden from detection to resistance. And legacy architectures—SIEM centralisation, EDR silver-bullet thinking, DLP boundary controls—are precisely the wrong substrate for that shift.

Why Detection-and-Response Architecture Guarantees Resilience Failure

The industry's response to DORA has so far been technical optimisation of existing systems: upgrading SIEMs to correlate more events, deploying Security Orchestration, Automation and Response (SOAR) to automate playbooks, expanding EDR sensor coverage to 100% of endpoints. None of this addresses the architectural problem.

Consider the topology that emerged from two decades of NIST Cybersecurity Framework and ISO 27001 adoption. A typical large European bank has:

• Centralised SIEM ingesting terabytes daily from network sensors, firewalls, and endpoint agents, storing events in a data lake. Threat analysts write correlation rules (often in Sigma or YARA syntax) to detect patterns matching MITRE ATT&CK technique IDs—T1021 (Remote Service Session Initiation), T1098 (Account Manipulation), T1567 (Exfiltration Over Web Service). When a rule fires, a ticket enters a ServiceNow workflow.
• EDR on every endpoint logging process creation, file writes, network connections. The EDR vendor's cloud backend detects "suspicious" behaviour via machine-learning models trained on malware datasets. Alerts feed back to analysts via a dashboard.
• DLP appliances at network egress and on file shares, pattern-matching on credit-card numbers, account numbers, and regulatory keywords (GDPR, HIPAA, MAS TRM).
• Incident response playbooks with predetermined escalation paths, legal notification procedures, and regulator communication templates.

This stack assumes a linear incident lifecycle: breach occurs, detection fires, analysts investigate, adversary is evicted, forensics are collected, incident is reported within regulatory timelines (typically 72 hours for GDPR, 4 business days under SEC Rule 10b-5), and the organisation learns from the event.

But operationally, this model breaks under three conditions:

First: Detection latency destroys the prevention paradigm. The CrowdStrike Falcon Sensor outage (July 2024), whilst not a breach, exposed how completely organisations depend on a single detection vendor's availability. More critically: a sophisticated adversary with legitimate credentials (insider threat, compromised account, supply-chain compromise) will move laterally, escalate privilege, and exfiltrate data before any EDR rule has a statistical basis to fire. The Change Healthcare ransomware incident (2024) involved attackers who established persistence for months before triggering ransom encryption—detection systems watched the entire campaign unfold and reported nothing actionable. The data was already staged for exfiltration.

Second: SIEM centralisation creates a single point of catastrophic failure. The moment an adversary gains access to the SIEM itself—as happened in the SolarWinds incident and is explicitly part of the MITRE ATT&CK framework (T1557 Adversary-in-the-Middle applied to log aggregation)—all downstream alerts become untrustworthy. An attacker with SIEM write access can modify alerts, delete event logs, and tamper with incident timelines. You cannot use a centralised system to detect compromise of that centralised system. This is not a gap in product implementation; it is a logical contradiction in the architecture itself.

Third: Incident response playbooks assume you can evict the adversary. Modern ransomware families (BlackCat/ALPHV, LockBit variants, Royal) are designed to be resilient against eviction. They dump credentials to underground markets, corrupt backup systems, and leave encrypted payloads that trigger days or weeks after initial discovery. Even if you detect them at Day 30, backups are corrupted, and ransom decryption is the only recovery path. DORA's "operational resilience" mandate implicitly rejects the assumption that eviction is possible; it demands you design for coexistence with undetected adversaries and recovery without adversary cooperation.

This requirement invalidates the entire detection-and-response paradigm.

The PULSE Reframing: Architecture, Not Detection

PULSE's doctrine responds to this regulatory transition with a structural inversion: do not design for detection of unauthorised activity; design so that unauthorised activity cannot access, modify, or exfiltrate the operationally critical assets that regulators care about.

This is not a semantics shift. It is an architectural commitment to three engineering principles:

Zero-Knowledge Substrate: Data at rest and in transit must be cryptographically isolated such that compromise of any single control plane (SIEM, EDR vendor infrastructure, cloud provider account, employee workstation) does not grant access to operational data. This differs from conventional encryption by design: rather than encrypt data after centralising it in a SIEM or data lake, isolate the cryptographic material itself. The organisation never holds plaintext copies of sensitive operational state in locations where logging or detection occurs. A sophisticated adversary may compromise your SIEM, but the SIEM should contain no decryption keys, no plaintext customer records, and no evidence of which systems hold sensitive assets.

Data-Plane vs. Control-Plane Separation: Legacy architectures mix operational processing (the data plane—customer transactions, settlement, clearance) with management and monitoring (the control plane—logging, alerting, policy enforcement). When the control plane is compromised (via SIEM breach, EDR vendor compromise, or insider access to monitoring dashboards), the adversary has visibility of operational topology and can pivot to high-value targets. DORA compliance requires that operational systems continue functioning correctly even when control-plane visibility is lost. This demands architectural primitives: quorum-based decision making for critical transactions, cryptographic proof-of-work for state commitments, and decentralised log verification that does not depend on centralised SIEM availability.

Continuous Adversarial Posture Drift: Rather than rely on annual penetration testing or triennial threat-led penetration testing to assess resilience, the organisation must continuously adjust its operational posture in response to simulated adversarial pressure. This is not a detection exercise; it is a chaos-engineering practice applied to security. You introduce simulated faults, credentials, and network topology changes into operational systems in production, and measure whether critical transactions continue completing, whether backups remain intact, and whether adversary-visible state changes in expected ways. Domain-specific automation—cryptographic verification of backup integrity, continuous rotation of session keys, automated rollback of suspicious policy changes—becomes part of the operational substrate, not a tool bolted onto a SIEM.

DORA's Technical Implementation: What Regulators Are Actually Asking For

The EBA's implementing technical standards and ESMA's consultation documents make this architectural requirement explicit, though they use regulatory language rather than technical jargon.

The "ICT Risk Management" pillar (DORA Article 6) demands organisations:

• Identify and document all assets involved in "critical functions" and "important functions" (payment processing, trade execution, fund custody, settlement). This inventory is not a spreadsheet; it is a cryptographic asset register where every component has verifiable provenance.
• Define "impact tolerance" for each function—the maximum acceptable duration of unavailability and data modification. For critical functions, this is measured in minutes or hours, not days.
• Implement "ICT security measures" that ensure continued operation even if specific components fail or are compromised.

The "Digital Operational Resilience Testing" pillar (DORA Articles 19-21) requires:

• Advanced Security Testing: organisations must conduct adversarial testing (red teaming) that simulates sophisticated threat actors. The testing must target "ICT components and functionalities", which includes third-party systems, cloud infrastructure, and supply-chain dependencies.
• Threat-Led Penetration Testing (TLPT): organisations must hire external teams (neither their in-house security staff nor their regular penetration testing vendors, who have commercial relationships) to attack their systems with threat intelligence briefing. A TLPT team uses current TTPs (Tactics, Techniques, and Procedures) from observed threat actors—not just MITRE ATT&CK technique lists, but the actual malware families, privilege escalation chains, and exfiltration methods currently in use.
• Scenario Analysis: organisations must test recovery from specific scenarios: ransomware encryption, database deletion, cryptographic key compromise, insider-initiated data exfiltration, and third-party service outage.

Critically, these tests must demonstrate that:

• Critical functions remain available (not just that alerts fire; that customer transactions complete).
• Backups can be restored without adversary cooperation.
• Compromised credentials or encryption keys do not grant access to unencrypted operational data.
• Supply-chain dependencies can be isolated without cascading failure.

These requirements are not achievable by upgrading EDR sensors or writing better SIEM correlation rules. They demand fundamental architectural change.

Operational Implications for Financial Services and Critical Infrastructure

The practical effect of DORA is immediate and economically significant. European institutions subject to EBA and ESMA oversight must, by 17 January 2025:

• Commission external red-team engagements (TLPT) covering attack surfaces that their own security teams have never properly tested.
• Demonstrate that critical functions survive the compromise of their SIEM, EDR vendor infrastructure, and cloud provider accounts.
• Prove that ransomware encryption cannot reach unencrypted backups.
• Show that insider exfiltration of customer data can be detected and stopped before it leaves the organisation's control.

These requirements immediately expose gaps in existing architectures. Consider a typical scenario: a European investment bank's equity trading system processes €50 million daily in customer orders. The trading infrastructure is protected by firewalls, monitored by EDR, and logged to a centralised SIEM. When auditors ask, "Can trading continue if the SIEM is offline?" the answer is typically "the trading system would keep running, but we wouldn't see if it was being attacked." DORA is saying: that is unacceptable.

The regulatory deadline—17 January 2025—has already arrived. Institutions that have not fundamentally redesigned their operational resilience posture are now operating in breach of enforceable regulation. The EBA and ESMA do not have enforcement authority; national regulators (FCA in the UK, BaFin in Germany, AMF in France, Central Bank of Ireland) have been instructed to enforce DORA. The first enforcement actions and penalties will likely emerge within 18-24 months, as institutions fail to demonstrate TLPT results or incident recovery capabilities.

The Architectural Transition: From Theatre to Engineering

The shift from compliance theatre to operational resilience is not cost-neutral. Organisations will need to:

• Redesign data protection: move from perimeter-based DLP to cryptographic isolation of sensitive data, with keys held in hardware security modules (HSMs) distributed across multiple control domains.
• Decentalise critical functions: replace centralised SIEMs with distributed log verification systems that do not create a single point of failure.
• Automate posture adjustment: implement domain-specific automation that continuously rotates credentials, patches vulnerable systems, and blocks known malicious patterns—not as a SOAR workflow, but as embedded operational logic.
• Establish red-team practices: make adversarial testing a continuous operational function, not an annual exercise.

The cost is substantial, but the regulatory compulsion is now law. Organisations cannot opt out; they can only choose how quickly to adapt.

---

Qualified operators—Chief Information Security Officers, Chief Risk Officers, Chief Technology Officers—confronting DORA's architectural requirements under enforceable deadline should request a technical briefing under Mutual NDA to discuss how sovereign resilience architecture differs from detection-and-response retrofit.