DORA for banks: What the EU regulation governs and how it works

Part 1 of 7 of our DORA series for banks. This introduction contextualizes the regulation and explains why digital operational resilience must be organized as a management task. To transition from contextualization to practical outsourcing management, Part 2 refers to the DORA Exit Plan.

Author: acceleraid Editorial Team

DORA is an Operating Model for Digital Resilience

DORA is not just an additional checklist for information security. Regulation (EU) 2022/2554 combines governance, technology, incident reporting, and the management of ICT third-party service providers into a unified framework for digital operational resilience in the financial sector. Therefore, its practical question is not just: "Are our systems protected?" But also: Can the institution detect disruptions, make traceable decisions, continue operations, and effectively manage its service providers? The regulation was signed on December 14, 2022, entered into force on January 16, 2023, and has applied since January 17, 2025. (EUR-Lex, Regulation (EU) 2022/2554)

For bank boards and responsible business areas, this is crucial because DORA does not delegate accountability to IT. Information and communication technology (ICT) risk management must align with business processes, data flows, emergency procedures, and supplier relationships. A good implementation therefore begins with a robust target state: Which services are essential for customers and market infrastructure, which systems and data support them, and who makes decisions in the event of a disruption?

Who the Framework Applies to and Since When

The scope is broad. Article 2 lists 21 categories of financial entities, including credit and payment institutions, trading venues, insurers, credit rating agencies, crypto-asset service providers, and critical ICT third-party service providers. DORA is directly applicable EU law; however, its application should be proportionate to the size, risk profile, as well as the nature, scale, and complexity of the services. (EUR-Lex, Article 2 as well as Articles 3 and 4)

In Germany, the national regulatory context has shifted at the same time. BaFin repealed KAIT, VAIT, and ZAIT effective at the end of January 16, 2025; for institutions with ICT risk management in accordance with DORA, the BAIT exceptions have applied since January 17, 2025. The complete repeal of BAIT is scheduled for the end of December 31, 2026; starting January 1, 2027, the newly drafted Section 1a (2) of the German Banking Act (KWG) will cover additional institutions. (BaFin, Announcement on DORA Implementation)

This is no reason to discard existing controls across the board. It is an opportunity to map them to the DORA logic: risk, accountability, evidence, and recoverability must be consistent across the entire digital service flow.

The Five Pillars as a Management Map

The structure of the regulation can be translated into five interconnected areas of action. First, it requires ICT risk management. Second, it regulates the management and reporting of ICT-related incidents. Third, it demands digital operational resilience testing, including Threat-Led Penetration Testing (TLPT). Fourth, it addresses the management of ICT third-party risk, including the oversight of critical providers. Fifth, it establishes a framework for sharing information on cyber threats. (EUR-Lex, Structure of the DORA Regulation)

The pillars are not an organizational chart. They describe dependencies: an incident process only works if the owners of data and services are known. A resilience test is only meaningful if its results feed back into risk decisions. And an exit strategy for a provider remains just paperwork if contract rights, data formats, and internal capabilities do not align with it.

Reporting Deadlines Require an Experienced Decision-Making Process

For major ICT-related incidents, DORA compresses time. The initial notification must be submitted within four hours after classification and no later than 24 hours after becoming aware of the incident. An intermediate report follows no later than 72 hours after the initial notification; the final report is due within one month. For credit institutions, the weekend and holiday easement contained in the RTS does not apply. (EUR-Lex, Delegated Regulation (EU) 2025/301)

These deadlines are not a reporting issue at the end of a disruption. They require a prepared interplay of detection, classification, escalation, technical assessment, and approval. A practical approach therefore defines an incident owner in advance, a reliable deputy, communication channels to compliance and PR, as well as the evidence that must be available for classification. The question "Who writes the notification?" comes only after that.

In Germany, BaFin is the competent authority. This underlines that complete, consistent, and timely information has not only operational but also supervisory relevance.

Testing Means More Than Just Controlling

DORA does not just require prevention, but verifiable resilience. For selected financial entities, Article 26 mandates TLPT at least every three years and explicitly on live production systems. Which tests are appropriate in each individual case follows from risk and proportionality; what matters is whether the institution derives concrete improvements from the results. (EUR-Lex, Article 26 DORA)

This also affects external dependencies. If a cloud, software, or data provider fails, it must be clear which function is affected, which data must be moved, and which alternative is actually available. Part 2 of this series dives deeper into why an exit plan must not only be documented but tested. Part 7 provides the classification logic for critical or important functions.

Third-Party Risk Begins Before the Contract

DORA shifts the focus from the purchasing decision to ongoing management. For ICT services supporting critical or important functions, Article 28 requires exit strategies, alternative solutions, and transition plans. Article 30 adds contractual requirements, including performance and data processing locations, the return of data in an easily accessible format, and termination rights. (EUR-Lex, Articles 28 and 30 DORA)

This is particularly relevant when customer, transaction, or model information flows across multiple technical layers. The register of information from Part 5 of the series thus becomes more than just a reporting list: it makes dependencies, contracts, and data flows auditable. A practical approach to this is described in the article on the DORA register of information as a data quality issue.

Furthermore, for critical ICT third-party service providers, DORA provides for a daily penalty payment of up to one percent of the average daily worldwide turnover of the preceding business year, limited to a maximum of six months and with a 30-calendar-day notice period. For financial entities, however, the consequences of weak service provider management remain primarily operational: lack of ability to act, poor auditability, and recovery under time pressure. (EUR-Lex, Article 35 DORA)

A Pragmatic Starting Point for Banks

An effective DORA program can be set up as a recurring management cycle. First, services, data, and owners are mapped. Second, risk scenarios and reporting pathways are tested against real business processes. Third, contracts, subcontractor chains, and exit options are checked against these scenarios. Fourth, the results feed back into priorities, budgets, and the work of management.

In doing so, international comparison should not be confused with equivalence. DORA is an EU regulation; a banking group with operations in Switzerland or the United Kingdom additionally needs an independent review of the respective local regulatory requirements.

Brief Comparison: Switzerland and the United Kingdom

The FINMA Circular 2023/1 explicitly mentions a prolonged outage due to the bankruptcy of an important service provider as an example of a stressed exit under the severe, plausible scenarios to be tested regularly. For groups with a Swiss presence, this is a clear indication to think of exit scenarios not just contractually, but operationally. (FINMA Circular 2023/1)

In the United Kingdom, the Critical Third Parties regime in Policy Statement PS16/24 addresses the operational resilience of critical third parties in the financial sector. The regimes are not identical; however, for internationally active banks, the common practical lesson is: dependencies, supply chains, and the orderly transition after termination must be clear before an emergency occurs. (Bank of England, PS16/24)

As a management principle, however, what DORA makes concrete remains transferable: make digital dependencies transparent, define accountability, and do not invent recovery only when an emergency hits.

The strength of DORA therefore does not lie in a single control. It lies in linking risk, testing, contracting, and decision-making capability. Those who establish this link gain not only better auditability but also a more resilient digital operating model.

The DORA Series at a Glance

• Part 1: DORA for Banks: What the EU regulation governs and how it works (this article)

• Part 2: The Exit Plan under DORA: What it must contain and why it must be tested

• Part 3: Cloud Dependency of European Banks: How to get away from AWS, Microsoft, and Google if necessary

• Part 4: Exit Option for Customer Engagement Workloads: Securing CDP, personalization, and campaigns in compliance with DORA

• Part 5: The DORA Register of Information: Why it is actually a data quality issue

• Part 6: AI Providers as a New Concentration Risk: What DORA means for model dependencies

• Part 7: Critical or Important? Risk levels from core banking to CRM, data lake, and CDP

Illustration: AI-generated. AI-supported content: In creating our articles, we use AI technologies and automated agents, including those from Microsoft, Google, OpenAI, Anthropic, and other providers. Topics, professional direction, and final approval remain with our team.