Why DORA Will Fail Regarding Cyber Risks

The Uncomfortable Question

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) became applicable on 17 January 2025. It is the EU's most ambitious attempt to secure the financial sector's digital infrastructure. It mandates ICT risk management frameworks. It requires incident classification and reporting. It demands resilience testing, including threat-led penetration testing (TLPT). It establishes an oversight framework for critical ICT third-party providers.

And yet, when it comes to cyber threats specifically, DORA contains a structural defect so fundamental that no amount of RTS, ITS, or supervisory guidance can fix it.

DORA demands that financial entities "identify all sources of ICT risk" and "assess cyber threats" — but provides no taxonomy for what those cyber threats are.

This isn't a minor omission. It's the logical equivalent of mandating a medical diagnosis system without providing a disease classification. Every hospital would invent its own categories. "Fever" would be both a symptom and a disease. Comparability across institutions would be impossible. And the entire system would quietly collapse into a compliance exercise that checks boxes without actually improving anyone's health.

That's what's happening right now in EU financial services.

What DORA Actually Says

DORA Article 5 requires financial entities to establish an ICT risk management framework. Article 8(2) states:

Financial entities shall, on a continuous basis, identify all sources of ICT risk, in particular the risk exposure to and from other financial entities, and assess cyber threats and ICT vulnerabilities relevant to their ICT supported business functions, information assets and ICT assets.

Read that carefully. The regulation explicitly separates "cyber threats" from the broader "ICT risk" universe. It recognizes that cyber threats are a specific category of risk requiring specific assessment. This is correct. But then DORA does something remarkable: it never defines what those cyber threat categories are.

The regulation defines "ICT risk" (Article 3(4)) as "any reasonably identifiable circumstance in relation to the use of network and information systems which, if materialised, may compromise the security..." — a consequence-oriented definition. It defines "cyber threat" (Article 3(12)) by reference to the EU Cybersecurity Act (Regulation (EU) 2019/881), which describes it as "any potential circumstance, event or action that could damage, disrupt or otherwise adversely impact network and information systems."

Neither definition provides a taxonomy. Neither tells a financial entity which cyber threats to assess. Neither provides categories that would allow Entity A to compare its risk assessment with Entity B.

The Classification Problem

The RTS on incident classification (Commission Delegated Regulation (EU) 2024/1772) goes further — but in the wrong direction. It classifies incidents by their impact: affected clients, data losses, economic impact, duration, geographical spread, criticality of services affected. The RTS on incident reporting (Commission Delegated Regulation (EU) 2025/301) requires three-stage reporting (initial within 4 hours, intermediate within 72 hours, final within one month) and classifies incidents into five types:

• Cybersecurity-related
• Process failure
• System failure
• External event
• Payment-related

Look at what's happened here. DORA has created an incident classification that mixes causes with consequences and categories with domains:

• "Cybersecurity-related" is supposed to be a cause category — but it's undefined. What exactly makes an incident "cybersecurity-related" versus a "system failure"? If a ransomware attack (#7 Malware) encrypts a database, is that cybersecurity-related (because a threat actor did it) or a system failure (because the system stopped working)? DORA doesn't say.
• "Process failure" and "System failure" are consequence descriptions — they tell you what failed, not why it failed. An SQL injection attack (#2 Server Exploits) that crashes a database presents as a "system failure." So does a power surge. So does a software bug. The classification collapses all three into the same bucket.
• "External event" is a topology description — it says something came from outside. But "outside" relative to what? A supply chain compromise (#10) is external. So is an earthquake. So is a regulatory change.

The Bow-Tie Problem: Why This Matters

To understand why DORA's approach structurally fails for cyber risk, consider the Bow-Tie risk model — a standard tool in operational risk management that DORA itself implicitly references through its emphasis on both prevention and recovery.

A Bow-Tie separates risk into five elements: Threats (causes) → Preventive Controls → Central Event (loss of control) → Mitigating Controls → Consequences (effects)

DORA's incident classification lives almost entirely on the right side of the Bow-Tie. It classifies by impact on services, by the number of affected clients, by economic loss, by duration. These are all consequences. Even the five incident types describe observable symptoms, not root causes.

But effective cyber risk management requires understanding the left side — what generic vulnerability was exploited, through what mechanism, via what attack vector. Without cause-side classification, you cannot:

1. Map controls to threats. If you don't know whether a system failure was caused by #2 Server Exploits (requiring input validation, patching, WAF) or #6 Flooding Attack (requiring rate limiting, capacity planning, CDN) or #7 Malware (requiring application control, EDR, execution prevention), you cannot determine whether your controls actually address the threat. You can only determine whether you have controls in general — which is the definition of a compliance exercise.
2. Compare incidents across entities. Two banks report a "major cybersecurity-related incident." Bank A was compromised through #9 Social Engineering → #4 Identity Theft → #1 Abuse of Functions. Bank B was compromised through #10 Supply Chain Attack → #7 Malware. These are fundamentally different threats requiring fundamentally different controls. DORA's classification treats them as the same type of incident.
3. Learn from incidents. Post-incident analysis requires understanding what went wrong causally. "A cybersecurity-related incident occurred that affected 50,000 clients and caused €2M in losses" tells you the consequence but nothing about the cause. It's like a medical system that records "patient died" without recording the disease.
4. Validate control effectiveness. DORA Article 9 requires "protection and prevention" measures. Article 10 requires "detection" capabilities. But protection against what? Detection of what? Without threat categories, control objectives cannot be specified. And without specified control objectives, control effectiveness cannot be assessed.

The Velocity Blindspot

There's a deeper problem that DORA's framework cannot even express, let alone address: attack velocity. DORA's reporting timeline assumes a common temporal profile. But cyber attacks operate across vastly different velocity classes:

• VC-1 (Strategic / Days to Months): Advanced persistent threats, slow supply chain compromises, insider threats building access over time. Detection requires log retention and threat hunting. DORA's reporting timeline works here.
• VC-2 (Tactical / Hours): Targeted attacks with human-speed progression. SIEM alerting and analyst triage are viable. DORA's 24-hour classification window is tight but manageable.
• VC-3 (Operational / Minutes): Automated lateral movement after initial compromise. At this speed, the attack may have achieved its objectives before the 4-hour initial notification deadline arrives. SOAR and EDR automation are required — human-dependent controls are structurally insufficient.
• VC-4 (Real-Time / Seconds to Milliseconds): Wormable exploits, automated exploitation chains, real-time DDoS. At this velocity, the entire attack completes before a human can classify the incident. Architectural controls (segmentation, circuit breakers, rate limiting) are the only structurally viable defense.

DORA treats all cyber incidents as having the same temporal profile. It doesn't ask: "At what velocity did this attack progress?" It doesn't require financial entities to assess whether their controls can structurally operate at the velocity of the threats they face.

The Third-Party Taxonomy Gap

DORA's Chapter V on ICT third-party risk management is arguably its strongest innovation. But even here, the missing threat taxonomy creates a structural gap.

DORA requires financial entities to assess the ICT risk associated with third-party providers. But what specific threats does a third-party relationship introduce? Without a taxonomy, the answer is vague: "the provider might be compromised" or "the service might be disrupted."

With a cause-based taxonomy, the answer becomes precise. A third-party ICT relationship introduces exposure to #10 Supply Chain Attack at every Trust Acceptance Event (TAE) — every point where your systems accept the third party's artifacts as authoritative. But the downstream effects depend on what the artifact enables: it might lead to #7 Malware (executable code), or #1 Abuse of Functions (excessive privileges), or #4 Identity Theft (fraudulent identity assertions).

Without this vocabulary, DORA's register of information captures which providers exist, but not where the trust boundaries are and what specific threat paths each boundary enables.

What "Risk-Based" Actually Requires

DORA repeatedly claims to establish a "risk-based approach." But here's the logical structure of actual risk-based management:

1. Step 1: Identify threats (what can go wrong — cause-side)
2. Step 2: Assess vulnerability (what exposure exists)
3. Step 3: Evaluate impact (what consequences would follow)
4. Step 4: Select controls (what reduces likelihood or impact)
5. Step 5: Assess residual risk (what remains after controls)

DORA skips Step 1 for cyber threats. It jumps directly from "you must identify all sources of ICT risk" to prescriptive control requirements without first establishing which threats those controls address.

This is the logical impossibility of control-first regulation: you cannot rationally select, prioritize, or validate controls without first knowing what threats they're supposed to counter.

The Comparison Trap

To be fair, DORA is not alone in this failure. The entire cybersecurity regulatory landscape shares the same structural defect. ISO/IEC 27001 mandates risk assessment but provides no threat taxonomy. NIST CSF 2.0 defines risk management functions but leaves threat categorization to the implementer. CMMC 2.0 prescribes maturity levels without anchoring them in a threat model.

Across 30+ major cybersecurity standards and regulations, the pattern repeats: controls are prescribed, outcomes are measured, but the cause-side — the actual cyber threats — remains undefined. DORA had the opportunity to break this pattern. It didn't.

What Would Fix This

The solution isn't complicated in principle. DORA's framework needs a cause-side taxonomy that:

• Classifies by generic vulnerability, not by outcome. Defined by root weakness, not what happens afterwards.
• Is non-overlapping. Each attack step should map to exactly one category. Overlapping categories destroy comparability.
• Separates threats from actors. Attribution is metadata, not a threat classification dimension.
• Supports sequential expression. Real cyber attacks are multi-step.
• Includes temporal dimension. Attack velocity determines which controls are structurally viable.
• Defines domain boundaries. Marking where trust boundaries are crossed in third-party risk.

The Prediction

Here's what will happen without a cause-side taxonomy:

• Year 1 (2025): Financial entities implement DORA frameworks. They create ICT risk management policies, establish incident reporting processes, conduct resilience testing. Compliance rates will be high. The ESAs will report successful implementation.
• Year 2-3 (2026-2027): Major cyber incidents will occur at DORA-compliant financial entities. Post-incident analysis will reveal that required controls were in place but didn't address the actual attack vector. Incident reports will classify incidents as "cybersecurity-related" without further causal precision, making cross-entity learning impossible.
• Year 4-5 (2028-2029): The ESAs' feasibility report on centralized incident reporting (mandated by DORA Article 21) will struggle with data quality. Aggregated incident data will show how many "cybersecurity-related" incidents occurred but not which threats are increasing or decreasing. Trend analysis will be limited to consequence metrics (financial impact, duration, affected clients) rather than threat evolution.

Ongoing: DORA will succeed as an ICT operational resilience framework. System failures, process failures, and business continuity incidents will be managed more consistently. But for cyber threats specifically — the attacks by adversaries exploiting generic vulnerabilities — DORA will remain a framework that requires "risk-based management" without providing the vocabulary to name the risks.

The regulation will not fail loudly. It will fail quietly, in the gap between compliance and actual security, where a financial entity has checked every box and still cannot describe, in consistent and comparable terms, what threatens it.

Conclusion: The Missing Noun

DORA provides excellent verbs: identify, protect, detect, respond, recover, report, test. It provides a comprehensive grammar: who must do what, when, how, and under what supervision.

But it's missing the nouns — the standardized, cause-based names for the cyber threats that all those verbs are supposed to act upon.

Until that gap is filled, DORA will remain a regulation that tells financial entities to manage cyber risk without giving them a common language to describe it. And a risk you can't consistently name is a risk you can't consistently manage.