DORA: One Year On – Between Ambition and Reality

When the Digital Operational Resilience Act (DORA) became fully applicable on 17 January 2025 after a two-year transition period, it was hailed as a milestone in European financial regulation. For the first time, the EU created a harmonised framework for digital resilience across the entire financial sector – from major banks and insurers to crypto service providers. Fourteen months on, the picture is sobering: 44 per cent of German financial institutions are still not DORA-compliant, according to an Advisori survey (self-assessment, Q1 2026). Not a single bank surveyed by KPMG (DORA Readiness Survey, 2024/25) had fully met the requirements by the deadline – though "not fully" covers a broad spectrum, from nearly complete to fundamentally deficient.

The gap between regulatory ambition and operational reality is remarkable. While supervisory authorities – BaFin foremost among them – are transitioning from a "guidance phase" to "interventionist supervision", many institutions are still grappling with the basics: inventorying their ICT service providers, establishing automated reporting systems, and integrating resilience testing into day-to-day operations.

What DORA demands: The five pillars of digital resilience

DORA is not merely a cybersecurity directive. The regulation encompasses five core areas that together form a comprehensive resilience framework: ICT risk management with a complete governance framework, incident management with an initial reporting deadline of four hours after classification of an incident as major, mandatory resilience testing including Threat-Led Penetration Testing (TLPT) every three years for systemically important institutions, detailed third-party risk management with a Register of Information and exit strategies, and the voluntary exchange of cyber threat intelligence between financial institutions.

Importantly, DORA contains a proportionality principle (Art. 4). Requirements scale according to the size, risk profile and complexity of the respective institution. Smaller investment firms or payment institutions need not meet the same standards as systemically important large banks. For certain smaller institutions, Art. 16 even provides a simplified ICT risk management framework. Not all 22,000 affected entities therefore face identical obligations – the implementation effort varies considerably.

What is decisive for all, however: DORA makes the management board personally responsible (Art. 5). Board members and managing directors must define the ICT risk management strategy, actively accompany its implementation, and demonstrably keep their knowledge of the ICT risk landscape up to date. This is not a compliance obligation that can be delegated to the IT department – it is a leadership responsibility.

The implementation gap: Where do institutions really stand?

A sobering assessment

The numbers speak clearly. Not a single bank surveyed by KPMG (DORA Readiness Survey, 2024/25) had fully met the DORA requirements by the January 2025 deadline. In the insurance sector, market observers report that some firms are only just beginning to address compliance systematically. Five challenges dominate the implementation landscape.

First and foremost is third-party management – by far the biggest construction site, as KPMG and Advisori consistently report. Behind this ranks technological complexity: DORA is, as KPMG puts it, "no paper tiger" – requirements range from network segmentation and encryption standards to backup architecture, overwhelming many legacy landscapes. Third is the skills shortage: specialists who understand both regulatory and technical requirements are scarcely available on the market. Budget constraints compound the problem – DORA projects compete with other regulatory initiatives for finite resources. Finally, institutions cite persistent regulatory ambiguity: some detailed technical standards (RTS/ITS) from the ESAs were long unavailable and must now be implemented under time pressure.

The contract avalanche: 500 to several thousand ICT contracts

In third-party management, the scale of the challenge becomes particularly apparent. DORA requires every financial institution to maintain a complete, up-to-date register of all contracts with ICT third-party providers – the so-called Register of Information. For large institutions and groups, this register encompasses 500 to several thousand contracts. Mid-sized firms typically manage between 100 and 500 contracts, smaller institutions still 10 to 100.

The challenge is less the number of contracts than their fragmentation. Relevant information is scattered across different departments and systems – from procurement to IT to the legal department. Consolidating this data into a single register frequently requires new systems and processes at decentrally organised institutions.

The Register of Information: The March 2026 stress test

Between 9 and 30 March 2026 – that is, precisely these weeks – financial institutions must submit their Register of Information to BaFin for the first time. From there, the data flows to the European Supervisory Authorities (ESAs). This register is far more than a bureaucratic compliance exercise: it gives regulators, for the first time, a system-wide view of ICT dependencies, supports the designation of critical ICT third-party providers, and enables the analysis of concentration risks.

For many institutions, this first submission will be a litmus test. Those who have not yet built a complete register will need to catch up under considerable time pressure – with the risk of incomplete or erroneous submissions that raise questions with supervisors.

Enforcement: From patience to consequences

Supervisory authorities treated 2025 as a transition year – with proportionality but clear expectations. 2026 marks the shift to a significantly sharper approach. BaFin has announced increased examinations and supervisory reviews from this year onwards.

The paradigm shift is clear: DORA compliance is moving from "paperwork to proof". Regulators no longer expect merely documented policies but demonstrable, data-driven resilience – supported by automated monitoring and real-time reporting. Point-in-time compliance, i.e. preparing for the next audit date, is a dying model.

DORA and NIS 2: The regulatory double act

Two frameworks, one direction

In parallel with DORA, the NIS 2 Directive is taking effect. Both regulations pursue the same overarching goal – strengthening cyber resilience in the EU – but do so in different ways and with different scopes. For financial institutions that may fall under both frameworks, the result is a complex compliance landscape requiring strategic management.

Those under DORA follow DORA

The relationship between the two frameworks is legally clear: DORA is the more specific regulation for the financial sector and takes precedence. Where DORA sets specific rules, it displaces the more general NIS 2 requirements. Financial institutions must therefore primarily comply with DORA. This does not mean, however, that NIS 2 is irrelevant – in areas not covered by DORA, NIS 2 requirements apply supplementarily.

A key structural difference: DORA is an EU Regulation and therefore applies directly and uniformly in all Member States. NIS 2, by contrast, is a Directive that must be transposed into national law by each Member State – with the consequence that country-specific variations may arise. The transposition deadline for NIS 2 expired on 18 October 2024; Germany has not yet adopted its NIS 2 Implementation Act (NIS2UmsuCG) – the process was further delayed by the early federal election in 2025. For affected companies, this means a period of legal uncertainty: the EU requirements are set, but the national framework is not yet in place.

Dimension	DORA	NIS 2
Legal form	EU Regulation – directly applicable	EU Directive – national transposition required
Scope	Financial sector: banks, insurers, investment firms, payment service providers, crypto providers, critical ICT providers	18 sectors: energy, transport, health, digital infrastructure, financial sector et al.
In force since	Entered into force 16 January 2023; applicable since 17 January 2025	Transposition deadline: 18 October 2024; Germany: NIS2UmsuCG further delayed by 2025 federal election, adoption expected 2026
Incident Reporting	Initial report within 4 hours of classification, interim report after 72 hours, final report after 1 month	Initial report within 24 hours, follow-up after 72 hours, final report after 1 month
Resilience Testing	Annual baseline tests + Threat-Led Penetration Testing (TLPT) every 3 years for systemically important institutions	Recommends vulnerability analyses and penetration tests – without a mandatory TLPT cycle
Third-Party Risk	Register of Information, detailed contractual clauses, exit strategies, direct supervision of critical ICT providers	General supply chain security, no specific contractual requirements
Sanctions	Up to 2% of global annual turnover; personal liability up to €1 million	Up to €10 million or 2% of turnover; personal liability of management
Supervision	ESAs (EBA, EIOPA, ESMA), national supervisors (BaFin)	National authorities (BSI in Germany), CSIRT, ENISA

The dual compliance trap

For financial institutions falling under both DORA and NIS 2, the challenge lies in their integration. The good news: both frameworks overlap in key areas – risk management, incident reporting, governance obligations and supply chain security. Those who implement DORA rigorously will automatically fulfil a large part of the NIS 2 requirements.

The bad news: "a large part" is not "all". NIS 2 imposes standalone requirements on training obligations, cooperation with national CSIRTs, and areas not explicitly addressed by DORA. Moreover, the reporting deadlines differ significantly: while DORA requires an initial report within four hours, NIS 2 allows a 24-hour window. For institutions that must serve both obligations in parallel, the implication is: those who meet the stricter DORA deadline automatically satisfy NIS 2 as well – but processes must be designed accordingly.

Strategic approach: Consolidation over duplication

The smartest strategy for financial institutions is consolidation. Rather than building two parallel compliance streams, an integrated approach is recommended: a common risk management framework that takes the stricter DORA requirements as the baseline and supplements NIS 2-specific requirements. Incident reporting processes can be consolidated with adjustments for the different deadlines. Governance structures can be harmonised.

This approach not only saves resources but also reduces the risk of contradictory policies – a problem that quickly arises with parallel implementation. The 2026 regulatory wave encompasses DORA and NIS 2 alongside the AI Act and the Cyber Resilience Act. Institutions that build a scalable compliance framework now are better positioned for future regulations.

What the industry is discussing now

Cloud dependency and exit strategies

A concrete example of the operational consequences: DORA requires financial institutions to have exit strategies for critical ICT providers. Those relying on AWS or Azure today must document how an orderly provider switch would work within defined timeframes. Microsoft has already published a practical blueprint for DORA exit planning on Azure SQL Database – an indication that the hyperscalers, too, are taking the regulation seriously.

The financial sector as the number one cyber attack target

The urgency of DORA is underscored by the threat landscape. Robust EU-wide statistics on the sectoral distribution of cyberattacks are scarce; national data, however, provide a consistent picture. In Spain, for instance, the financial sector concentrates 34 per cent of all cyberattacks according to a PROBATIA analysis, with average costs of EUR 5.8 million per incident. While these figures cannot be transferred one-to-one to the German market, they are consistent with the findings of the IBM Cost of a Data Breach Report, which identifies the financial sector globally as one of the most heavily affected industries. The scale illustrates why the EU is not relying on voluntary self-regulation.

The 19 ICT providers designated as critical – including AWS, Microsoft Azure and Google Cloud – have been under direct EU supervision since November 2025. This is a first: for the first time, the EU regulates not only financial institutions themselves but also their technology infrastructure providers directly. For the affected cloud providers, this means considerable compliance investments; for institutions, potentially rising costs – but also a higher level of transparency and resilience across the entire value chain.

Recommendations: What financial institutions should do now

The remaining grace period is over. Institutions that are not yet compliant must act now – in a structured, prioritised manner and with the awareness that supervisors will show no transition-year tolerance in 2026.

Outlook: DORA as a permanent construction site

DORA is not a project with a defined end date. The regulation establishes a continuous compliance cycle that evolves with every new concretisation by the ESAs. The RTS and ITS (Regulatory and Implementing Technical Standards) are being continuously refined; new requirements will follow. At the same time, the AI Act, the Cyber Resilience Act, and the ongoing NIS 2 transposition in Member States are creating an increasingly dense regulatory net.

For financial institutions, this means: those who treat DORA as a one-off compliance project will be permanently running behind. The winners are those institutions that build scalable structures now – integrated risk management platforms, automated reporting chains, living contract registers, and a corporate culture in which digital resilience is understood not as an IT topic but as a core strategic competence.

Fourteen months after application, the balance sheet reads: DORA has set the right framework – a framework more demanding than anything European financial regulation has previously produced in the area of digital resilience. The decisive question is no longer whether the regulation works, but whether the industry understands its implementation as a strategic investment or as a regulatory burden. Those institutions that use DORA to break open outdated structures will emerge more robust from this phase. All others will have to explain, at the latest at the next major ICT incident, why they did not.