The Digital Operational Resilience Act (DORA) is an EU regulation that requires financial institutions to withstand, respond to, and recover from ICT-related disruptions and threats. It entered into application on January 17, 2025 and applies to banks, insurers, investment firms, payment institutions, and their ICT third-party providers, including non-EU firms with EU operations or EU-facing services.
The initial period of supervisory tolerance is over. National Competent Authorities across EU member states are conducting active supervisory reviews, and enforcement actions are live.
Financial institutions now face a sharper question than compliance: whether their program is auditable, evidenceable, and built to withstand active supervisory examination. This article covers what DORA requires, where institutions are finding gaps, and what compliance looks like in 2026.
- Who Does DORA Apply To?
- What Does DORA Actually Require? Understanding DORA’s 5 Key Compliance Obligations
- What DORA Enforcement Looks Like in 2026
- The Register of Information: What It Is and Why It's Hard
- Critical Third-Party Providers: The ESA Supervisory Framework
- Where Organizations Are Struggling in 2026
- What a Program Built for Continuous Operation Looks Like
- Frequently Asked Questions
Who Does DORA Apply To?
DORA applies to a wide range of financial entities operating within the EU, including banks and credit institutions, insurance and reinsurance companies, investment firms, payment institutions and e-money institutions, crypto-asset service providers, central counterparties and trading venues, and credit rating agencies and audit firms under certain conditions.
DORA applies to any entity providing financial services within the EU, including non-EU firms operating in EU markets. UK, US, and global financial institutions with EU operations or EU-facing services are in scope.
What Does DORA Actually Require? Understanding DORA’s 5 Key Compliance Obligations
DORA organizes its requirements across five domains, each carrying distinct obligations and, in 2026, varying degrees of supervisory scrutiny.
-
ICT Risk Management and Governance
Under DORA, the management body owns the ICT risk framework. That means a documented digital resilience strategy, defined risk tolerance, a complete asset inventory, security policies, and regular employee awareness training. It also means board-level oversight that is evidenceable, not nominal. In 2026, NCAs are examining whether boards can demonstrate active engagement with ICT risk, not simply whether a governance structure exists on paper.
-
Incident Response and Reporting
Organizations must maintain a clear incident response plan covering classification, reporting procedures, and communication to affected users. Major ICT incidents must be reported to the relevant NCA in three stages: initial notification within four hours of classification, an intermediate report within 72 hours, and a final report within one month, per RTS 2025/301. The operational challenge is classification: determining in real time whether an incident crosses the NCA notification threshold requires procedures that have been tested against actual scenarios (not just documented).
-
Digital Operational Resilience Testing
DORA requires a testing framework covering regular basic ICT testing and, for significant entities, advanced Threat-Led Penetration Testing aligned to the TIBER-EU methodology under Article 26. Weaknesses identified through testing must be addressed through documented remediation. Supervisors are no longer accepting acknowledgment of the TLPT obligation as evidence.
-
Third-Party Risk Management
Organizations must assess the security controls of ICT third-party providers and ensure contracts include a full service-level description, data location disclosures, audit rights, and exit-strategy provisions. Organizations must also maintain a Register of Information covering all ICT third-party contracts categorised by criticality, and actively manage concentration risk where multiple critical functions depend on a single provider. The Register is submitted to the NCA, must be maintained continuously under Article 28(3), and must be submission-ready at all times. NCAs can request it outside the annual cycle without a fixed lead time.
-
Information and Intelligence Sharing
DORA encourages financial entities to participate in trusted communities for threat intelligence sharing, coordinating on emerging ICT risks and vulnerabilities to reduce systemic exposure across the financial sector. This is the least prescriptive of the five domains and the least supervisory-attention-generating — participation supports the compliance posture regulators expect, but it is not where NCA examinations are focused in 2026.
What DORA Enforcement Looks Like in 2026
NCAs have moved from supervisory tolerance into active review. For ECB-supervised institutions, the publication of the ECB Guide on Outsourcing Cloud Services in July 2025 removed the ambiguity that allowed for interpretive latitude. The Guide covers all forms of cloud outsourcing, IaaS, PaaS, and SaaS, across public, private, and hybrid environments, with supervisory reviews measured against it.
National authorities began issuing formal NIS2 supervisory actions in 2026, marking the directive’s shift from implementation to enforcement. The direction of regulatory travel is consistent: the grace period for digital resilience obligations is over.
A DORA compliance program that was adequate for January 2025 may not be adequate for a supervisory examination in 2026. Regulators are not checking whether controls exist, but whether controls are working, are continuously maintained, and are evidenceable on demand.
The Register of Information: What It Is and Why It’s Hard
The Register of Information is a mandatory, structured record of every contractual arrangement that a financial entity holds with third-party ICT service providers. The register goes to your NCA. It is not an internal document.
Under DORA, financial entities must maintain the register continuously, keep it current, and submit it to their National Competent Authority annually. NCAs consolidate and forward the data to the European Supervisory Authorities — the EBA, EIOPA, and ESMA — for oversight purposes. The first submission cycle ran in early 2025. The 2026 cycle, covering data as at 31 December 2025, ran across EU member states through the first quarter of 2026.
The register is structured around a standardized template set by the ESAs under Commission Implementing Regulation (EU) 2024/2956. At a minimum, each entry must capture the provider’s identity (including a valid LEI or EU-ID), a description of services provided and their criticality classification, data storage and processing locations, sub-outsourcing arrangements, relevant contractual terms, and an assessment of the provider’s substitutability.
For most financial institutions, building and maintaining a complete, accurate register requires vendor data governance that legacy TPRM programs weren’t designed for.
The most common failure points:
- LEI codes are missing for vendors whose contracts predate the requirement
- No visibility into sub-outsourcing chains beyond the first tier
- Criticality classifications that don’t update when business functions change
- Validation errors at submission that aren’t caught before NCA deadlines
Organizations managing this at scale should look for solutions that automate vendor data collection, flag LEI gaps before submission, and surface sub-outsourcing dependencies across the full contract population.
Your Register of Information Is a Live Supervisory Instrument.
Keep It That WayNCA expectations on data quality are increasing with each cycle. The ESAs have been explicit that the register is a live supervisory instrument. NCAs may also request it outside the annual submission cycle as part of supervisory reviews or thematic exercises, with response terms set at the point of request. Organizations that treat the register as an annual filing rather than a continuously maintained dataset will not be able to meet that obligation.
Critical Third-Party Providers: The ESA Supervisory Framework
DORA’s third-party risk framework includes a layer of oversight that operates independently of the requirements imposed on individual financial entities. For the ICT providers most systemically important to the EU financial sector, DORA establishes a direct supervisory regime operated by the European Supervisory Authorities.
These providers are designated as Critical Third-Party Providers (CTPPs). As of October 2025, 19 ICT third-party providers have been formally designated by the ESAs. These are major cloud platforms and technology infrastructure providers whose services underpin significant portions of the EU financial system.
CTPP designation means direct oversight by a Lead Overseer ESA (EBA, EIOPA, or ESMA, depending on the provider’s primary financial sector), mandatory cooperation with that overseer, including onsite inspections and audit access, and obligation to address recommendations within defined timeframes. Periodic penalty payments apply for non-cooperation.
For financial entities that use designated CTPPs, the key point is this: ESA oversight of your provider does not replace your own compliance obligations. The ECB has been explicit on this. CTPP designation does not substitute for contractual protections or due diligence. If a provider you rely on holds CTPP status, review your contractual arrangements against DORA’s requirements, including audit rights, exit provisions, and data location transparency. Concentration risk obligations apply with particular force where a CTPP is involved.
DORA is in active enforcement.
Download the third-party risk checklist.Where Organizations Are Struggling in 2026
Active supervisory review is surfacing consistent gaps across institutions. The most common areas of exposure:
- Vendor registration completeness remains a problem. Many organizations do not hold a comprehensive, categorized record of all ICT third-party contracts at the level of detail DORA requires, especially for contracts predating the regulation’s implementation.
- Incident classification processes lack operational consistency. Determining in real time whether an incident crosses the NCA notification threshold is difficult without clear internal procedures that are tested against real scenarios.
- Concentration risk visibility is incomplete. Identifying over-reliance on a small number of critical ICT providers requires cross-portfolio visibility that many organizations are still developing.
- Multi-jurisdiction program consistency is a structural challenge for multinationals. Different NCAs apply supervisory expectations at varying rates, and maintaining a consistent program across member states adds operational complexity.
- TLPT completion is lagging. Many organizations that acknowledged the testing obligation in 2025 have not yet completed a full cycle.
What a Program Built for Continuous Operation Looks Like
The organizations best positioned for supervisory review are not those that scrambled to meet the January 2025 deadline. They built programs designed for continuous operation. They produce evidence of compliance as a natural output of how the program runs, rather than something assembled in response to a supervisory request.
That means continuous vendor monitoring rather than annual point-in-time assessments. It means incident classification criteria that are tested against real scenarios, not just documented. It means a Register of Information that reflects live contractual arrangements and is updated as contracts change. And it means third-party oversight that doesn’t end after initial onboarding.
Managing this manually across five domains, multiple jurisdictions, and dozens or hundreds of ICT vendors isn’t sustainable for most organizations. The right technology infrastructure centralizes compliance data, automates monitoring and assessment workflows, and provides compliance teams with a consolidated view of program health at any time.
If you’re assessing where your program stands, the most useful starting point is a gap assessment across the five domains, measured against the standard a supervisor would apply today.
Align Your DORA Program Across IT, Risk, and Compliance.
See the PlatformFrequently Asked Questions
What is DORA?
DORA stands for the Digital Operational Resilience Act.
It is an EU regulation that requires financial institutions to manage ICT risks and demonstrate operational resilience to digital disruptions. It applies to banks, insurers, investment firms, payment institutions, crypto-asset service providers, and their ICT third-party providers. Non-EU firms with EU operations or EU-facing services are also in scope.
What are DORA’s five pillars?
DORA is structured around five domains: ICT risk management and governance, incident response and reporting, digital operational resilience testing, third-party risk management, and information and intelligence sharing. Each domain carries specific obligations; third-party risk management and the Register of Information have attracted the most supervisory attention since enforcement began.
What is the DORA Register of Information?
The Register of Information is a mandatory regulatory submission that catalogs all of a financial entity’s third-party ICT contracts, classified by criticality. It must include provider identities (with LEI codes), service descriptions, data locations, sub-outsourcing arrangements, and contractual terms. It is submitted annually to the relevant National Competent Authority and then consolidated by the European Supervisory Authorities.
What is a Critical Third-Party Provider under DORA?
A Critical Third-Party Provider (CTPP) is an ICT service provider formally designated by the European Supervisory Authorities as systemically important to the EU financial sector. As of October 2025, 19 providers have been designated. CTPPs are subject to direct ESA oversight, including inspections and audit rights. Financial entities that use CTPPs retain their own DORA compliance obligations regardless of the provider’s designated status.
Is DORA being enforced in 2026?
Yes. The initial period of supervisory tolerance ended after DORA’s January 2025 application date. Financial entities face administrative fines for material non-compliance; the specific penalty framework varies by entity type and is set out in Articles 50 to 54 of Regulation (EU) 2022/2554. National Competent Authorities are conducting active supervisory reviews, and the ECB published its cloud outsourcing guidance in July 2025.
