DORA is EU Regulation 2022/2554, in force since 17 January 2025. It sets uniform, legally binding requirements for the digital operational resilience of EU financial institutions — here's everything you need to know.
DORA — the Digital Operational Resilience Act (EU Regulation 2022/2554, Official Journal L 333) — is the EU's comprehensive law requiring financial institutions to withstand, respond to, and recover from ICT (information and communication technology) disruptions, whether caused by cyberattacks, software failures, power outages, or third-party provider incidents.
The regulation was adopted in December 2022 and became fully applicable on 17 January 2025. It applies to over 22,000 financial entities across the EU — from the largest systemically important banks to payment institutions, crypto-asset service providers, and insurance undertakings.
DORA's central insight: in modern finance, a cyberattack or IT failure poses the same systemic risk as a liquidity crisis. Before DORA, financial regulators supervised capital adequacy and credit risk with rigour while digital resilience remained governed by non-binding guidelines and fragmented national rules. DORA closes that gap.
Before DORA, ICT risk rules for financial firms were fragmented across member states and sectors. A payment processor in Germany faced different digital resilience rules than one in France or Italy. The EBA's ICT guidelines (EBA/GL/2019/04) were influential but non-binding — regulators could choose how strictly to enforce them, creating regulatory arbitrage. Major incidents including the 2020 SolarWinds supply chain attack and large-scale cloud outages affecting financial services demonstrated how critical unified standards had become. DORA creates a single harmonised framework across all 27 EU member states and all financial sectors simultaneously.
DORA covers cybersecurity, but also operational resilience more broadly — IT system failures, power outages, natural disasters affecting ICT infrastructure, and disruptions caused by third-party providers. If an event disrupts digital operations of a financial entity, DORA's requirements apply. It sits alongside (and takes precedence over) the NIS2 Directive for entities within its scope.
DORA organises its requirements into five interconnected pillars, each supported by specific Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) published by the European Supervisory Authorities. Each pillar addresses a distinct failure mode that prior ICT rules left inadequately covered.
Comprehensive governance framework covering identification, classification and documentation of ICT assets; protection and prevention controls; anomaly detection; response, recovery and restoration. Management body directly accountable under Article 5.
RTS on ICT Risk Management →Mandatory classification and reporting of major ICT incidents to competent authorities within strict timeframes: 4-hour initial notification, 72-hour intermediate report, 1-month final report. Voluntary reporting of significant cyber threats.
Incident Reporting RTS Guide →Annual basic testing (vulnerability assessments, scenario-based tests) required for all entities. Advanced Threat-Led Penetration Testing (TLPT) mandatory every 3 years for significant institutions, based on the TIBER-EU methodology.
Full TLPT Guide →Oversight of all ICT service providers including cloud providers. Mandatory Register of Information, contract requirements (audit rights, exit plans, SLAs), and due diligence obligations. Critical providers directly supervised by ESAs.
19 Designated CTPPs (2025) →Voluntary arrangements among financial entities to share cyber threat intelligence, indicators of compromise, and lessons from incidents. Participating entities benefit from regulatory safe harbour for good-faith sharing activities.
Information Sharing RTS →DORA Article 2 defines one of the broadest scopes of any EU financial regulation, covering 21 categories of financial entity. Unlike sector-specific rules, DORA applies simultaneously to banks, insurers, investment firms, crypto providers, pension funds, and infrastructure operators — any entity whose disruption could affect financial stability or consumers.
Every in-scope entity must maintain a documented, management-body-approved ICT risk management framework. This is not a one-time exercise: the framework must be reviewed annually and after every major ICT incident. It must cover the full lifecycle of risk: identification and classification of ICT assets supporting critical functions; technical and organisational protection measures; continuous monitoring and anomaly detection; incident response and recovery procedures; and post-incident review and improvement processes.
Article 5 explicitly places accountability on the management body — the board of directors or equivalent — to approve the framework, allocate adequate budget, receive regular ICT risk reports, and demonstrate active oversight during supervisory assessments.
Major ICT incidents must be reported to the national competent authority using a three-stage process defined in the RTS on incident reporting: an initial notification within 4 hours of first awareness; an intermediate report within 72 hours containing a preliminary assessment of impact; and a final report within one month including root cause analysis and lessons learned. The classification criteria — specifying what makes an incident "major" — are set out in Commission Delegated Regulation 2024/1772 and include quantitative thresholds on affected clients, duration, data loss, and financial impact.
DORA also allows voluntary reporting of significant cyber threats that could affect the financial sector, encouraging proactive intelligence sharing even when an actual incident has not occurred.
All financial entities must maintain a Register of Information documenting every contractual arrangement with ICT third-party service providers. The register must record provider identity, services contracted, classification of functions as critical or important, contractual dates, and full sub-outsourcing chains. The ESAs published a mandatory data template (ITS on Register of Information) in early 2025. Most entities were required to submit the register to their competent authority by 30 April 2025. Regulators use the aggregated register data to map systemic concentration risk across the financial sector.
DORA mandates specific clauses in all contracts with ICT third-party service providers supporting critical or important functions. Required provisions include: clearly defined and measurable service level agreements; full audit and inspection rights for the entity and its competent authority; data portability and access rights on termination; constraints on sub-outsourcing without prior approval; exit plans and transition periods; and incident notification obligations. Contracts signed before January 2025 that lack these clauses must be renegotiated — there is no formal grace period in the text of the Regulation.
All in-scope entities must conduct annual basic ICT resilience testing including vulnerability assessments, open-source analysis, network security assessments, and gap analysis on ICT risk controls. Significant institutions must additionally undergo Threat-Led Penetration Testing (TLPT) every three years. TLPT simulates real adversary techniques against production systems and must be conducted by qualified external testers. The DORA TLPT framework is built on the TIBER-EU methodology and requires coordination with the national competent authority.
DORA has been in force since January 2025 and supervisors are actively integrating it into their oversight frameworks. Understanding the enforcement reality helps institutions prioritise where regulatory scrutiny will fall first.
The European Central Bank has formally integrated DORA compliance into the Supervisory Review and Evaluation Process (SREP) for significant institutions. ICT risk assessment results directly influence SREP scores and can trigger additional capital requirements or operational constraints. The 2025 SREP cycle includes specific DORA-themed questionnaires sent to supervised entities.
The April 2025 Register of Information submission has given supervisors their first data-driven map of third-party concentration in the EU financial sector. Follow-up queries from competent authorities are ongoing. Institutions with incomplete registers or inconsistent data are being asked to resubmit. This is the area generating the most immediate supervisory dialogue in 2025.
The 19 designated Critical ICT Third-Party Providers (first list, November 2025) are now under direct ESA oversight through lead overseers. Oversight programmes include information requests, desktop assessments, and preparation for on-site inspections. Financial entities relying on these CTPPs must cooperate with oversight exercises and ensure their contractual arrangements enable full access.
The first TLPT cycle for large institutions began in 2025. National competent authorities (BaFin, ACPR, DNB, FCA-equivalent bodies) are coordinating TLPT programmes with the Joint Committee of ESAs. Results feed into SREP assessments. Institutions that have not yet initiated TLPT planning face increasing supervisory pressure.
Competent authorities are testing the quality of incident reporting submissions. Common findings include: delays between first awareness and initial notification, misclassification of incidents (under-reporting is a risk as much as over-reporting), and final reports lacking adequate root cause analysis. First formal enforcement actions for reporting failures are expected in 2026.
According to the EBA's 2024 progress survey, approximately 60-70% of EU financial institutions described their Register of Information as a "work in progress" at the January 2025 deadline. Supervisors acknowledge this and are taking a risk-based approach to enforcement, prioritising institutions with the largest third-party exposures and most significant gaps first.
DORA compliance requires investment. But the financial exposure of non-compliance — direct fines, incident costs, and reputational damage — typically far exceeds the cost of a structured compliance programme. Here is the evidence base that boards and senior management should be aware of.
DORA fines under Article 50 are calibrated to worldwide annual turnover — not EU-only turnover. For a large European bank with €5Bn global revenues, 2% equates to €100M. For a mid-size payment institution with €200M revenues, 2% is €4M. DORA also enables competent authorities to temporarily suspend or prohibit specific ICT services, which can be operationally more disruptive than a financial penalty.
Critically: DORA fines can be applied cumulatively. An institution with governance failures (Pillar 1), late incident reporting (Pillar 2), and no TLPT programme (Pillar 3) is exposed to parallel enforcement across multiple articles. This is distinct from single-issue regulations like GDPR.
A public DORA enforcement notice is increasingly consequential. Credit rating agencies (S&P, Moody's, Fitch) incorporate operational resilience governance into financial institution ratings. A publicised DORA enforcement action signals control weaknesses that can trigger negative rating watch events, increase funding costs, and prompt institutional investors to request governance explanations.
Insurance implications are also evolving. Cyber insurers are beginning to align underwriting criteria with DORA compliance status. Institutions with documented DORA programmes in place — completed registers, tested incident response plans, active TLPT programmes — are well-positioned to negotiate better cyber insurance terms. The inverse also applies.
Where does your institution stand? This five-level framework — adapted from established capability maturity models — helps organisations locate their current state across DORA's five pillars and build a credible roadmap toward full compliance. The model is used in our free DORA Assessment Dashboard.
No structured ICT risk framework. Incidents managed reactively on an ad hoc basis. No Register of Information. Third-party contracts lack DORA clauses. Management body not engaged on ICT risk.
ICT risk management policy exists but is not fully tested or operationalised. Register of Information started but incomplete. Incident response process documented but not practised. Management body aware but not actively overseeing.
Processes formally implemented across all 5 pillars. Register submitted to regulator. Incidents classified and reported. Basic testing completed. Contracts under review. Board receiving regular ICT risk reports.
Reporting automated with defined metrics and thresholds. TLPT programme underway or completed. Register verified and regularly updated. Testing programme embedded in operational calendar. Management body demonstrating active SREP-ready oversight.
Intelligence-sharing arrangements active. DORA controls fully integrated into ICAAP, SREP, and enterprise risk frameworks. Third-party oversight programme functioning as a strategic supplier management capability, not just compliance. Continuous improvement cycle embedded.
Answer 25 questions and get an instant maturity score with prioritised remediation recommendations across all 5 DORA pillars.
Get Your Free DORA ScoreBased on supervisory feedback and implementation experience across EU financial institutions, these are the five errors that compliance teams encounter most frequently — and that generate the most supervisory scrutiny.
Institutions consistently underestimate the volume, complexity, and data quality requirements of the Register of Information. A typical mid-size bank may have 200–500 active ICT third-party arrangements when sub-outsourcing chains are properly traced. The ESA data template requires granular fields per arrangement. Institutions that began the exercise late, or assumed their existing vendor management databases were sufficient without remediation, struggled to meet the April 2025 submission deadline with accurate data. The register is a live document requiring quarterly updates — not a one-time project deliverable.
The RTS on incident classification uses quantitative thresholds across five criteria (client impact, duration, data integrity, reputational impact, financial loss). Institutions frequently under-classify incidents because they apply thresholds individually rather than cumulatively, or because they measure impact at the time of initial detection rather than at peak. Under-classification is a compliance risk: if a supervisor subsequently reclassifies an incident as "major" and finds no notification was filed, the entity faces enforcement for both the operational failure and the reporting failure. Building a documented classification decision log for every significant incident is essential.
Threat-Led Penetration Testing is often confused with existing annual penetration testing programmes. TLPT is fundamentally different: it targets critical functions and production systems using real attacker techniques (not vulnerability scans), requires pre-authorised coordination with the competent authority, and must be conducted by external testers meeting DORA's qualification criteria. The three-year cycle is per institution, not per system. Institutions that assumed their existing third-party security testing satisfied TLPT requirements have had to build parallel programmes from scratch — a costly and time-consuming process that needs to begin 12–18 months before the target test date.
DORA's Article 30 contract requirements are non-negotiable — every contract covering critical or important functions must contain the specified clauses. Large institutions discovered on gap analysis that hundreds of contracts signed before 2025 lacked audit rights, adequate exit plan provisions, or explicit sub-outsourcing restrictions. Renegotiating with major ICT vendors (cloud providers, core banking software suppliers) proved more complex than anticipated — some vendors pushed back on audit rights in particular. Institutions that prioritised critical-function contracts first and maintained a documented renegotiation tracker have managed this most effectively.
Article 5 of DORA is unambiguous: the management body bears direct accountability for the ICT risk management framework. Supervisors have found that in many institutions, board-level engagement remains superficial — boards receive ICT risk reports but cannot demonstrate they challenged assumptions, requested remediation of weaknesses, or allocated resources based on those reports. During SREP interviews, board members are increasingly asked to explain the entity's DORA compliance status directly. Boards that delegate DORA entirely to the CISO or IT function, without maintaining meaningful oversight, face personal fine exposure of up to €1M under Article 50(4)(b).
DORA published in the Official Journal of the EU (L 333). 24-month implementation period begins. ESAs mandated to develop 13 RTS and ITS packages.
ESAs publish first and second batch of RTS/ITS drafts for public consultation. Institutions begin formal gap analysis and compliance programme mobilisation.
ESAs publish final batch of RTS/ITS including the Register of Information ITS (data template), incident classification RTS, and TLPT RTS. Final standards enter Commission adoption process.
DORA fully applicable. All requirements in force. Supervisors begin active monitoring. ECB integrates DORA into 2025 SREP cycle for significant institutions.
Register of Information first submission deadline for most entities. ESAs begin aggregating data to map systemic concentration in ICT third-party dependencies across EU financial sector.
First list of 19 Critical ICT Third-Party Providers (CTPPs) published by the ESAs. Lead overseers assigned. Direct oversight programmes begin for designated providers.
First TLPT cycles for large institutions. SREP assessments including DORA findings. First formal enforcement actions expected for incident reporting failures and Register quality deficiencies.
Annual ICT resilience testing, continuous monitoring and reporting, quarterly Register updates, and third-party oversight required for all in-scope entities indefinitely.
DORA grants competent authorities broad supervisory and enforcement powers under Chapter VI (Articles 42–56). Administrative penalties are calibrated to worldwide turnover — not EU-only revenues — and can be applied cumulatively across multiple violations.
| Entity Type | Maximum Fine | Legal Reference |
|---|---|---|
| Financial entities (general) | Up to 2% of total annual worldwide turnover | Art. 50(4)(a) |
| Natural persons (senior management) | Up to €1,000,000 | Art. 50(4)(b) |
| Critical ICT Third-Party Providers | Up to 1% of average daily worldwide turnover, per day, for up to 6 months | Art. 35(4) |
| CTPPs — severe violations (Art. 35(6)) | Suspension of designation as CTPP; prohibition from providing services to EU financial entities | Art. 35(6) |
NIS2 (Directive 2022/2555) covers cybersecurity broadly for critical infrastructure sectors including energy, health, and digital services. DORA is lex specialis for financial entities under Article 1(1) of the Regulation — it takes precedence over NIS2 for entities within its scope. In practice: a bank subject to DORA does not need to separately comply with NIS2's equivalent incident reporting requirements, since DORA's requirements are considered at least equivalent. However, ICT third-party providers serving financial entities (cloud providers, data centre operators) may simultaneously be subject to NIS2 as "digital infrastructure" entities.
Full DORA vs NIS2 Comparison →DORA and GDPR are complementary, not mutually exclusive. ICT incidents involving personal data breaches trigger both DORA incident reporting (to the financial competent authority) and GDPR breach notification (to the data protection authority). The timelines differ: DORA requires 4-hour initial notification for major ICT incidents, while GDPR requires 72-hour breach notification. Institutions must maintain dual notification procedures and ensure both are activated when an incident involves personal data. Third-party ICT contracts must satisfy both DORA Article 30 requirements and GDPR Article 28 data processor requirements simultaneously.
Under the Capital Requirements Directive (CRD IV/V), the Supervisory Review and Evaluation Process (SREP) assesses capital adequacy, liquidity, and business model viability. From 2025, DORA compliance is formally integrated into the SREP framework. The ECB and national competent authorities use DORA ICT risk findings as direct inputs to SREP scores. Persistently poor DORA compliance can result in additional capital add-ons under Pillar 2 to buffer against operational risk — creating a direct financial link between ICT resilience and capital requirements.
The Bank Recovery and Resolution Directive (BRRD) requires institutions to maintain operational continuity through resolution scenarios. DORA's ICT resilience requirements strengthen resolution feasibility: institutions with robust DORA frameworks can demonstrate that critical functions would survive an insolvency scenario. Resolution authorities (under the SRM) increasingly consider ICT operational resilience in assessing resolution plan credibility.
DORA does not require ISO 27001 certification or NIST CSF adoption — but these frameworks map well to DORA's ICT risk management requirements. ISO 27001 controls align strongly with DORA Pillar 1. NIST CSF's Detect, Respond, and Recover functions map to DORA Pillars 2 and 3. Holding ISO 27001 certification does not constitute DORA compliance, but institutions with mature ISO 27001 programmes have a significant implementation head start.
Key questions about DORA that go beyond the basics. For the full 50-question FAQ, see our dedicated DORA FAQ page.
Before DORA, EBA ICT guidelines (EBA/GL/2019/04) were non-binding recommendations. National regulators could choose how — and whether — to enforce them, creating uneven standards across the EU. DORA is a directly applicable EU Regulation (not a Directive), meaning it has the same legal force in all 27 member states without needing national transposition. It also covers all financial sectors simultaneously, whereas previous guidelines were sector-specific, and introduces mandatory penalties that competent authorities must be able to apply.
Yes, but only to those formally designated as Critical ICT Third-Party Providers (CTPPs) by the Joint Committee of the ESAs. The first 19 CTPPs were designated in November 2025 — primarily large cloud infrastructure and data analytics providers. Designated CTPPs face direct ESA oversight including audit rights, mandatory testing cooperation, and potential fines of up to 1% of average daily worldwide turnover per day for up to 6 months. Non-designated ICT providers are not directly supervised under DORA but must meet contractual requirements their financial entity clients impose under Article 30.
The DORA RTS on incident classification (Commission Delegated Regulation 2024/1772) defines major incidents using quantitative thresholds across five criteria: clients affected; duration; data integrity or availability; reputational impact; and economic loss. Classification must be completed within 4 hours of the entity becoming aware of the incident, triggering the initial notification to the competent authority. The thresholds apply cumulatively — a relatively brief incident affecting a large proportion of clients can qualify as major even if the absolute duration is short.
Existing contracts must be renegotiated to include DORA's mandatory Article 30 clauses: service level agreements, audit and inspection rights, data portability rights, sub-outsourcing constraints, termination rights and exit plans, and incident notification obligations. There is no formal grace period in the Regulation — these provisions were required from 17 January 2025. In practice, many institutions have prioritised contracts covering critical or important functions first, given the volume of third-party agreements involved. Supervisors expect a documented renegotiation tracker showing progress toward full contract remediation.
A CTPP is an ICT third-party service provider formally designated as critical by the Joint Committee of the ESAs (EBA, ESMA, EIOPA). Designation criteria include: number and type of financial entities using the provider, systemic importance and substitutability, and cross-border relevance. The first 19 CTPPs were designated in November 2025. Designation triggers the full DORA oversight regime: allocation to a lead overseer, mandatory cooperation with oversight exercises, and sanctions exposure. Financial entities must update their Register of Information and contractual arrangements to reflect each provider's CTPP status.
Yes — each in-scope entity within a group must comply with DORA individually. An EU subsidiary of a non-EU banking group cannot rely on group-level compliance unless the group framework fully satisfies each DORA requirement for that entity specifically. Intra-group ICT service arrangements are permitted, but parent-subsidiary contracts must still meet Article 30 contractual requirements. For large banking groups under ECB supervision, the SREP reviews DORA compliance at both consolidated and individual entity level.
The Register of Information (Article 28(3)) is a structured inventory of all contractual arrangements with ICT third-party service providers. It records: provider identity, services contracted, classification as critical or important function, contractual dates, and sub-outsourcing chains. The ESAs published a mandatory data template in early 2025. Entities submitted the register to their national competent authority by 30 April 2025. The ESAs aggregate the data to identify systemic concentration risk across the EU financial sector. The register is not public, but regulators have full access — and share relevant data with the ESAs for systemic analysis.
Yes. DORA does not require fault or direct causation for all enforcement actions. Penalties can be applied for: failure to have adequate ICT risk management processes that would have detected or mitigated the incident; failure to report within the required timelines; or failure to maintain adequate contractual protections with the third party that caused the disruption. Competent authorities assess the quality of the institution's response and preparedness — not just the origin of the incident. A third-party outage that causes major service disruption, combined with no documented incident response plan, creates dual enforcement exposure.
DORA does not require or preclude ISO 27001 certification or NIST CSF adoption. Both frameworks map well to DORA requirements — ISO 27001 aligns strongly with Pillar 1 (ICT Risk Management), and NIST CSF's Detect/Respond/Recover functions align with Pillars 2 and 3. However, they are not substitutes for DORA compliance. Regulators expect entities to demonstrate compliance specifically against DORA RTS requirements, not against third-party certifications. ISO 27001 certification can support your DORA compliance case but does not replace the requirement to meet DORA's specific obligations.
DORA Article 5 makes the management body — the board of directors or equivalent — directly accountable for the ICT risk management framework. Specific legal obligations include: approving and annually reviewing the framework; allocating adequate ICT security budget; receiving regular ICT risk reports; and approving the TLPT programme. Supervisors will interview board members during SREP assessments on DORA compliance. This is not a governance best practice — it is a hard legal requirement. Senior managers can face personal fines of up to €1,000,000 under Article 50(4)(b). Delegation to CISO or IT leadership without board oversight does not discharge liability.
Use our free tools to assess your current state, identify gaps, and build your compliance roadmap.
Free DORA Assessment Gap Analysis Tool All RTS & ITS StandardsTake our free 5-minute assessment and get an instant DORA compliance score with personalised recommendations.