DORA Is in Active Enforcement and 44% of Financial Institutions Still Have Gaps. Here's What Supervisors Are Finding — and What Your Program Needs to Fix Before They Get to You.

TL;DR

• DORA entered active enforcement in January 2026. Supervisory reviews in H1 2026 are surfacing structural compliance gaps at institution after institution — not edge cases, systemic patterns.
• 44% of financial institutions still miss DORA requirements as of mid-2026. The Register of Information is the hardest: 46% of entities identified it as their biggest challenge, and empty exit strategy fields are the most common finding.
• In November 2025, the ESAs designated 19 Critical ICT Third-Party Providers — including AWS, Google Cloud, Microsoft, Oracle, SAP — subjecting them to direct ESA oversight. Financial entities using them face heightened concentration risk documentation obligations.
• The first formal enforcement actions are expected in H2 2026. Regulators are asking for evidence, not plans.

DORA has been in force since January 17, 2025. That means the grace period is over, the remediation-plan window is closed, and what supervisors are looking at now is whether you can demonstrate compliance — not whether you intend to achieve it.

Fourteen months of supervisory activity has produced a consistent finding: most financial entities achieved surface-level compliance at best. The Register of Information isn’t complete. Exit strategies are theoretical. Concentration risk is underestimated. Resilience exercises rarely include third parties in any meaningful way.

These aren’t obscure edge cases. They’re the patterns the supervisors are finding across institutions. If your program addressed DORA at the requirements level without stress-testing the evidence of compliance, there’s a good chance you’re in the same bucket.

The enforcement escalation is real. Advisori’s 2026 analysis puts it starkly: 44% of financial institutions are missing DORA requirements, and the supervisory environment has moved from awareness to active enforcement.

What DORA Covers — and Who It Reaches

DORA applies to “financial entities” as defined under EU law. The list is long: credit institutions, payment institutions, e-money institutions, investment firms, insurance undertakings, crypto-asset service providers under MiCA, fund managers, crowdfunding service providers, and others with EU regulatory authorizations.

If your fintech operates a European subsidiary with an EU payment institution or e-money license, that entity is directly subject to DORA. If your US-domiciled company provides ICT services to EU-licensed financial entities, DORA’s third-party provisions may apply to those service arrangements even without a direct EU authorization.

The ICT third-party provisions are among the most far-reaching parts of DORA. Articles 28–30 impose due diligence, contractual, and monitoring requirements on any ICT service arrangement supporting critical or important functions — and require financial entities to ensure those requirements flow through their entire third-party ICT supply chain.

The Register of Information: The Gap Nobody Fixed

The Register of Information is DORA’s mandatory inventory of all ICT third-party contractual arrangements. Every vendor relationship that involves ICT services needs to be documented with specific fields:

• Service description and scope
• Criticality classification (critical/important function vs. non-critical)
• Nature of the data processed
• Sub-outsourcing arrangements (fourth parties in your ICT chain)
• Geographic location of data and data processing
• Concentration risk assessment
• Exit strategy summary

Supervisory reviews through 2025 and into 2026 have consistently flagged Articles 28–30 as the single biggest source of compliance gaps, driven almost entirely by incomplete registers and missing criticality classifications.

The two most common specific failures:

Empty exit strategy fields. Nearly every regulated institution has started a Register. Far fewer have completed the exit strategy column for anything beyond the most obvious vendors. Supervisors treat an empty exit strategy field as simultaneously a validation error (the register is technically incomplete) and a substantive compliance gap (the exit plan doesn’t exist). These aren’t treated as equivalent failures — both are noted.

Criticality classification inconsistencies. Entities are under-classifying ICT services as non-critical to avoid the full compliance burden of critical function requirements. Supervisors are pushing back on classifications that look suspiciously convenient — if an ICT service supports a function whose disruption would materially impair your operations or customer service, the “non-critical” classification needs to be defensible.

The overall result: 46% of financial entities identified completing the Register of Information as the single most challenging DORA requirement, and most programs that have completed a register haven’t validated it against actual contractual rights or technical feasibility.

The 19 Critical ICT Third-Party Providers

On November 19, 2025, the ESAs published their first list of Critical ICT Third-Party Providers (CTPPs) under Article 32 of DORA. The 19 designated CTPPs include the major hyperscaler cloud providers — Amazon Web Services, Google Cloud, Microsoft — as well as Oracle, SAP, and Deutsche Telekom.

CTPP designation means these providers are subject to direct oversight by Joint Examination Teams (JETs) composed of staff from the ESAs and national competent authorities. JETs have authority to conduct annual risk analyses, comprehensive reporting obligations, on-site inspections, and active cooperation requirements.

For financial entities using these providers, CTPP designation has a practical consequence: it reinforces the concentration risk documentation and exit strategy requirements. If your critical infrastructure runs on AWS or Microsoft, and your Register of Information says “exit strategy: evaluate alternatives,” that’s not a credible exit plan under DORA, and supervisors will read your CTPP concentration as an aggravating factor when they assess your risk profile.

The ESAs’ annual collective assessment by the Oversight Forum will produce best and worst practices shared across supervised entities — meaning findings from CTPP oversight will eventually inform expectations for all financial entities, not just those with direct JET interactions.

Exit Strategies That Don’t Hold Up

DORA’s exit strategy requirement is where the gap between paper compliance and substantive compliance is most visible.

Article 28(8) requires documented exit strategies for ICT services supporting critical or important functions. The regulation is clear about what “documented and credible” means: a credible exit plan must reflect actual contractual rights, technical feasibility, and operational resources.

The DORA exit strategy guidance identifies the most common failure pattern: exit strategies that cite contractual rights that don’t actually exist in the contract. A right-to-exit clause paired with no data export rights is an exit plan that can’t be executed. A migration plan that assumes engineering capacity the institution doesn’t have is theoretical. Supervisors probe exactly this — not whether an exit strategy document exists, but whether it could actually be executed.

The stress test for a credible exit strategy:

1. Does the contract include explicit data portability and export rights?
2. Can you migrate the workload to an alternative provider in a defined timeframe?
3. Do you have the technical staff, documentation, and budget to execute the migration?
4. Have you tested any component of this — tabletop exercise, partial migration, architecture review?

If the honest answer to any of those is “not really,” the exit strategy doesn’t satisfy DORA’s requirement.

Concentration Risk Is Systematically Underestimated

The concentration risk dimension of DORA is about more than individual vendor dependency. DORA requires financial entities to assess concentration risk both at the entity level (your own over-reliance on a single provider) and at the sector level (recognizing that if multiple financial institutions rely on the same critical provider, a failure creates systemic risk).

Supervisory reviews have found that concentration risk is consistently underestimated — institutions count their own vendor relationships but don’t adequately account for cross-sector dependencies. If your institution, your core processing vendor, your fraud platform, and your cloud infrastructure all rely on the same hyperscaler, your actual concentration risk is substantially higher than your entity-level vendor count suggests.

The FSB’s August 2026 warning to G20 finance ministers made the same point at the systemic level: frontier AI is amplifying risk specifically through concentrated critical third-party technology providers. DORA’s concentration risk documentation requirement is designed to force visibility into exactly this dynamic.

ICT Risk Management Gets the Worst Scores

The European Central Bank’s supervisory assessment data shows ICT risk management receiving the worst average scores in the SREP (Supervisory Review and Evaluation Process) across all risk categories. The IBM analysis summarizes the finding: “operational risk and ICT risk continue to receive the worst average scores in the SREP.”

This isn’t a coincidence. ICT risk management is hard to demonstrate because it requires:

• A risk assessment methodology that’s applied consistently across your ICT asset inventory
• Evidence that identified risks are mapped to controls and that controls are tested
• An incident classification system that aligns with DORA’s taxonomy
• Board and senior management oversight that’s documented and attributable to specific decisions

The gap between having an ICT risk management policy and having an ICT risk management program that produces auditable evidence of those activities is exactly what supervisors are finding. The policy exists. The evidence doesn’t.

What to Fix Before the First Enforcement Wave

The DORA enforcement timeline puts the first formal actions in H2 2026 — which is now. Regulators are expecting evidence, not remediation timelines.

If your Register of Information has empty fields or placeholder exit strategies, those need to be completed with real content. That means:

• Reviewing each ICT contract to document actual data portability and export rights
• Identifying whether a migration plan can be executed against the contractual terms and your technical capacity
• Classifying each arrangement as critical, important, or neither — with documented reasoning

If your concentration risk assessment is an entity-level vendor count, it needs to expand to include cross-provider dependencies and sector-level concentration in your critical ICT infrastructure.

If your ICT risk management program produces policies but not evidence, the audit trail gap needs to be addressed. Supervisors will ask for the risk assessment methodology, the control mapping, and the testing records — not the policy document.

If your resilience testing doesn’t include third parties, it needs to. DORA requires that ICT-related incident reporting, response, and recovery procedures include the third parties supporting critical functions. A tabletop exercise that tests internal recovery without including the vendors who need to participate in that recovery is not DORA-compliant.

The DORA third-party ICT risk requirements — the contractual obligations under Articles 28–30 and the Register of Information framework — are the starting point, and they were the subject of significant implementation guidance at DORA’s January 2025 launch. For institutions that haven’t revisited those requirements since the initial build-out, the supervisory findings suggest the implementation fell short of the evidence standard.

For US fintechs building TPRM infrastructure that could serve EU operations, the structure is similar to OCC Bulletin 2023-17’s lifecycle model but adds the Register of Information, criticality classification, and documented exit strategy requirements. Our operational resilience vs. business continuity analysis covers the regulatory shift away from traditional BCP toward DORA-style operational resilience frameworks.

So What?

DORA’s active enforcement phase is producing consistent findings. The institutions that are faring better in supervisory reviews are the ones that treated DORA’s requirements as evidence-production exercises, not policy exercises. A complete Register of Information with defensible exit strategies. Concentration risk assessed at the system level, not just the entity level. ICT risk management that produces records, not just policies.

For EU-exposed fintechs, the question isn’t whether supervisory review is coming. It’s whether the program can demonstrate compliance when it does.

The Third-Party Risk Management (TPRM) Kit at RiskTemplate includes ICT vendor risk tiering methodology, due diligence questionnaires, contract review checklists, ongoing monitoring frameworks, and exit planning templates — built for risk and compliance teams managing complex vendor ecosystems across jurisdictions.