Credit transfers, securities clearing, insurance underwriting, lending: financial operations are now entirely digital. This reliance on information systems exposes banks, insurers, investment firms and payment providers to new risks, where an outage or a cyberattack can halt business overnight. In response, the European Union adopted DORA, the regulation on digital operational resilience for the financial sector.
The regulation goes beyond cybersecurity. It makes the management body responsible for ICT risk, harmonises incident reporting, requires regular testing and sets rules for the use of technology providers.
This article covers the scope of the regulation, its six pillars and its implementing texts.
1. DORA: a regulation for the digital resilience of finance
1.1. Key facts
Regulation (EU) 2022/2554, the Digital Operational Resilience Act (DORA) of 14 December 2022, has applied since 17 January 2025 in all EU Member States, with no need for national transposition. It is accompanied by Directive (EU) 2022/2556, which brings eight sectoral directives into line with it.
The NIS 2 Directive, the EU’s general cybersecurity framework, gives way to sector-specific legislation that imposes requirements of at least equivalent effect. DORA meets this condition for financial entities: ICT risk management, incident reporting and supervision are governed by its rules.
NIS 2 nonetheless keeps a residual role. It still applies to financial sector entities outside DORA’s scope, and to obligations that DORA does not cover.
1.2. Why the European Union adopted it
In the digital age, financial entities have become highly interconnected and heavily dependent on information and communication technologies (ICT). As a result, an incident at any one of the EU’s roughly 22,000 financial entities can easily spread to others and affect the entire banking, financial and insurance sector. Before DORA, rules on incidents, testing and providers varied from one country to another. The aim is therefore to harmonise the applicable rules across the EU for this sector.
2. Who does DORA apply to?
2.1. The 20 categories of financial entities
The regulation lists twenty categories of financial entities, from retail banks to insurance brokers.
| Area | Entities covered |
|---|---|
| Banking and payments | credit institutions; payment institutions; account information service providers; electronic money institutions |
| Markets and investment | investment firms; crypto-asset service providers and issuers of asset-referenced tokens; central securities depositories; central counterparties; trading venues; trade repositories; alternative investment fund managers; management companies; data reporting service providers |
| Insurance and pensions | insurance and reinsurance undertakings; insurance, reinsurance and ancillary insurance intermediaries; institutions for occupational retirement provision |
| Other players | credit rating agencies; administrators of critical benchmarks; crowdfunding service providers; securitisation repositories |
2.2. ICT third-party service providers
A twenty-first category completes the list: ICT third-party service providers, which supply digital and data services on an ongoing basis. Examples include a data centre host, a cloud computing provider or the vendor of an institution’s core banking software.
2.3. Exclusions and proportionality
DORA excludes certain entities from its scope. These include institutions for occupational retirement provision with no more than fifteen members, and small insurance intermediaries.
For everyone else, requirements are scaled to size and risk profile. A brokerage firm with five employees, classed as a microenterprise, falls under a lighter regime, while a systemically important bank applies the full set of requirements laid down by the regulation.
3. The six pillars of DORA
3.1. ICT risk management
The management body bears ultimate responsibility: it approves the resilience strategy, allocates the budget and receives regular training. The risk management framework is documented and reviewed at least once a year. It relies on an independent control function and on business continuity, backup and recovery plans.
3.2. Incident management and reporting
Incidents are logged and then classified against six criteria: clients affected, duration, geographical spread, data losses, criticality of services and economic impact. An outage of a few hours in the credit transfer service that prevents thousands of clients from making payments would be classified as a major incident. It must then be reported to the competent authority in three stages: initial notification, intermediate report and final report.
3.3. Resilience testing
Systems that support critical functions are tested at least once a year: vulnerability assessments, performance testing and end-to-end testing. Entities designated by the authorities must also carry out threat-led penetration testing (TLPT) at least every three years. TLPT replicates the methods of real attackers on live production systems.
3.4. Third-party risk management
Each entity keeps a register of all its arrangements with ICT providers and, before signing any contract, checks the safeguards on offer. It assesses concentration risk: hosting critical applications with the same cloud provider as the rest of the market creates a dependency that regulators monitor. The entity remains responsible for complying with DORA, even when it outsources.
3.5. Oversight of critical providers
The European Supervisory Authorities designate the providers deemed critical to the financial system, such as a major cloud service provider. A Lead Overseer, chosen from among the European Banking Authority (EBA), the European Insurance and Occupational Pensions Authority (EIOPA) and the European Securities and Markets Authority (ESMA), can investigate, carry out on-site inspections and issue recommendations.
3.6. Information sharing
The regulation encourages entities to share cyber threat intelligence on a voluntary basis, in line with competition law and the GDPR.
4. A three-level regulatory framework
The regulation and the amending directive make up level 1.
Regulatory technical standards (RTS) and implementing technical standards (ITS) make up level 2. They specify:
- the ICT risk management framework (RTS 2024/1774);
- incident classification and incident reporting (RTS 2024/1772 and 2025/301, ITS 2025/302);
- threat-led penetration testing (RTS 2025/1190);
- ICT providers and subcontracting (RTS 2024/1773 and 2025/532);
- the register of information (ITS 2024/2956).
Level 3 covers guidelines from the European Supervisory Authorities, including on estimating the costs and losses of major incidents.
5. DORA and AI: three points to watch
DORA does not mention artificial intelligence, but its definitions cover any AI system that supports a financial entity, such as a credit scoring engine or a fraud detection tool. Its interplay with the AI Act raises three issues:
- Contracts: an AI provider is an ICT provider like any other. It must be added to the register and covered by appropriate contractual terms.
- Incidents: the same malfunction can fall under both DORA and the AI Act, with different authorities and deadlines.
- Testing: AI systems that support critical functions fall within the testing programme.
Conclusion: digital resilience as a governance obligation
DORA turns digital resilience into a governance obligation, from senior management to providers. For financial entities and their suppliers alike, the challenge is to map their digital dependencies and be able to demonstrate control of their ICT risk at any time.
How do you structure the governance of your AI systems?
For organisations that use artificial intelligence, the first step is knowing which systems and which providers they rely on, and which rules apply to each.
With Naaia, organisations identify their AI systems and use cases, document their assessments and track their compliance actions. By centralising system mapping, obligation management and decision traceability, Naaia helps move from fragmented compliance to operational AI governance.
Move from reactive AI governance to governance you control.