A practical legal guide to the Digital Operational Resilience Act (Regulation (EU) 2022/2554)
DORA, the Digital Operational Resilience Act, is an EU regulation that entered into application on 17 January 2025. It establishes a binding framework for digital operational resilience across the EU financial sector, covering ICT risk management, incident reporting, operational resilience testing, third-party risk management, and information sharing.
DORA applies directly to banks, insurers, investment firms, payment institutions, and a wide range of other financial entities operating in the EU. It also imposes obligations on critical ICT third-party service providers, including cloud providers and data analytics firms that serve the financial sector.
For UK businesses, DORA is not a domestic law. However, it applies to UK-based financial entities operating in the EU and to UK technology companies providing services to EU-regulated financial institutions. Understanding DORA is a commercial necessity for any UK business with EU financial sector exposure.
This guide explains what DORA regulation is, who it applies to, what it requires, how it differs from a directive, and what the penalties are for non-compliance. For quick DORA documentation guidance, visit our DORA templates page.
Key DORA Definitions
| Term | Definition | Legal basis |
|---|---|---|
| Digital operational resilience | The ability of a financial entity to build, assure, and review its operational integrity and reliability by ensuring, directly or indirectly through the use of services provided by ICT third-party service providers, the full range of ICT-related capabilities needed to address the security of network and information systems | Article 3(1) |
| ICT risk | Any reasonably identifiable circumstance relating to the use of network and information systems which, if materialised, may compromise the security of network and information systems, technology-dependent tools, operations, processes, or the provision of services | Article 3(5) |
| ICT-related incident | An unplanned event or series of linked events that compromises the security of network and information systems, and has an adverse impact on the availability, authenticity, integrity, or confidentiality of data or on services provided by the financial entity | Article 3(8) |
| Major ICT-related incident | An ICT-related incident that has a high adverse impact on network and information systems that support critical or important functions of the financial entity | Article 3(10) |
| ICT third-party service provider | An undertaking providing digital and data services, including cloud computing services, software, data analytics, data centres, and other ICT services to financial entities | Article 3(19) |
| Critical ICT third-party service provider (CTPP) | An ICT third-party service provider designated as critical by the European Supervisory Authorities based on systemic importance to the financial sector | Articles 31-44 |
| Operational resilience testing | Structured testing of the ICT systems and tools of financial entities, including threat-led penetration testing (TLPT) | Articles 24-27 |
| TLPT | Threat-led penetration testing. Advanced testing methodology using real-world attack scenarios for significant financial entities | Article 26 |
What Is DORA Regulation
DORA, formally Regulation (EU) 2022/2554 on digital operational resilience for the financial sector, is a directly applicable EU regulation. It was adopted on 14 December 2022, published in the Official Journal on 27 December 2022, and entered into application on 17 January 2025 following a two-year implementation period.
DORA addresses a structural vulnerability in the EU financial system: the deep dependence of financial institutions on ICT systems and third-party technology providers. Before DORA, ICT risk management requirements for financial entities were fragmented across multiple sector-specific instruments and national laws, creating inconsistency and gaps that regulators identified as a systemic risk.
DORA consolidates ICT risk requirements into a single, horizontally applicable regulation covering the entire EU financial sector. It creates uniform standards for how financial entities must manage ICT risk, report incidents, test resilience, oversee third-party providers, and share information about cyber threats.
Is DORA a Regulation or a Directive?
DORA is a regulation, not a directive. This distinction matters practically.
An EU directive sets objectives that member states must achieve but leaves the method of implementation to national law. Each member state transposes a directive differently, creating variation across the EU.
A regulation is directly applicable in all EU member states without national transposition. DORA applies in identical terms across all 27 EU member states from 17 January 2025. There is no UK version, no German version, no French version. The text is the same everywhere.
For businesses operating across multiple EU member states, this means a single DORA compliance programme applies uniformly. There is no need to assess national variations in implementation.
Who Does DORA Regulation Apply To?
DORA applies to a wide range of financial entities and ICT third-party service providers. Article 2(1) lists the entities in scope explicitly.
Financial Entities in Scope
| Entity type | Examples |
|---|---|
| Credit institutions | Banks, building societies, mortgage lenders |
| Payment institutions | Payment service providers, money transfer businesses |
| Electronic money institutions | E-money issuers |
| Investment firms | Brokers, dealers, portfolio managers |
| Crypto-asset service providers | Cryptocurrency exchanges, custodians regulated under MiCA |
| Central securities depositories | Post-trade infrastructure |
| Central counterparties | Clearing houses |
| Trading venues | Stock exchanges, multilateral trading facilities |
| Trade repositories | Derivatives data repositories |
| Managers of alternative investment funds | Hedge funds, private equity fund managers |
| Management companies | UCITS management companies |
| Insurance and reinsurance undertakings | Insurers and reinsurers |
| Insurance intermediaries | Brokers, agents, tied intermediaries above threshold |
| Institutions for occupational retirement provision | Pension funds above threshold |
| Credit rating agencies | Rating agencies |
| Statutory auditors and audit firms | Auditors of regulated financial entities |
| Administrators of critical benchmarks | LIBOR successors, financial benchmark administrators |
| Crowdfunding service providers | Investment and lending crowdfunding platforms |
| Securitisation repositories | Structured finance data repositories |
| Data reporting services providers | Approved reporting mechanisms, trade data monitors |
Proportionality: Microenterprises
Article 4 introduces a proportionality principle. Microenterprises, defined as entities with fewer than 10 employees and annual turnover or balance sheet not exceeding €2 million, benefit from simplified requirements in several areas. However, microenterprises are not exempt from DORA entirely. Core obligations including ICT risk management, incident reporting, and third-party risk management still apply.
ICT Third-Party Service Providers
DORA imposes direct obligations on ICT third-party service providers that are designated as critical under Article 31. Critical designation is determined by the Joint Committee of the European Supervisory Authorities (EBA, ESMA, and EIOPA) based on the systemic importance of the provider to the financial sector.
Designated critical ICT third-party service providers are subject to direct oversight by a Lead Overseer drawn from the three ESAs, including the right to conduct inspections, request information, and issue recommendations.
Non-critical ICT third-party service providers are not directly subject to DORA, but financial entities must impose contractual requirements on all their ICT third-party providers that bring those providers’ practices into alignment with DORA standards.
DORA Regulation and the UK
DORA is not a UK domestic law. It was not retained in UK law following Brexit in the way that some EU financial services instruments were. UK-regulated financial entities operating solely in the UK are not subject to DORA on the basis of UK regulation.
However, DORA applies to UK businesses in two circumstances.
First, UK financial entities that are authorised or registered in an EU member state, or that provide regulated financial services into the EU under passporting arrangements, are subject to DORA in relation to those EU activities. A UK bank with a Frankfurt branch, a UK insurer with an Irish subsidiary, or a UK investment firm passporting into EU markets must comply with DORA for those operations.
Second, UK technology companies providing ICT services to EU-regulated financial institutions must meet the contractual requirements that DORA imposes on financial entities’ third-party arrangements.
If a UK cloud provider, data analytics firm, or software company serves EU banks or insurers, its contracts with those clients must meet DORA’s third-party contract requirements, and it may be subject to audit and information requests from those clients under their DORA obligations.
The UK’s own operational resilience framework, built on the PRA and FCA’s operational resilience policies and the Bank of England’s systemic risk guidance, shares objectives with DORA but is not equivalent to it. UK firms with both UK and EU regulated operations must satisfy both frameworks independently.
The Five Pillars of DORA
DORA organises its requirements into five substantive areas.
Pillar 1: ICT Risk Management
Articles 5 to 16 set out the ICT risk management framework. Financial entities must establish a comprehensive ICT risk management framework as part of their overall risk management system.
| ICT risk management requirement | What is required | Legal basis |
|---|---|---|
| Governance and organisation | Management body accountable for ICT risk. Define roles and responsibilities. Approve ICT risk management framework | Article 5 |
| ICT risk management framework | Establish, implement, and maintain a documented ICT risk management framework covering all ICT assets and risks | Article 6 |
| ICT asset identification | Maintain an inventory of all ICT assets including hardware, software, data, and third-party services | Article 8 |
| Threat and vulnerability identification | Continuously identify and assess threats and vulnerabilities to ICT systems | Article 9 |
| Protection and prevention | Implement appropriate controls to protect ICT systems, including access controls, encryption, and change management | Article 9 |
| Detection | Implement mechanisms to detect anomalous activity, incidents, and threats in a timely manner | Article 10 |
| Response and recovery | Establish business continuity and disaster recovery plans. Define recovery time objectives and recovery point objectives | Articles 11-12 |
| Backup and restoration | Implement backup policies and restoration procedures. Test backups regularly | Article 12 |
| Learning and evolving | Incorporate lessons from ICT incidents and third-party audits into the ICT risk management framework | Article 13 |
| Communication | Develop ICT risk communication strategies for internal and external stakeholders | Article 14 |
Pillar 2: ICT-Related Incident Reporting
Articles 17 to 23 establish mandatory incident classification and reporting requirements.
Financial entities must classify all ICT-related incidents and report major ICT-related incidents to their competent authority within prescribed timeframes.
| Report type | Timeframe | Content |
|---|---|---|
| Initial notification | Within 4 hours of classification as major, and no later than 24 hours after becoming aware | Initial notification of the incident, its classification, and initial assessment |
| Intermediate report | Within 72 hours of initial notification | Updated information on the incident, its impact, and containment measures taken |
| Final report | Within one month of submission of intermediate report | Root cause analysis, impact assessment, mitigation measures, and lessons learned |
The classification of an incident as major is determined by criteria set out in Commission Delegated Regulation (EU) 2024/1772, including the number of clients affected, the duration of the incident, the geographic spread, the data losses involved, and the criticality of the services affected.
Financial entities must also report significant cyber threats to their competent authority on a voluntary basis where the threat could have affected the financial system.
| Incident classification | Reporting obligation |
|---|---|
| Major ICT-related incident | Mandatory report to competent authority within prescribed timeframes |
| Significant cyber threat | Voluntary notification to competent authority |
| Other ICT-related incidents | Internal logging and management. No mandatory external reporting |
Pillar 3: Digital Operational Resilience Testing
Articles 24 to 27 require financial entities to conduct regular testing of their ICT systems and tools.
| Testing requirement | Who it applies to | Frequency | Legal basis |
|---|---|---|---|
| Basic resilience testing | All financial entities | At least annually | Article 25 |
| Vulnerability assessments | All financial entities | Regularly, and after significant changes | Article 25 |
| Network security assessments | All financial entities | Regularly | Article 25 |
| Gap analyses | All financial entities | Regularly | Article 25 |
| Threat-led penetration testing (TLPT) | Significant financial entities designated by competent authorities | At least every 3 years | Article 26 |
TLPT is the most demanding testing requirement. It involves using real-world threat intelligence to design and execute controlled attacks on the live production systems of financial entities. The testing must be conducted by certified internal or external testers and validated by the competent authority.
Article 26(5) introduces a mutual recognition mechanism for TLPT. Where a financial entity has completed TLPT in accordance with DORA standards, other EU financial entities or authorities may recognise that testing result, avoiding duplication where multiple regulated entities share the same critical systems.
Pillar 4: ICT Third-Party Risk Management
Articles 28 to 44 establish requirements for managing ICT third-party risk. This pillar has the most direct commercial impact on technology companies serving the financial sector.
Financial entity obligations:
| Obligation | What is required | Legal basis |
|---|---|---|
| Third-party risk management policy | Establish a policy for managing ICT third-party risk as part of the ICT risk management framework | Article 28(2) |
| Register of arrangements | Maintain a register of all contractual arrangements with ICT third-party service providers | Article 28(3) |
| Pre-contract due diligence | Assess the security practices, resilience capabilities, and financial stability of providers before contracting | Article 28(4) |
| Concentration risk assessment | Assess and manage the risk of excessive concentration of ICT third-party dependencies | Article 29 |
| Mandatory contractual provisions | Include specified provisions in all contracts with ICT third-party service providers | Article 30 |
| Exit strategies | Develop and maintain exit strategies for critical or important functions supported by third parties | Article 28(8) |
Mandatory contractual provisions under Article 30:
Every contract between a financial entity and an ICT third-party service provider covering a critical or important function must include:
| Contractual provision | What must be included |
|---|---|
| Service description | Clear description of all functions and services to be provided |
| Locations | Locations where services are provided and where data is processed and stored |
| Data provisions | Provisions on data availability, authenticity, integrity, and confidentiality |
| Service levels | Quantified targets for availability, performance, and response times |
| Assistance on incidents | Obligation of the provider to assist with incident response |
| Cooperation with authorities | Obligation to cooperate with competent authorities and auditors |
| Termination rights | Termination rights including minimum notice periods |
| Audit rights | Right of the financial entity and its competent authority to audit the provider |
| Sub-outsourcing conditions | Conditions under which sub-outsourcing is permitted |
| Exit assistance | Obligation to assist with transition on termination |
Critical ICT third-party service provider oversight:
Providers designated as critical under Article 31 are subject to direct oversight by a Lead Overseer. The Lead Overseer may conduct document requests, interviews, inspections, and on-site visits. It may issue recommendations on remediation of identified risks. Fines for critical providers that fail to comply with oversight requirements can reach up to 1% of average daily worldwide turnover.
Pillar 5: Information and Intelligence Sharing
Article 45 creates a voluntary framework for financial entities to share cyber threat information and intelligence with each other through trusted arrangements. Participation is voluntary but encouraged by the regulation as a mechanism for strengthening collective resilience across the financial system.
Information shared under Article 45 arrangements is protected from use in regulatory proceedings against the sharing entity, subject to conditions. Arrangements must comply with applicable data protection law.
DORA and the EU AI Act: Intersection for Financial Sector AI
Financial entities using AI systems in critical or important functions face obligations under both DORA and the EU AI Act. The two frameworks interact in several important areas.
| Area of intersection | DORA requirement | AI Act requirement |
|---|---|---|
| ICT risk management | AI systems must be included in the ICT risk management framework under Article 6 | High-risk AI systems require a risk management system under Article 9 |
| Incident reporting | AI system failures affecting critical functions may constitute major ICT-related incidents reportable under Article 19 | Serious incidents involving high-risk AI systems must be reported under Article 73 |
| Third-party risk | AI models provided by third parties must be subject to DORA third-party risk management under Article 28 | GPAI models used in financial services require downstream provider obligations under Article 53 |
| Testing | AI systems in critical functions must be included in resilience testing under Article 24 | Human oversight and accuracy testing requirements apply to high-risk AI systems under Articles 14-15 |
| Documentation | AI systems must be documented as ICT assets under Article 8 | Technical documentation under Annex IV is required for high-risk AI systems |
A fraud detection AI system used by a bank is likely to be both within scope of DORA as an ICT system supporting a critical function and within scope of the EU AI Act as a high-risk AI system under Annex III. Both sets of requirements must be satisfied independently and simultaneously.
DORA Regulation Penalties
DORA does not set a Union-wide maximum fine in the way the EU AI Act does. It requires competent authorities to have the power to impose administrative penalties and remedial measures that are effective, proportionate, and dissuasive, but leaves the specific penalty levels to member state implementation.
| Infringement category | Penalty |
|---|---|
| Failure to comply with ICT risk management requirements | Administrative penalty set by member state. Must be effective, proportionate, and dissuasive |
| Failure to report major ICT-related incidents | Administrative penalty set by member state |
| Failure to comply with testing requirements | Administrative penalty set by member state |
| Failure to comply with third-party risk management requirements | Administrative penalty set by member state |
| Critical ICT third-party provider: failure to comply with oversight | Up to 1% of average daily worldwide turnover. Periodic penalty payments possible |
| Critical ICT third-party provider: failure to remedy identified risk | Periodic penalty payments of up to 1% of average daily worldwide turnover per day for up to six months |
DORA Compliance Checklist
| Area | Key actions | Status |
|---|---|---|
| Governance | Assign management body accountability for ICT risk. Define ICT risk roles and responsibilities | ☐ |
| ICT risk framework | Establish documented ICT risk management framework. Conduct ICT asset inventory | ☐ |
| Business continuity | Define RTOs and RPOs. Document and test BCP and DRP | ☐ |
| Incident classification | Implement incident classification methodology aligned with DORA criteria | ☐ |
| Incident reporting | Establish reporting procedures with 4-hour, 72-hour, and 1-month reporting tracks | ☐ |
| Resilience testing | Implement annual testing programme. Assess TLPT applicability | ☐ |
| Third-party register | Maintain register of all ICT third-party arrangements | ☐ |
| Contract review | Review all ICT contracts against Article 30 mandatory provisions | ☐ |
| Concentration risk | Assess dependency on individual providers and sub-contractors | ☐ |
| Exit strategies | Document exit strategies for critical ICT functions | ☐ |
| Information sharing | Assess participation in Article 45 information sharing arrangements | ☐ |
| AI system integration | Map AI systems against ICT risk framework and DORA obligations | ☐ |
Frequently Asked Questions
What is DORA regulation in simple terms?
DORA is an EU law that requires financial institutions, including banks, insurers, and investment firms, to manage the risks that come from their dependence on technology and digital systems. It sets rules for how they must protect their systems, report technology failures, test their resilience, and manage the technology companies they rely on.
Is DORA a regulation or a directive?
DORA is a regulation. It applies directly and uniformly across all EU member states without national transposition. This means the same rules apply in Germany, France, Ireland, and all other EU member states from 17 January 2025. It is not a directive, which would require each member state to pass its own implementing law.
Who does DORA regulation apply to?
DORA applies to a wide range of EU financial entities including banks, payment institutions, insurers, investment firms, crypto-asset service providers, and others listed in Article 2(1). It also imposes obligations on ICT third-party service providers designated as critical. Technology companies serving EU financial institutions must meet contractual requirements imposed by their financial entity clients under DORA.
Does DORA regulation apply to UK firms?
DORA is not UK domestic law. However, it applies to UK financial entities that are authorised in EU member states or provide regulated services into the EU. It also affects UK technology companies whose EU financial sector clients must impose DORA-compliant contractual requirements on their ICT providers. UK firms with EU regulated operations must assess their DORA obligations specifically.
When did DORA regulation come into force?
DORA entered into application on 17 January 2025, following a two-year implementation period after its adoption in December 2022. All financial entities in scope were required to be compliant from that date.
What is the difference between DORA and the EU AI Act for financial services firms?
DORA governs the operational resilience of financial entities’ ICT systems, including systems that use AI. The EU AI Act governs the development and use of AI systems specifically, including risk classification, technical documentation, human oversight, and conformity assessment. Where a financial entity uses a high-risk AI system, both DORA and the AI Act apply concurrently. DORA covers the ICT risk dimension. The AI Act covers the AI-specific compliance dimension. Both must be satisfied independently.
What are the penalties for non-compliance with DORA?
DORA requires competent authorities to have power to impose effective, proportionate, and dissuasive penalties but leaves specific amounts to member state implementation. Critical ICT third-party service providers face fines of up to 1% of average daily worldwide turnover for non-compliance with oversight requirements, with periodic penalty payments possible for continued non-compliance.
We are a cloud provider serving EU banks. Does DORA apply to us directly?
Not directly unless you are designated as a critical ICT third-party service provider under Article 31. However, your EU bank clients are required by Article 28 to include DORA-specified contractual provisions in their agreements with you, including audit rights, service level requirements, incident assistance obligations, and exit assistance provisions. In practice, DORA shapes the contractual terms you will be required to accept from EU financial sector clients regardless of whether you are formally in scope.
How does DORA interact with NIS2?
NIS2, the Network and Information Security Directive, and DORA overlap in their coverage of cybersecurity for financial entities. Article 1(2) of DORA provides that for financial entities that are essential or important entities under NIS2, DORA is considered a sector-specific act. This means DORA obligations take precedence over NIS2 for financial entities in scope of both. Financial entities comply with DORA rather than NIS2 for their cybersecurity and ICT risk obligations, though national NIS2 competent authorities and financial supervisors must cooperate where issues cross both frameworks.This guide reflects the text of Regulation (EU) 2022/2554 as published in the Official Journal on 27 December 2022 and applicable regulatory technical standards and implementing technical standards adopted through August 2026. It is published by European Compliance Suite for general informational purposes and does not constitute legal advice. Financial entities and ICT service providers should obtain advice specific to their activities, regulatory status, and applicable competent authority requirements.