For financial entities, risk leaders, and compliance teams
Digital Operational
Resilience Act
(DORA) Compliance
Operationalize DORA across ICT risk, incident reporting, resilience testing, and third-party oversight. Fully applicable since 17 January 2025: supervisors expect a working program, not a plan.
What is DORA?
DORA (Regulation (EU) 2022/2554) is the EU's regulation ensuring that financial entities can withstand, respond to, and recover from ICT-related disruptions. It became fully applicable on 17 January 2025 and covers over 20 categories of financial entities, from banks and insurers to crypto-asset service providers.
DORA also establishes an EU oversight framework for designated critical ICT third-party providers and acts as lex specialis to NIS2 for financial-sector ICT risk and incident reporting obligations.
Where things stand
DORA is past its application date and into steady-state supervision. Four markers show where the regime is today and what comes next.
DORA fully applicable to all in-scope financial entities under Article 64
ESAs designated the first 19 Critical ICT Third-Party Providers, including the major cloud providers
Registers of information enter an annual submission cycle under ESA implementing standards
Commission review of key DORA provisions, including the oversight framework (Article 58)
Does DORA apply to you?
Pick your entity type for a first read, then check the full list. Article 2(1)(a) to (t) lists more than 20 categories of financial entities, from banks and insurers to crypto-asset service providers. Article 2(3) sets exclusions and Article 2(4) gives Member States options. DORA also reaches into the technology supply chain through its oversight framework for designated critical ICT third-party providers under Article 31.
In scope as a financial entity
Credit institutions are the first entry in the Article 2(1) list. You owe the full Chapter II ICT risk-management framework, major-incident reporting, resilience testing, and third-party oversight, and you are a prime candidate for threat-led penetration testing under Articles 26 and 27.
Proportionality: Article 4 scales implementation to your size and risk profile. It narrows how you comply, not whether you comply.
In scope as a financial entity
Payment institutions, e-money institutions, and account information service providers are all listed in Article 2(1). Most implement the full framework, from ICT risk management through incident reporting and third-party oversight.
Proportionality: Institutions exempted under PSD2 or the E-Money Directive follow the simplified ICT risk-management framework of Article 16 instead of the full Chapter II version.
In scope as a financial entity
Investment firms are listed in Article 2(1). Most implement the full Chapter II framework plus the reporting, testing, and third-party duties that come with it.
Proportionality: Small and non-interconnected investment firms follow the simplified ICT risk-management framework of Article 16.
In scope as a financial entity
Insurance and reinsurance undertakings are listed in Article 2(1) and implement the full framework across ICT risk, incident reporting, resilience testing, and third-party oversight.
Proportionality: Article 4 scales the work to your size and risk profile. Insurance intermediaries that are microenterprises or SMEs are excluded under Article 2(3), but that exclusion does not extend to insurers themselves.
In scope as a financial entity
Crypto-asset service providers authorised under MiCA and issuers of asset-referenced tokens are listed in Article 2(1). DORA draws no distinction between crypto and traditional finance on operational resilience.
Proportionality: Article 4 applies, but there is no simplified-framework carve-out for crypto-asset service providers.
In scope as a financial entity
UCITS management companies and alternative investment fund managers are listed in Article 2(1) and implement the full framework.
Carve-out: Sub-threshold managers registered under Article 3(2) of the AIFMD are excluded from DORA under Article 2(3).
In scope as a financial entity
Trading venues, central counterparties, central securities depositories, trade repositories, and data reporting service providers are all listed in Article 2(1). As core market infrastructure you implement the full framework and are a likely candidate for TLPT under Articles 26 and 27.
Proportionality: Article 4 applies, but supervisory expectations for market infrastructure sit at the demanding end of the scale.
In scope indirectly, through your customers
DORA does not regulate you directly unless you are designated, but every financial-entity customer must flow Article 30 terms into your contracts (service descriptions, locations, monitoring, audit and exit rights) and record your services in their register of information. Expect DORA clauses in every renewal.
Designation risk: The ESAs designated the first 19 Critical ICT Third-Party Providers on 18 November 2025, including the major cloud providers. Designated CTPPs face direct ESA oversight and periodic penalty payments of up to 1% of average daily worldwide turnover.
Orientation, not legal advice: confirm your scope against Article 2 of Regulation (EU) 2022/2554.
Banking & Credit
- Credit institutions
- Payment institutions
- Electronic money institutions
- Account information service providers
Investment & Trading
- Investment firms
- Trading venues
- Central securities depositories
- Central counterparties
Insurance & Pensions
- Insurance and reinsurance undertakings
- Insurance intermediaries
- Institutions for occupational retirement provision
Crypto & Alternative
- Crypto-asset service providers
- Crowdfunding service providers
- Securitisation repositories
Asset Management
- Management companies
- Alternative investment fund managers
Market Infrastructure
- Trade repositories
- Credit rating agencies
- Administrators of critical benchmarks
- Data reporting service providers
Proportionality Principle (Article 4)
DORA applies proportionally: requirements scale with the size, risk profile, and complexity of the entity.
Article 16(1) provides a simplified ICT risk-management framework for specific entity categories: small and non-interconnected investment firms, exempt payment and e-money institutions, credit institutions exempted under Directive 2013/36/EU where Member States exercise the Article 2(4) option, and small institutions for occupational retirement provision.
Other in-scope institutions must implement the full framework, and entities identified by competent authorities must perform advanced resilience testing (TLPT) under Articles 26-27.
DORA Reaches Into Your Tech Supply Chain
DORA's Chapter V brings ICT third-party service providers into scope through oversight of Critical Third-Party Providers (CTPPs). On 18 November 2025, the European Supervisory Authorities designated the first 19 CTPPs, including AWS, Google Cloud, and Microsoft.
Extraterritorial reach (Article 31(12)): Non-EU CTPPs must establish a subsidiary within the European Union within 12 months of designation. This means a US cloud provider serving EU financial institutions cannot simply comply from abroad; they must have an EU legal presence.
Contractual obligations (Article 30): Article 30(2) requires baseline contractual clauses (description of services, locations, monitoring, exit strategies) in all ICT service contracts. Article 30(3) adds enhanced provisions, including audit rights and detailed exit strategies, for services supporting critical or important functions.
What do you owe?
Five substantive obligation areas, set out in Chapters II to VI of Regulation (EU) 2022/2554. DORA does not formally use the term “pillars”.
ICT Risk Management
- -Comprehensive ICT risk management framework
- -Management body accountability and oversight
- -Identify, protect, detect, respond, and recover
- -Business continuity and disaster recovery plans
Incident Reporting
- -Classify incidents based on severity criteria
- -Initial notification within 4 hours of classification (and within 24 hours of awareness)
- -Intermediate report within 72 hours of the initial notification
- -Final report within 1 month of the latest updated intermediate report
Resilience Testing
- -Regular testing of ICT tools and systems
- -Threat-Led Penetration Testing (TLPT) at least every 3 years for entities identified by competent authorities
- -If internal testers are used, external testers are required every third TLPT; significant credit institutions use external testers only
- -Testing on live production systems with safeguards
- -Follow DORA TLPT RTS (Commission Delegated Regulation (EU) 2025/1190) for execution and closure
Third-Party Risk
- -Article 28(3) Register of Information for all ICT service arrangements
- -Due diligence before onboarding providers
- -Continuous monitoring of provider performance
- -Direct oversight of designated critical ICT third-party providers by the lead overseer
Information Sharing
- -Voluntary cyber threat intelligence sharing
- -Within trusted financial sector communities
- -Compliant with data protection rules
- -Collective defense across the sector
How fast must you report an incident?
Article 19 and Commission Delegated Regulation (EU) 2025/301 set a three-stage escalation clock for major ICT-related incidents. It starts the moment you classify an incident as major, not when you resolve it.
Stage 0: the clock starts the moment the incident is classified as major
Initial notification
From classification as major, and no later than 24 hours from awareness
- What happened, when it was detected, and why it is classified as major
- Member States and services affected
- Whether business continuity plans were activated
Intermediate report
From the initial notification
- Updated status and severity assessment
- Clients, counterparties, and transactions affected
- Recovery actions taken so far
Final report
From the latest intermediate report
- Root cause analysis
- Actual direct and indirect costs and losses
- Remediation applied and safeguards against recurrence
The deadlines run on calendar time: weekends and public holidays do not pause the clock.
What happens if you get it wrong?
DORA sets the enforcement framework but leaves the fine tables for most financial entities to Member State law. Designated critical ICT providers answer to the ESAs directly.
Financial Entities
Member States must provide effective, proportionate, and dissuasive penalties for breaches by in-scope financial entities.
Critical ICT Providers
The lead overseer can impose daily periodic penalty payments on designated critical ICT third-party providers under Article 35.
Periodic Penalty Window
Periodic penalty payments accrue daily and can run for up to six months.
The split matters: national supervisors set fines for financial entities, while designated Critical ICT Third-Party Providers face periodic penalties of up to 1% of average daily worldwide turnover for up to six months.
One AI system, four regimes
DORA treats AI models in financial ICT as ICT. Here is how one system accumulates duties across regimes.
One system, every regime · SYS-04 · credit-scoring model at an EU-serving bank
Credit scoring is Annex III point 5(b): the model is a high-risk AI system.
- Articles 9 to 17 high-risk stack
- Conformity assessment
- EU database registration
Personal data runs through training, inputs, and outputs, and a solely automated credit denial is an Article 22 decision.
- Lawful basis for each processing purpose
- Article 35 DPIA
- Data-subject rights incl. Article 22
At a financial entity, the model is ICT supporting a critical or important function.
- Chapter II ICT risk management
- Major-incident reporting
- Register of information entry
For financial entities NIS2 is largely disapplied: DORA is lex specialis under NIS2 Article 4. Run the same model at an energy or health company and the Article 21 measures attach instead.
- Article 21 cybersecurity measures (where in scope)
- 24h early warning, 72h notification
Four regimes, one system, overlapping controls. Map controls once, keep one evidence record, and reuse it across every regime that attaches. That is the working model behind the Modulos platform.
How the work gets done
Modulos gives risk and compliance teams one workflow for requirements, controls, evidence, reviews, and exports. This helps you operationalize DORA with clearer accountability and defensible audit trails.
Book a DORA DemoBreak DORA obligations into structured requirements and mapped controls with clear ownership, implementation status, and evidence expectations.
FAQ about the Digital Operational Resilience Act
The Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, is the EU regulation governing the operational resilience of financial entities. It applies to banks, investment firms, insurance and reinsurance undertakings, payment and e-money institutions, crypto-asset service providers, and other financial entities listed in Article 2, plus their ICT third-party service providers under the Chapter V oversight framework. DORA entered application on 17 January 2025.
DORA stands for the Digital Operational Resilience Act, formally Regulation (EU) 2022/2554. It is binding EU law on the operational resilience of financial entities and their critical ICT third-party providers. The acronym is sometimes confused with the Colorado Department of Regulatory Agencies (also DORA), which is unrelated to EU financial regulation.
DORA was adopted on 14 December 2022 and entered into force on 16 January 2023. The two-year preparation period ended on 17 January 2025, when the regulation became applicable under Article 64. Financial entities have been required to comply since 17 January 2025; designated critical ICT third-party providers (CTPPs) become directly subject to the Chapter V oversight framework only after Article 31 designation and notification, which the European Supervisory Authorities began on 18 November 2025.
Yes, for in-scope entities. DORA is a binding EU regulation that applies directly across all 27 member states without national transposition. Financial entities listed in Article 2 must comply with the Chapter II to V obligations and the Chapter VI information-sharing conditions where they participate. Designated critical ICT third-party providers are subject to the Chapter V oversight framework directly following Article 31 designation.
DORA compliance means meeting the obligations across the five substantive chapters of the regulation: ICT risk management under Chapter II (Articles 5 to 16), ICT-related incident management and reporting under Chapter III (Articles 17 to 23), digital operational resilience testing including threat-led penetration testing under Chapter IV (Articles 24 to 27), management of ICT third-party risk and the oversight framework for designated critical providers under Chapter V (Articles 28 to 44), and information-sharing arrangements under Chapter VI (Article 45).
DORA does not formally use the term "pillars". The five substantive obligation areas live in Chapters II to VI. Chapter II covers the ICT risk-management framework (Articles 5 to 16). Chapter III covers ICT-related incident management, classification, and reporting (Articles 17 to 23). Chapter IV covers digital operational resilience testing, including threat-led penetration testing under Article 26 for entities identified by competent authorities (Articles 24 to 27). Chapter V covers management of ICT third-party risk and the oversight framework for designated critical ICT providers (Articles 28 to 44). Chapter VI covers voluntary information-sharing arrangements (Article 45).
Article 2(1)(a)–(t) lists over 20 categories of financial entities, including credit institutions, payment and e-money institutions, 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 reinsurance undertakings, insurance and reinsurance intermediaries, IORPs, credit rating agencies, administrators of critical benchmarks, crowdfunding service providers, and securitisation repositories. Article 2(3) sets exclusions and Article 2(4) gives Member States options. ICT third-party providers are listed separately at Article 2(1)(u) and are directly subject to DORA only after Article 31 designation as critical.
Under Article 19 and Commission Delegated Regulation (EU) 2025/301 Article 5, financial entities submit an initial notification within 4 hours after classifying a major ICT-related incident (and no later than 24 hours after becoming aware of it), an intermediate report within 72 hours of the initial notification, and a final report within one month of the latest updated intermediate report. Entities can also report significant cyber threats voluntarily under Article 19(2).
For financial entities, Article 50 requires member states to set effective, proportionate, and dissuasive administrative penalties in national law; sanctions are not harmonised into one EU-wide cap. For designated critical ICT third-party providers under the Chapter V oversight framework, Article 35(7) and (8) allow the lead overseer to impose periodic penalty payments of up to 1% of the average daily worldwide turnover in the preceding business year, for a maximum of six months.
Modulos automates the governance, risk, and compliance workflow across DORA’s five substantive chapters (II to VI): ICT risk-management framework documentation, incident records, resilience-testing evidence, third-party risk registers and contracts, and audit trails for supervisory reviews. Controls map across DORA, NIS2, ISO/IEC 27001, ISO/IEC 42001, the EU AI Act, and SOC 2 simultaneously, which matters for financial entities running multi-framework compliance programs.
How DORA fits with other frameworks
Most financial entities run DORA alongside other regimes rather than instead of them.
For financial entities subject to both DORA and the NIS2 Directive, DORA is lex specialis: DORA Article 1(2) and NIS2 Article 4 disapply equivalent NIS2 provisions where DORA covers the same matter. NIS2 governance and supply-chain provisions outside DORA may still apply alongside.
ICT risk management under DORA Chapter II maps directly onto ISO/IEC 27001 controls, with ISO/IEC 42001 supporting the AI-management portion where the financial entity uses AI in its ICT systems. Risk operating models such as NIST AI RMF support the AI risk-analysis duty inside DORA.
When financial entities deploy AI systems that touch personal data or fall under high-risk categories, the EU AI Act and GDPR apply alongside DORA without substituting for any of them.
For US-attestation work, SOC 2 control sets often share evidence with DORA Chapter II ICT risk-management controls, especially around access, change, and incident management.
Comparing platforms? See how 20 AI governance platforms address AI risk inside the DORA stack in our 2026 enterprise buyer’s guide.
By industry
How this applies in your sector
DORA is a financial-sector regime. See how it stacks with the EU AI Act and ISO/IEC 42001 for AI used in financial ICT:
Need a Defensible DORA Execution Workflow?
In a live walkthrough, see how teams track ICT risk controls, third-party evidence, and reporting artifacts before supervisory reviews.