EU DORA: a complete guide to Regulation (EU) 2022/2554

Modern banks, insurers and payment firms run on software. When that software fails — an outage, a cyberattack, a data leak — customers can lose access to their money, and the shock can spread across the financial system. DORA is the EU’s rulebook that forces every regulated financial firm to prevent, survive and recover from technology failures — and, uniquely, lets EU regulators directly inspect the giant tech suppliers (the big cloud providers, SWIFT) the whole sector leans on. Think of it as fire-safety codes, but for the financial system’s IT: every firm needs alarms, drills and backups, and the shared wiring everyone depends on gets inspected too.

The EU Digital Operational Resilience Act (DORA) is the law that sets out, for the first time across all 27 Member States, what every regulated financial entity in Europe must do to prevent, withstand, recover from and learn from ICT (information and communication technology) disruptions. Until DORA, ICT-resilience requirements lived in dozens of overlapping sectoral guidelines — EBA, ESMA and EIOPA (the EU’s three financial watchdogs — for banking, securities markets, and insurance/pensions respectively) each had their own; national supervisors layered theirs on top; and most rules were “should” rather than “shall”. DORA replaces that landscape with one binding, harmonised regime that applies to banks, insurers, investment firms, crypto-asset service providers, payment institutions, central counterparties (clearing houses that stand between the buyer and seller of a trade and guarantee it settles), trading venues, fund managers and 13 more categories — plus, uniquely, direct EU-level oversight of the largest ICT third-party service providers that those financial entities depend on (the hyperscale cloud platforms — Amazon, Microsoft and Google’s clouds; the SWIFT bank-to-bank messaging network; the big core-banking systems that run accounts and payments).

If you are a financial entity established in the EU, or you provide ICT services on which EU financial entities critically rely, this Regulation applies to you. DORA entered into force on 16 January 2023 and started to apply on 17 January 2025. The first list of 19 Critical ICT Third-Party Providers (CTPPs) — tech suppliers judged so systemically important that EU regulators oversee them directly, not just the financial firms that depend on them — was published by the European Supervisory Authorities (the ESAs — EBA, ESMA and EIOPA acting jointly) on 18 November 2025.

This page is the canonical klarproof guide — every key claim is sourced directly to EUR-Lex, the European Banking Authority (EBA), the European Securities and Markets Authority (ESMA), or the European Insurance and Occupational Pensions Authority (EIOPA).

Quick facts

• Full name: Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector
• Companion directive: Directive (EU) 2022/2556 — amends eight sectoral financial-services directives (UCITS 2009/65/EC, Solvency II 2009/138/EC, AIFMD 2011/61/EU, CRD IV 2013/36/EU, BRRD 2014/59/EU, MiFID II 2014/65/EU, PSD2 2015/2366, IORP II 2016/2341) to align them with DORA
• Adopted: 14 December 2022
• Published in OJ: 27 December 2022
• Entered into force: 16 January 2023 (twentieth day after publication, per Article 64)
• Started to apply: 17 January 2025
• In scope: 20 categories of “financial entities” as defined in Article 2(2) — credit institutions, payment and e-money institutions, investment firms, CCPs, CSDs, trading venues, asset managers, insurers, reinsurers, intermediaries, IORPs, credit-rating agencies, benchmark administrators, crypto-asset service providers, crowdfunding service providers, account information service providers and others — plus a 21st category of in-scope addressee under Article 2(1)(u): ICT third-party service providers (subject to the oversight regime when designated as Critical)
• Penalties: for Critical ICT Third-Party Providers (CTPPs) under Article 35, periodic penalty payments up to 1% of the average daily worldwide turnover of the preceding business year, accruing daily for up to six months; for financial entities, sanctions are imposed by national competent authorities under sectoral laws (banking, insurance, securities), often referencing fixed-amount caps or a percentage of turnover
• Coordinating EU bodies: the three European Supervisory Authorities (ESAs) — EBA (banking), ESMA (markets), EIOPA (insurance and pensions) — acting through their Joint Committee for sector-spanning matters and through a Oversight Forum for the CTPP regime
• National enforcement: by each Member State’s banking, securities and insurance supervisors (BaFin, AMF, ACPR, CONSOB / Bank of Italy, CNB, Finantsinspektsioon, etc.)

What DORA actually does

DORA does two things at the same time. It is one law, but the addressees are different:

1. It tells every regulated financial entity in the EU how to manage ICT risk (the chance that a technical failure, cyberattack or data breach disrupts the entity’s operations, finances or reputation) — from board-level governance, through technical controls and incident reporting, to mandatory penetration testing of the most critical systems and rigid contractual rules for outsourced ICT services.
2. It puts the largest non-financial ICT vendors under direct EU oversight — the hyperscale cloud providers, SWIFT, payment-rails operators, core-banking platforms — through a designation process run by the ESAs and a “Lead Overseer” with quasi-supervisory powers (information requests, on-site inspections, recommendations, periodic penalty payments).

DORA is horizontal across the financial sector but vertical against ICT vendors. That’s the architectural choice that makes the regime distinctive.

It does not replace GDPR (which still governs the personal data flowing through these systems) or the NIS 2 Directive (which governs cybersecurity of essential and important entities economy-wide). The three regimes apply in parallel: a payment-services breach can trigger DORA incident-reporting (to your national financial supervisor), GDPR breach-notification (to your DPA, within 72 hours), and NIS 2 reporting (to your national cybersecurity authority) — all from the same incident, all on different forms, all with their own deadlines.

In scope: who DORA applies to (Article 2)

DORA applies to 20 categories of “financial entity” (Article 2(2) defines points (a)–(t) collectively as “financial entities”) plus a 21st category of in-scope addressee — ICT third-party service providers (Article 2(1)(u)) — that is subject to the oversight regime once designated as Critical. The list is broader than most non-specialists expect:

• Credit institutions
• Payment institutions, including those exempted under PSD2
• Account information service providers
• Electronic-money institutions, including those exempted under EMD2
• Investment firms
• Crypto-asset service providers (CASPs) authorised under MiCA and issuers of asset-referenced tokens
• Central securities depositories (CSDs)
• Central counterparties (CCPs)
• Trading venues (regulated markets, MTFs, OTFs)
• Trade repositories
• Managers of alternative investment funds (AIFMs)
• Management companies (UCITS)
• Data reporting service providers (DRSPs)
• Insurance and reinsurance undertakings
• Insurance, reinsurance and ancillary insurance intermediaries
• Institutions for occupational retirement provision (IORPs)
• Credit rating agencies
• Administrators of critical benchmarks
• Crowdfunding service providers
• Securitisation repositories
• ICT third-party service providers (only when designated as Critical ICT Third-Party Providers — see below)

Exclusions and proportionality

Article 2(3) and 2(4) carve out a small number of cases from the full DORA regime:

• AIFMs that meet the small-AIFM thresholds in Article 3(2) of the AIFMD
• Insurance and reinsurance undertakings that fall below the Solvency II thresholds in Article 4 of Directive 2009/138/EC (the small-undertakings exemption: gross written premium income ≤ €5 million, gross technical provisions ≤ €25 million, no cross-border or specified-class business)
• Insurance and reinsurance intermediaries that qualify as microenterprises or small or medium-sized enterprises (SMEs)
• IORPs operating pension schemes with fewer than 15 total members
• Persons exempted under Article 2 or 3 of MiFID II
• Post-office giro institutions

Beyond these full carve-outs, DORA itself is built around a proportionality principle (Article 4): a microenterprise financial entity is not expected to run the same governance, testing or third-party-risk machinery as a global investment bank. Most of the substantive Articles include simplified regimes for smaller entities.

The five pillars

DORA’s substantive obligations sit in five chapters of the Regulation. Each chapter is one of the “five pillars” that every implementation manual references:

Pillar 1 — ICT risk management (Chapter II, Articles 5–16)

Every in-scope financial entity must adopt an ICT risk management framework approved by, and overseen by, the management body. The framework must cover the identification, protection, detection, response and recovery functions across the entire ICT estate — applications, systems, data, networks, end-points, third-party connections.

Concretely, this requires:

• Documented ICT risk policies, procedures, protocols and tools proportionate to the entity’s risk profile
• Identification of all ICT-supported business functions, roles, responsibilities and information assets, mapped to the supporting ICT infrastructure
• Continuous monitoring for anomalous activity
• A business continuity policy with response and recovery plans tested at least annually
• A learning-and-evolving function — every major incident has to feed into the next iteration of the framework

The management body is explicitly accountable for ICT risk (Article 5(2)). DORA forecloses the “we delegated it to the CIO” defence: if the board did not understand the risk, that itself is a finding.

Pillar 2 — ICT-related incident management, classification and reporting (Chapter III, Articles 17–23)

Every in-scope entity must operate an ICT-related incident management process that detects, manages, records and resolves incidents — and, for those that meet the major-incident threshold, notifies the competent authority on a tight clock.

The reporting timeline (set out in Commission Delegated Regulation (EU) 2025/301 of 23 October 2024 — the RTS on content and time limits — adopted from the joint ESA technical standards JC 2024-33; the matching templates are in Commission Implementing Regulation (EU) 2025/302):

Stage	Deadline
Initial notification	Within 4 hours of classifying the incident as major; in any event no later than 24 hours after the entity becomes aware of the incident
Intermediate report	Within 72 hours of the initial notification, with updates provided without delay
Final report	Within 1 month of the intermediate (or updated intermediate) report

These timelines are intentionally aligned with the NIS 2 Directive so that a single incident does not produce conflicting deadlines, but DORA’s 4-hour clock is the most operationally pressured of the three EU incident-reporting regimes (DORA, NIS 2, GDPR Article 33). DORA also permits entities to voluntarily notify the competent authority of significant cyber threats that have not yet materialised into incidents (Article 19(2)) — this is a discretionary channel, not an obligation.

Pillar 3 — Digital operational resilience testing (Chapter IV, Articles 24–27)

Every in-scope entity must run a digital operational resilience testing programme, proportionate to its size and risk. There are two layers:

1. Standard testing — at least annually, covering all critical ICT systems: vulnerability assessments, scenario-based tests, performance and end-to-end tests, source-code reviews, penetration tests, network-security and physical-security tests.
2. Threat-Led Penetration Testing (TLPT) — every three years at minimum, only for entities identified by the competent authority as required to perform TLPT (Article 26(8)) on the basis of impact, financial-stability and ICT-risk-profile factors. TLPT means a controlled red-team exercise, executed by external, certified testers, against the entity’s live production environment, simulating the tactics, techniques and procedures of real adversaries. TLPT is built on the existing TIBER-EU framework, developed jointly by the ECB and the EU national central banks and published in May 2018. Article 26(7) DORA contemplates the mutual recognition of TLPT across Member States, with the detailed mechanics specified in Commission Delegated Regulation (EU) 2025/1190 — the RTS that lays down the criteria for identifying financial entities required to perform TLPT and the standards governing scope, methodology, testing phases and the conditions for mutual recognition.

TLPT is the single most expensive obligation in DORA. Significant institutions are typically credit institutions and CCPs above defined size and systemic-importance thresholds; CSDs, asset managers and trading venues may be brought in by Member State decision.

Pillar 4 — Managing of ICT third-party risk (Chapter V, Articles 28–44)

This is the chapter that re-shaped the financial sector’s relationship with its software and cloud vendors.

Every in-scope entity must:

• Maintain a register of information (RoI) — under Article 28(3) — of all contractual arrangements with ICT third-party service providers, by service line, by criticality, with sub-contracting chains traced. Financial entities must report at least yearly to the competent authority on the metadata of those arrangements (number of new contracts, categories of providers, types of contractual arrangements, services and functions provided). The full register is provided to the competent authority on request, in whole or in specified sections.
• Run a pre-contractual due-diligence before entering into any new arrangement — concentration risk, criticality, exit strategy, data location.
• Embed mandatory contractual clauses (Article 30) — service descriptions, security and continuity requirements, audit and inspection rights, sub-contracting controls, termination rights, data-portability and exit-assistance obligations, applicable law and jurisdiction. Standard cloud contracts that pre-date DORA have generally needed amendment.
• Treat the use of ICT services for “critical or important functions” as a heightened risk class with tighter contractual minimums.

Pillar 5 — Information-sharing arrangements (Chapter VI, Article 45)

DORA explicitly encourages and authorises voluntary information-sharing among financial entities about cyber threats, indicators of compromise, tactics and procedures — within trusted communities, subject to safeguards on competition law and personal-data protection. This is not an obligation; it is a permission, and it removes the previous legal uncertainty about whether entities could share threat intelligence without breaching antitrust rules. The financial-sector ISACs (FS-ISAC and the EU-level FI-ISAC) are the operational backbone.

Critical ICT Third-Party Providers (CTPPs)

The most novel feature of DORA is direct EU-level oversight of certain ICT vendors — even though those vendors are not, themselves, financial entities. This is the regime in Chapter V, Section II (Articles 31–44).

Designation

The three ESAs, acting through their Joint Committee, assess each ICT third-party service provider used by EU financial entities against four criteria set out in Article 31(2):

1. The systemic impact on the stability, continuity or quality of financial services if the provider failed.
2. The systemic character or importance of the financial entities that rely on the provider.
3. The reliance of those financial entities on the provider for critical or important functions.
4. The degree of substitutability of the provider — how easily its services could be replaced.

If the provider meets the criticality criteria across the financial system, the ESAs designate it as a Critical ICT Third-Party Provider (CTPP). The provider is then subject to the oversight regime described below.

First designations: 18 November 2025

The first batch of CTPPs was designated on 18 November 2025 by the ESAs Joint Committee. The 19 designated providers (alphabetical, exactly as listed in the official Joint Committee list under Article 31(9)) — each with its category and what it provides is in our living DORA CTPP register:

• Accenture plc
• Amazon web Services EMEA Sarl
• Bloomberg L.P.
• Capgemini SE
• Colt Technology Services
• Deutsche Telekom AG
• Equinix (EMEA) B.V.
• Fidelity National Information Services, Inc.
• Google Cloud EMEA Limited
• International Business Machine Corporation
• InterXion HeadQuarters B.V.
• Kyndryl Inc.
• LSEG Data and Risk Limited
• Microsoft Ireland Operations Limited
• NTT DATA Inc.
• Oracle Nederland B.V.
• Orange SA
• SAP SE
• Tata Consultancy Services Limited

Across the list, four practical groupings stand out: hyperscale cloud (AWS, Google Cloud, Microsoft, Oracle), telecom and data-centre infrastructure (Colt, Deutsche Telekom, Equinix, InterXion, Orange), IT services and systems integrators (Accenture, Capgemini, IBM, Kyndryl, NTT DATA, Tata Consultancy Services), and specialised financial-services and enterprise-technology providers (Bloomberg, FIS, LSEG Data and Risk, SAP).

Designations are reviewed annually; new providers can be added, and providers that have lost criticality can be de-designated.

Lead Overseer and Oversight Forum

For each CTPP, the ESAs designate a Lead Overseer — one of EBA, ESMA or EIOPA, depending on which financial sector relies on the CTPP most. The Lead Overseer:

• Conducts the day-to-day oversight engagement
• Issues information requests, conducts on-site inspections, audits and IT investigations (Articles 36–38)
• Adopts recommendations to the CTPP — to remediate findings, modify contractual practices, mitigate concentration risk
• Can impose periodic penalty payments of up to 1% of the CTPP’s average daily worldwide turnover in the preceding business year, accruing daily for a maximum of six months (Article 35), to compel compliance

The day-to-day work — investigations, on-site inspections, evidence gathering, recommendation drafting — is carried out by a joint examination team (JET) established for each CTPP under Article 40. The JET is staffed jointly by the three ESAs and the relevant national competent authorities supervising financial entities that depend on the CTPP, and assists the Lead Overseer throughout the oversight cycle. The Lead Overseer is the formal decision-maker; the JET is the operational vehicle.

The Oversight Forum sits one level above: a sub-committee of the ESAs Joint Committee that coordinates cross-sector oversight, shares intelligence, harmonises the recommendations issued to CTPPs and feeds back on JET findings.

Sub-contracting and concentration risk

A CTPP that subcontracts critical services has to disclose the chain to the Lead Overseer, and DORA’s Article 30 contractual minimums flow down to the sub-contractors. Concentration risk — the dependency of a large share of the EU financial system on a small number of cloud providers — is one of the explicit policy concerns DORA addresses; the Lead Overseer can recommend that a CTPP modify its sub-contracting model if concentration risk is judged excessive.

Limits of the regime

DORA’s CTPP regime is oversight, not authorisation. Designated providers do not need a licence; they are not “regulated” in the financial-services sense. The Lead Overseer’s recommendations are not directly enforceable against the CTPP — but they are enforceable through the financial entities that contract with it, because financial entities are required to take Lead Overseer recommendations into account when negotiating, monitoring and (if needed) terminating their CTPP contracts. A CTPP that ignores recommendations risks being dropped by the very financial entities that made it critical.

Governance: who supervises and who enforces

DORA uses a layered governance model that mirrors the rest of EU financial regulation.

EU level

• The three European Supervisory Authorities — EBA (banking and payments), ESMA (markets, asset management, CRAs, benchmark administrators, CASPs), EIOPA (insurance and pensions). For DORA, they act:
  • Individually, as competent authorities over the entities in their existing remit
  • Jointly, through the Joint Committee, for cross-sector matters — adopting RTS/ITS, coordinating CTPP designations, running the Oversight Forum
• Lead Overseer — one of the three ESAs designated as the principal overseer of each CTPP, depending on which sector the CTPP most affects.

National level

Each Member State’s existing financial supervisors (banking, insurance, securities) supervise the application of DORA by the in-scope financial entities they already supervise:

• 🇩🇪 Germany — BaFin
• 🇫🇷 France — ACPR for banks/insurers, AMF for markets
• 🇮🇹 Italy — Bank of Italy, CONSOB, IVASS
• 🇮🇪 Ireland — Central Bank of Ireland
• 🇪🇪 Estonia — Finantsinspektsioon
• 🇫🇮 Finland — FIN-FSA (Finanssivalvonta)
• 🇱🇺 Luxembourg — CSSF
• 🇳🇱 Netherlands — DNB (prudential), AFM (conduct)

National supervisors handle authorisations, day-to-day prudential and conduct supervision, on-site inspections, and the imposition of administrative sanctions on financial entities.

Penalties and sanctions

DORA’s enforcement architecture has two distinct tracks:

Financial entities

For in-scope financial entities, DORA itself does not prescribe a uniform fine ceiling. Instead, sanctions are imposed by national competent authorities under the existing sectoral laws (Capital Requirements Directive, MiFID II, Solvency II, IDD, UCITS, AIFMD, PSD2, etc.). Article 50 requires Member States to ensure that competent authorities have, at a minimum, the power to:

• Issue public statements identifying the breach and the responsible person
• Order the cessation of the conduct in breach
• Impose administrative penalties — pecuniary and non-pecuniary

Member States are free to add criminal sanctions on top of administrative ones (Article 52).

In practice, the size of fines on financial entities for DORA breaches will be set by the relevant sectoral law: a credit institution will be fined under the CRD’s general framework; an investment firm under MiFID II’s Article 70; an insurer under the national IDD/Solvency II implementation. The structure is intentionally piggy-backing on existing sectoral enforcement frameworks rather than building a new cross-sector tariff.

Critical ICT Third-Party Providers

For CTPPs, DORA establishes its own pan-EU sanction: periodic penalty payments under Article 35.

Aspect	Provision
Imposed by	The Lead Overseer
Trigger	Failure to comply with an information request, an on-site inspection, or a remedial action requested by recommendation
Maximum amount	Up to 1% of the average daily worldwide turnover of the CTPP in the preceding business year
Accrual	Daily
Maximum duration	Six months
Procedural safeguard	The CTPP must be heard before the penalty is imposed (Article 35(11))

A six-month, daily-accruing penalty at the maximum rate is a substantial economic instrument against vendors whose annual turnover runs into the tens of billions of dollars. It is the lever the Lead Overseer holds against a CTPP that refuses to engage.

How DORA overlaps with other EU regimes

• GDPR (Regulation 2016/679) — applies to personal data flowing through ICT systems. A DORA major incident that involves a personal data breach also triggers Article 33 GDPR notification (within 72 hours, to the DPA). See our GDPR pillar.
• NIS 2 Directive (Directive (EU) 2022/2555) — cybersecurity obligations for “essential” and “important” entities economy-wide. DORA is lex specialis for the financial sector: where DORA applies, it displaces NIS 2 for the same entity (NIS 2 Article 4). Incident reporting timelines are aligned but the addressee authority differs.
• MiCA (Regulation 2023/1114) — CASPs and ART/EMT issuers are explicitly in scope of DORA. A CASP authorised under MiCA still has to run the full DORA framework. See our MiCA pillar.
• AI Act (Regulation 2024/1689) — financial entities deploying AI for credit scoring, pricing or underwriting are simultaneously deployers under the AI Act and ICT users under DORA. The two regimes overlap on third-party-risk and on incident-reporting expectations. See our AI Act pillar.
• PSD2 / PSD3 / PSR — payment-services regulation. DORA’s incident reporting absorbs most of PSD2’s old major-incident reporting duty for payment institutions.
• Cyber Resilience Act (Regulation (EU) 2024/2847) — cybersecurity requirements for products with digital elements placed on the EU market. CRA addresses the manufacturer of the software / hardware; DORA addresses the financial-sector user. The two regimes complement each other.

What this means for you

If you’re a financial entity in scope:

• Build a Register of Information (Article 28(3)) of every ICT contractual arrangement, classified by criticality and sub-contracting chain. The first annual submission to the competent authority is a hard milestone; many entities discovered in 2024–2025 that their existing inventories were incomplete.
• Re-paper your contracts. The Article 30 mandatory clauses are not negotiable. Cloud, SaaS and core-banking contracts signed before 2024 generally need addenda — many providers have published DORA-aligned templates, but make sure the Article 30(3) heightened clauses for “critical or important functions” are in place where the function meets that classification.
• Implement the incident classification methodology in Commission Delegated Regulation (EU) 2024/1772 — six criteria with quantitative thresholds — and run table-top exercises against the 4-hour / 72-hour / 1-month timeline.
• Plan TLPT if you are likely to be designated as significant. Engagements with certified red teams take 6–12 months; the test is followed by a 6–12 week remediation cycle.
• Read your CTPP recommendations. If the Lead Overseer issues a recommendation against a cloud provider you depend on, you have to take it into account in your contract management.

If you’re an ICT vendor selling to EU financial entities:

• Even if you are not designated as a CTPP, your financial-entity customers will require Article 30 contractual terms. Build a DORA-ready contract template once, deploy it across your customer base.
• Keep good records of sub-contracting chains. Customers will ask, and the Lead Overseer can ask through them.
• If you reach the scale where designation is plausible (large hyperscale cloud, large financial-services platform, critical messaging or settlement provider, large SaaS estate), engage early with the ESAs Joint Committee — designation criteria are public and the conversation is materially smoother before designation than after.
• A designated CTPP must accept on-site inspections by the Lead Overseer in the EU, and joint inspections with the relevant competent authorities. Build the playbook before the first inspection request lands.

If you’re a board member or senior manager of a financial entity:

• Article 5 places ICT risk explicitly with the management body. Failure of an ICT risk-management framework is a board-level finding, not just a CIO finding. Ensure board-level visibility, training, and accountability are documented.
• Board-approved ICT risk frameworks are reviewed at least annually and after every major incident.

TL;DR

DORA is the EU’s first comprehensive law on digital operational resilience for the financial sector, applied since 17 January 2025. It applies to 20 categories of “financial entities” (Article 2(2)) — banks, insurers, investment firms, CASPs, payment institutions, CCPs, CSDs, fund managers and more — plus a 21st in-scope category, ICT third-party service providers, subject to direct EU oversight when designated as Critical. Five pillars: ICT risk management (board-level accountability), incident management and reporting (initial notification within 4 hours of classifying as major, intermediate within 72 hours, final within 1 month), digital operational resilience testing including TLPT every three years for significant entities, ICT third-party risk with mandatory Article 30 contractual clauses and an annual Register of Information, and information-sharing arrangements within trusted communities. Most novel feature: direct EU oversight of large ICT vendors through the Critical ICT Third-Party Provider (CTPP) regime — first list of 19 CTPPs designated on 18 November 2025 — including the four hyperscale clouds (AWS, Google Cloud, Microsoft, Oracle), big IT integrators (Accenture, Capgemini, IBM, Kyndryl, NTT DATA, Tata Consultancy Services), telecom and data-centre infrastructure (Colt, Deutsche Telekom, Equinix, InterXion, Orange), and specialised providers Bloomberg, FIS, LSEG Data and Risk, and SAP. Each CTPP gets a Lead Overseer (EBA, ESMA or EIOPA) with information-request, on-site inspection and recommendation powers, backed by periodic penalty payments up to 1% of average daily worldwide turnover, accruing daily for up to six months. Sanctions on financial entities themselves are imposed by national supervisors under the existing sectoral regimes.

Sources

• Regulation (EU) 2022/2554 — full text on EUR-Lex — official source of DORA
• Directive (EU) 2022/2556 — companion amending directive — aligns eight sectoral financial-services directives with DORA
• EBA — DORA hub — joint technical standards, oversight role
• ESMA — DORA hub — markets-side coordination
• EIOPA — DORA hub — insurance-side coordination
• EIOPA announcement — ESAs designate CTPPs (18 November 2025)
• Joint ESA Final Report on incident reporting RTS — JC 2024-33
• Commission Delegated Regulation (EU) 2024/1772 — incident classification criteria
• Commission Delegated Regulation (EU) 2025/301 — RTS on content and time limits for major-incident reporting
• Commission Implementing Regulation (EU) 2025/302 — ITS templates for incident reporting
• Commission Delegated Regulation (EU) 2025/1190 — RTS on TLPT criteria and methodology
• Joint Committee of the ESAs — official list of designated CTPPs (18 November 2025)