EU regulations · DORA
Next register consolidation: 31 March 2027Digital 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 to see a working program.
What you need to know
- Twenty categories of financial entities are in scope, several with multiple subtypes, from banks and insurers to crypto-asset service providers, and DORA has been fully applicable since 17 January 2025.
- Five obligation areas span Chapters II to VI: ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing. Major-incident reporting runs on a 4-hour clock from classification.
- Supervision is active: registers of information cycle annually to the ESAs, and the first 19 critical ICT third-party providers were designated in November 2025.
What the Digital Operational Resilience Act is
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: registers of information run an annual cycle to the ESAs each spring, and the Level 2 rulebook is complete.
Today
Spacing proportional to time from today
17 Jan 2025
now in effect
DORA fully applicable to all in-scope financial entities
31 Mar 2027
in 6 months
Next annual register-of-information consolidation to the ESAs
17 Jan 2028
in 15 months
Article 58 Commission review, including possible extension to payment-system operators
Today
17 Jan 2025
now in effect
DORA fully applicable to all in-scope financial entities
31 Mar 2027
in 6 months
Next annual register-of-information consolidation to the ESAs
17 Jan 2028
in 15 months
Article 58 Commission review, including possible extension to payment-system operators
Behind us: Level 2 rulebook completed July 2025; first 19 critical ICT third-party providers designated November 2025; first ESAs incident report June 2026 (3,383 major incidents in 2025, a third from third-party failures).
Does DORA apply to you?
Pick your entity type for a first orientation, 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) carves out exclusions, and Article 2(4) leaves options to Member States. 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, but the duty itself stays.
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.
Use this for orientation and confirm your scope against Article 2 of Regulation (EU) 2022/2554.
Who counts as a financial entity
Credit institutions · Payment institutions · Electronic money institutions · Account information service providers
Investment firms · Trading venues · Central securities depositories · Central counterparties
Insurance and reinsurance undertakings · Insurance intermediaries · Institutions for occupational retirement provision
Crypto-asset service providers · Crowdfunding service providers · Securitisation repositories
Management companies · Alternative investment fund managers
Trade repositories · Credit rating agencies · Administrators of critical benchmarks · Data reporting service providers
The Article 4 proportionality principle
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 chose not to exercise the Article 2(4) option (exercising it excludes them from DORA entirely), 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 comply from abroad; it needs an EU legal presence.
Contractual obligations (Article 30): Article 30(2) requires baseline contractual clauses (description of services, locations, data protection, service levels, termination) in all ICT service contracts. Article 30(3) adds enhanced provisions, including performance monitoring, audit rights, and exit strategies, for services supporting critical or important functions.
Which of the five reach you?
Answer for your company, and see the stack you actually manage. Most teams arrive here for one regulation and leave managing three.
You came for the DORA. Tick what else is true and watch the stack grow.
A one-question check gives orientation only; actual scope turns on each regime's territorial, entity-size, and product tests.
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”.
Chapter II
ICT risk management
Articles 5-16
- Comprehensive ICT risk management framework
- Management body accountability and oversight
- Identify, protect, detect, respond, and recover
- Business continuity and disaster recovery plans
Chapter III
Incident reporting
Articles 17-23
- 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
Chapter IV
Resilience testing
Articles 24-27
- 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
Chapter V
Third-party risk
Articles 28-44
- 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
Chapter VI
Information sharing
Article 45
- 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, long before resolution.
Stage 0: the clock starts the moment the incident is classified as major
| Step | Deadline | Content |
|---|---|---|
| Initial notification | 4 h from classification as major, and no later than 24 hours from awareness |
|
| Intermediate report | 72 h from the initial notification |
|
| Final report | 1 month from the latest intermediate report |
|
The deadlines generally run on calendar time, though under Article 5 of the reporting RTS many entities may submit by noon of the next working day when a deadline lands on a weekend or bank holiday; significant credit institutions and other listed categories get no such extension. The RTS also carries further triggers: intermediate reports update on material status changes or on the authority's request, and reports can be combined where recovery comes early.
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.
sanctions framework
Member States must provide effective, proportionate, and dissuasive penalties for breaches by in-scope financial entities.
Financial entities
of average daily worldwide turnover per day
The lead overseer can impose daily periodic penalty payments on designated critical ICT third-party providers under Article 35.
Critical ICT providers · Article 35
maximum duration
Periodic penalty payments accrue daily and can run for up to six months.
Periodic penalty window
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.
How regimes stack on one AI system
DORA treats AI models in financial ICT as ICT. Here is how one system accumulates duties across regimes.
Worked example · 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
If the model ships to the bank as licensed software, it is a product with digital elements and the vendor carries manufacturer duties. Run purely as an internal model or hosted service, it stays outside the CRA and the entity regimes above cover it.
- Annex I secure-by-design & vulnerability handling
- Article 14 reporting (24h/72h)
- Article 12 bridge to AI Act Article 15
The regimes overlap where the controls live. Map controls once, keep one evidence record, and reuse it across every regime that attaches; the Modulos platform is built on that working model.
The regimes overlap where the controls live
The governance graph maps every control in the framework library to every regulation it serves. Where regimes map the same control, one implementation and one evidence record can support all of them, subject to each regime's own requirements, and most of DORA's controls already serve at least one other framework.
Framework library v1.0.32
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.
Turn DORA obligations into executable work
Break DORA obligations into structured requirements and mapped controls with clear ownership, implementation status, and evidence expectations.
Reuse controls across overlapping requirements
Map one control to multiple obligations where overlap exists, reducing duplicate implementation and evidence effort across governance programs.
Trace ICT risk controls end-to-end
Track ICT risk management controls from design to operation with linked evidence, review history, and change records.
Organize third-party oversight evidence
Organize third-party risk documentation and contractual evidence in a consistent structure that supports DORA oversight and internal assurance.
Prove governance and remediation decisions
Use review states and approval records to demonstrate accountable governance and decision-making around controls and remediation actions.
Export supervisory-ready documentation
Generate control and project exports plus supporting evidence files to build supervisory and internal audit packages efficiently.
How DORA fits with other frameworks
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. The software those entities procure carries its own regime: the Cyber Resilience Act puts secure-by-design, SBOM, and vulnerability-reporting duties on the vendors, which feeds directly into DORA third-party risk work.
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.
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 20 categories of financial entities, several with multiple subtypes, 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.
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:
Where the DORA work goes next
Talk to an expert
Walk through your ICT risk framework with someone who has built the registers before.
Book a DORA demo →Keep exploring on your own
The framework docs cover DORA chapter by chapter, and the governance graph shows what your ISO/IEC 27001 work already covers.