The Digital Operational Resilience Act — known as DORA — is one of the most significant pieces of EU financial regulation to come into force in recent years. If you work in banking, insurance, payments, investment management, or any part of the financial sector, DORA directly affects how your organisation manages technology risk.
This guide explains what DORA is, who it applies to, what it requires, and how to approach compliance — without the jargon.
What is DORA?
DORA (Regulation (EU) 2022/2554) is a European Union regulation that sets uniform requirements for the security of network and information systems across the financial sector. It was adopted by the European Parliament and Council on 14 December 2022 and became fully applicable on 17 January 2025.
The regulation exists because the financial sector has become deeply dependent on technology. Cloud services, payment platforms, trading systems, and data analytics — all run on ICT infrastructure that, if disrupted, can threaten financial stability across borders.
Before DORA, ICT risk management in the financial sector was governed by a patchwork of national rules, EBA guidelines, and sector-specific directives. The requirements were inconsistent, and many focused on capital buffers rather than operational resilience. DORA replaces this fragmented approach with a single, harmonised framework that applies directly across all EU member states.
The core idea is simple: financial entities must be able to withstand, respond to, and recover from all types of ICT-related disruptions and threats.
Why was DORA introduced?
The case for DORA was built on three realities:
Growing ICT dependency. Modern financial services run almost entirely on digital infrastructure. A single point of failure in a cloud provider, payment processor, or data centre can cascade across multiple institutions and markets. Rising cyber threats. Cyberattacks on financial institutions have increased dramatically in both frequency and sophistication. Ransomware, supply chain attacks, and state-sponsored threats have all hit the sector hard. Regulatory fragmentation. Before DORA, each member state had its own approach to ICT risk in financial services. This made cross-border supervision difficult and allowed gaps in oversight — particularly around third-party ICT providers who served multiple institutions across multiple jurisdictions.DORA addresses all three by creating a single regulatory framework that covers ICT risk management, incident reporting, resilience testing, and third-party risk oversight.
Who must comply with DORA?
DORA casts a wide net. Article 2 defines 21 categories of financial entities that fall within scope:
- Credit institutions (banks)
- Payment institutions
- Account information service providers
- Electronic money institutions
- Investment firms
- Crypto-asset service providers (under MiCA)
- Central securities depositories
- Central counterparties
- Trading venues
- Trade repositories
- Managers of alternative investment funds (AIFMs)
- Management companies (UCITS)
- Data reporting service providers
- Insurance and reinsurance undertakings
- Insurance intermediaries, reinsurance intermediaries, and ancillary insurance intermediaries
- Institutions for occupational retirement provision (IORPs)
- Credit rating agencies
- Administrators of critical benchmarks
- Crowdfunding service providers
- Securitisation repositories
- ICT third-party service providers
That last category is particularly significant. DORA doesn't just regulate financial institutions — it also brings ICT service providers (cloud providers, software vendors, data centres) into scope. Critical ICT third-party providers (CTPPs) face direct oversight from the European Supervisory Authorities.
Who is exempt?
A few narrow exemptions exist under Article 2(3):
- Very small AIF managers exempt under the AIFMD
- Insurance and reinsurance undertakings exempt under Solvency II
- IORPs with pension schemes of 15 members or fewer
- Persons exempt under MiFID II Articles 2 and 3
- Insurance intermediaries that are micro or small enterprises
- Post office giro institutions
For everyone else: if you're a regulated financial entity in the EU, DORA applies to you. And the regulation explicitly states it applies proportionally — so smaller entities face lighter requirements, but they cannot ignore the regulation entirely.
Does DORA apply outside the EU?
DORA is an EU regulation, but its reach extends beyond EU borders. Any ICT service provider — regardless of where it is headquartered — that serves EU financial entities will face contractual requirements driven by DORA. If a US cloud provider or a UK software vendor supports a critical function for an EU bank, that bank must ensure the provider meets DORA's standards.
The four pillars of DORA
DORA is structured around four main pillars (plus a fifth on information sharing). Together, they cover the full lifecycle of ICT risk management.
Pillar 1: ICT Risk Management (Articles 5–16)
This is the foundation. Financial entities must establish and maintain a comprehensive ICT risk management framework that covers identification, protection, detection, response, and recovery.
Key requirements include:
- Governance: The management body (board) bears ultimate responsibility for ICT risk. They must approve the ICT risk management framework, oversee its implementation, and stay informed about ICT risks.
- ICT Risk Management Framework: A documented framework covering strategies, policies, procedures, and tools for managing ICT risk. It must be audited regularly and follow the Three Lines of Defence model.
- Asset management: Financial entities must identify and classify all ICT assets, map dependencies between business functions and ICT systems, and maintain up-to-date inventories.
- Business continuity: Comprehensive backup policies, recovery procedures, and business impact analyses must be in place and regularly tested.
- Crisis communication: Plans for communicating with internal and external stakeholders during ICT incidents.
Smaller entities qualifying under Article 16 can follow a simplified ICT risk management framework — a lighter version of the full requirements.
Pillar 2: ICT Incident Reporting (Articles 17–23)
Financial entities must establish processes to detect, classify, and report ICT-related incidents.
Key requirements include:
- Classification: Incidents must be classified according to criteria set out in the regulation — including the number of clients affected, duration, geographical spread, data losses, and impact on critical functions.
- Reporting: Major ICT-related incidents must be reported to the relevant national competent authority (NCA) using a structured three-stage process: initial notification, intermediate report, and final report.
- Voluntary notification: Entities may also voluntarily notify significant cyber threats to their competent authority.
- Client notification: When a major incident impacts clients' financial interests, entities must inform them without undue delay.
The reporting timelines and templates are defined in Commission Delegated Regulation (EU) 2025/301 and Implementing Regulation (EU) 2025/302.
Pillar 3: Digital Operational Resilience Testing (Articles 24–27)
All financial entities must conduct regular testing of their ICT systems. The scope and frequency depend on the entity's size and risk profile.
Key requirements include:
- Basic testing: All entities must conduct regular vulnerability assessments, open-source software analyses, network security assessments, and gap analyses.
- Advanced testing (TLPT): Significant financial entities (identified by their NCA) must conduct Threat-Led Penetration Testing at least every three years. These tests simulate real-world attacks against live production systems and must follow the TIBER-EU framework.
- Testers: TLPT must be carried out by qualified, independent testers. Internal testers may be used in certain circumstances, but an external tester must be involved.
- Remediation: Findings from all testing activities must be addressed through documented remediation plans.
Pillar 4: ICT Third-Party Risk Management (Articles 28–44)
This is widely regarded as DORA's most transformative requirement. Financial entities must manage the risks arising from their use of third-party ICT service providers.
Key requirements include:
- Third-party risk strategy: Entities must adopt a strategy on ICT third-party risk, including a policy on the use of services supporting critical or important functions.
- Due diligence: Before entering into contracts, entities must assess the provider's security posture, regulatory compliance, and operational resilience.
- Contractual requirements: Article 30 sets out mandatory contractual provisions that must be included in agreements with ICT providers — covering service levels, audit rights, exit strategies, and data location.
- Concentration risk: Entities must assess and manage concentration risk — the danger of over-reliance on a single ICT provider or a small group of providers.
- Register of Information: Under Article 28(3), entities must maintain a register of all contractual arrangements with ICT third-party providers. This Register of Information (RoI) must be submitted to NCAs annually, and NCAs forward it to the ESAs.
- CTPP oversight: The ESAs can designate certain ICT providers as Critical Third-Party Providers (CTPPs), subjecting them to direct oversight by a Lead Overseer.
Pillar 5: Information Sharing (Article 45)
DORA encourages (but does not mandate) financial entities to share cyber threat intelligence and vulnerability information with each other. This collaborative approach aims to strengthen collective resilience across the sector.
| Date | Milestone |
|---|---|
| 14 December 2022 | DORA adopted by EU Parliament and Council |
| 16 January 2023 | DORA enters into force |
| 17 January 2024 | First batch of RTS/ITS technical standards finalised |
| 17 July 2024 | Second batch of technical standards published |
| 17 January 2025 | DORA becomes fully applicable — enforcement begins |
| Q1 2025 | First Register of Information (RoI) submissions to NCAs |
| January 2026 | European Commission review of DORA (Article 58) |
| Q1 2026 | Second annual RoI submissions — regulators expect more mature data |
DORA is already in force and being enforced. There is no further transition period.
Penalties for non-compliance
DORA's enforcement mechanisms are significant:
- Financial entities face fines of up to 2% of total worldwide annual turnover for breaches. For large institutions, this can mean tens of millions of euros.
- Critical third-party providers face fines of up to €5,000,000.
- Daily penalties of up to 1% of average daily turnover can be imposed for each day of continuing non-compliance, for up to six months.
- Beyond fines, competent authorities can issue binding orders, restrict business activities, and in severe cases suspend or revoke authorisations.
The penalties are set at the member state level, but the regulation provides the framework and maximum thresholds.
How DORA relates to other regulations
DORA does not exist in isolation. It intersects with several other EU frameworks:
- NIS2 Directive: DORA is considered lex specialis to NIS2 — it takes precedence for financial entities. However, financial entities remain part of the NIS2 ecosystem for information sharing and cooperation.
- GDPR: Data protection obligations continue to apply alongside DORA. Incident reporting under DORA and GDPR may overlap but serve different regulatory purposes.
- ISO 27001 / ISO 27005: DORA's risk management requirements align closely with ISO 27005 methodology. Organisations with existing ISO certifications will find significant overlap.
- EBA/EIOPA Guidelines: Previous ICT risk management guidelines from the ESAs have been updated to align with DORA. The EBA published amended guidelines in February 2025.
Getting started with DORA compliance
For organisations beginning their DORA compliance journey, the following steps provide a practical starting point:
1. Determine your scope. Confirm whether your organisation falls within DORA's 21 entity categories. Identify which proportionality exemptions may apply. 2. Gap analysis. Assess your current ICT risk management practices against DORA's requirements — particularly Articles 5–16 on governance and risk management. 3. Build your Register of Information. Start documenting all contractual arrangements with ICT third-party providers. This is one of the first deliverables regulators will ask for. 4. Review contracts. Ensure your agreements with ICT providers include the mandatory contractual provisions required by Article 30. 5. Establish incident reporting. Implement classification criteria and reporting workflows aligned with the regulatory technical standards. 6. Plan your testing programme. Determine what testing is required for your risk profile and begin scheduling vulnerability assessments and, if applicable, TLPT. 7. Engage your board. DORA places explicit responsibility on the management body. Ensure your board understands their obligations and receives regular reporting on ICT risk.Conclusion
DORA represents a fundamental shift in how the EU regulates technology risk in financial services. It moves beyond capital-based approaches to demand genuine operational resilience — the ability to absorb shocks, adapt, and continue delivering services.
For financial entities, the message is clear: ICT risk management is no longer just an IT concern. It's a board-level responsibility, a regulatory obligation, and increasingly, a competitive differentiator.
The organisations that treat DORA as an opportunity to strengthen their foundations — rather than a box-ticking exercise — will be better positioned for whatever disruptions come next.