The Day DORA Became Real: What January 17 Means for 22,000 Financial Entities

What Actually Changed at Midnight

At 00:00 CET on January 17, 2025, Regulation (EU) 2022/2554 became directly applicable law in every EU member state. No transposition required. No grace periods. No opt-outs. Approximately 22,000 financial entities — banks, insurers, investment firms, payment institutions, crypto-asset service providers, and 15 other categories enumerated in Art. 2(1) — woke up to a fundamentally different regulatory reality.

The reality, of course, is that DORA did not appear overnight. Published in the Official Journal on December 27, 2022, the regulation provided a two-year implementation window. The ESAs (EBA, EIOPA, ESMA) published their first batch of Regulatory Technical Standards throughout 2024. The European Commission adopted the final delegated acts in the weeks preceding the application date. The question was never whether DORA would arrive — it was whether the industry would be ready.

The data suggests it was not.

The Deloitte European Survey on DORA readiness, covering respondents across 28 countries, found that only 25% of financial institutions expressed confidence in their compliance posture. PwC's parallel assessment reported that 70% of firms were concerned about meeting the requirements on time. These are not outlier findings — they represent the consensus view of an industry that underestimated the regulation's operational depth.

Five Pillars, One Regulation: The Architecture of DORA

DORA is not a single requirement. It is a framework of five interlocking pillars, each addressing a distinct dimension of operational resilience:

Figure 1: DORA's five interlocking pillars. Pillars III (Resilience Testing) and IV (Third-Party Risk) shown in amber represent the widest readiness gaps according to industry surveys.

The aggregate picture is concerning. Pillars III and IV — resilience testing and third-party risk management — represent the widest readiness gaps. These are also the pillars with the highest operational complexity: testing requires infrastructure, scenarios, and governance that cannot be procured overnight, and third-party risk management requires data collection across hundreds or thousands of vendor relationships.

The First Batch of Technical Standards

DORA's application date coincided with the finalization of the regulatory technical standards that give the regulation its operational specificity. The first batch, published in the Official Journal in January 2025, covered:

• RTS on ICT risk management framework (Art. 15): Detailed requirements for ICT risk identification, protection, detection, response, and recovery — including mandatory elements for business continuity and disaster recovery.
• RTS on incident classification (Art. 18(3)): The classification criteria for major ICT-related incidents, including materiality thresholds that trigger reporting obligations.
• ITS on incident reporting (Art. 20): The standard templates and timelines for reporting incidents to national competent authorities.
• RTS on ICT third-party risk management (Art. 28(10)): The detailed requirements for managing third-party ICT risk, including the register of information.
• ITS on the Register of Information (Art. 28(9)): The standard templates for recording contractual arrangements with ICT third-party service providers.

A second batch — covering TLPT requirements, threat-led penetration testing, and the Lead Overseer oversight framework — was in various stages of finalization. The subcontracting RTS, notably, was rejected by the European Commission on January 21, just four days after DORA became applicable, forcing a rapid revision cycle.

The ECB's Pre-DORA Stress Test: 109 Banks, Systemic Gaps

In mid-2024, the ECB conducted its first dedicated cyber resilience stress test, covering 109 directly supervised banks. The exercise was explicitly designed to assess preparedness for the DORA requirements that would become applicable six months later.

The findings were sobering. While the ECB did not publish institution-specific results, supervisory communications made clear that recovery capabilities — the ability to restore critical functions within defined timelines after a severe ICT disruption — showed significant gaps across the supervised population. Specific weaknesses included:

• Recovery time objectives (RTOs) not validated through testing. Institutions stated RTOs for critical functions but had not tested whether they could actually achieve them.
• Backup restoration untested at scale. Art. 12 requires that backup procedures be tested periodically. The ECB found that many institutions had never performed a full-scale restoration test.
• Third-party dependencies not mapped to recovery plans. Institutions could not articulate how a critical third-party failure would affect their recovery timeline.
• Incident communication plans incomplete. Art. 14(2) requires the management body to be informed of major incidents. The ECB found that escalation procedures were often informal and untested.

The stress test was a dress rehearsal. The results confirmed that DORA's requirements, far from being bureaucratic overhead, targeted real and measurable gaps in the industry's operational resilience posture.

Where the Gaps Are Widest: A Pillar-by-Pillar Assessment

Pillar III: Resilience Testing (Art. 24-27)

The Deloitte survey data, combined with McKinsey's operational assessment, paints a stark picture of testing readiness:

Art. 25 requires that resilience testing be performed at least annually, covering "all ICT systems and applications supporting critical or important functions." For significant institutions subject to Threat-Led Penetration Testing (TLPT) under Art. 26, the bar is higher: live production testing using real threat intelligence, conducted by qualified red teams, with results reported to the competent authority.

Most institutions had some form of penetration testing before DORA. Few had the programmatic, evidence-based testing framework that DORA demands — one that connects test scenarios to identified risks, produces verifiable evidence of recovery capability, and feeds results into the ICT risk management framework in a documented cycle.

Pillar IV: Third-Party Risk Management (Art. 28-44)

The 46% figure from Deloitte — the share of institutions naming the Register of Information as their hardest DORA challenge — deserves unpacking.

Art. 28(3) requires every financial entity to maintain a register recording all contractual arrangements with ICT third-party service providers. This is not a simple vendor list. The register must capture the nature of services provided, whether they support critical or important functions, the location of data processing and storage, subcontracting chains, and audit rights. The ITS published in January 2025 specified the exact template — a multi-tab structure with dozens of mandatory fields per contractual arrangement.

For a mid-size bank with 200-300 ICT vendor relationships, populating this register from scratch required engaging with every vendor, extracting contractual data that was often dispersed across procurement, legal, IT, and business units, and making criticality determinations that many institutions had never formalized. McKinsey's finding that 40% of firms dedicate more than 7 FTEs to this effort becomes understandable in this context.

What Supervisors Are Looking at First

National competent authorities across the EU signaled their supervisory priorities in the weeks surrounding January 17. While approaches varied by jurisdiction, a consistent pattern emerged:

Figure 2: Supervisory priority sequencing across 2025. Red indicates immediate supervisory focus areas; amber indicates near-term priorities.

Immediate priorities (Q1 2025):

• Existence of an ICT risk management framework (Art. 5-6) with documented management body approval
• Incident classification and reporting capability (Art. 17-20) — can the institution detect, classify, and report within the prescribed timelines?
• Initial Register of Information population (Art. 28(3)) — the first submission window opened in April 2025

Near-term priorities (Q2-Q3 2025):

• Resilience testing programme establishment (Art. 24-25) — not necessarily completed tests, but an approved programme with scenarios, timelines, and governance
• Third-party risk assessment for critical or important function providers (Art. 28-29)
• Concentration risk assessment (Art. 29) — particularly cloud and technology platform dependencies

Medium-term priorities (Q4 2025 and beyond):

• TLPT execution for significant entities (Art. 26-27)
• Lead Overseer regime implementation for designated critical ICT third-party providers (Art. 31-44)
• Cross-border supervisory cooperation on shared ICT risk exposures

The pragmatic sequencing reflects regulatory realism. Supervisors understood that full compliance on Day One was aspirational for most institutions. The implicit message: demonstrate that you have a credible programme with clear milestones and governance. What supervisors will not tolerate is the absence of a programme — institutions that treated DORA as a future problem as of January 17 face the most acute supervisory risk.

The Proportionality Principle: Not One Size

Art. 4 establishes the proportionality principle: DORA requirements apply "taking into account [the entity's] size and overall risk profile, and the nature, scale, and complexity of their services, activities, and operations." This is not a blanket exemption for smaller institutions — it is a calibration mechanism.

Proportionality affects how requirements are implemented, not whether they apply. Even a microenterprise must have an ICT risk management framework, manage incidents, and maintain a register of third-party providers. The framework can be simpler, the testing less extensive, the governance lighter — but the obligations exist.

The Path from Day One

January 17, 2025 was not a finish line. It was the starting gun for a multi-year supervisory cycle that will progressively deepen requirements, sharpen enforcement, and raise the operational resilience floor across European financial services.

The institutions best positioned are those that treated the two-year implementation window as exactly that — an implementation period, not a waiting period. They staffed programmes, engaged vendors, built testing capabilities, and invested in the technology and processes needed to operate in a DORA-compliant mode.

For those still building, the priority hierarchy is clear:

Figure 3: Recommended implementation priority hierarchy for institutions still building DORA capabilities.

1. Governance first. Ensure the management body has formally approved the ICT risk management framework (Art. 5(2)). This is the supervisory entry point — without board-level ownership, nothing downstream has authority.

1. Incident capability second. The 4-hour reporting window (Art. 19(4)(a)) is the most time-sensitive obligation. Establish detection, classification, and notification pipelines before they are needed.

1. Register of Information third. The April 2025 submission deadline is real. Start with critical and important function providers — do not attempt to catalogue every vendor simultaneously.

1. Testing programme fourth. Establish the programme, define scenarios linked to identified risks, and begin execution. Evidence of a credible, progressing programme is more defensible than no programme at all.

1. Continuous improvement always. DORA is not a one-time exercise. Art. 6(5) requires the ICT risk management framework to be "documented, reviewed at least once a year." Build the rhythm of review, test, evidence, report into operational cadence.

Twenty-two thousand entities. Five pillars. One regulation. The operational resilience era for European finance has begun.

---

This analysis reflects Regulation (EU) 2022/2554 and associated technical standards as applicable from January 17, 2025. Supervisory approaches vary by jurisdiction and entity type.

---