Feature Third-Party Risk
DORA Article 28 in 2026: What US Financial Institutions with EU Operations Are Still Getting Wrong
DORA's transition year is over. Q1 2026 Register of Information submissions are under NCA review, 19 Critical ICT Third-Party Providers have been designated, and active enforcement has begun. Here's what US financial institutions with EU branches and subsidiaries are still getting wrong — and what to fix before supervisory follow-up arrives.
Table of Contents
TL;DR:
- DORA’s transition year is over. The Q1 2026 Register of Information submission was the first hard supervisory test — NCAs are now cross-referencing submitted data automatically to identify gaps.
- Nineteen Critical ICT Third-Party Providers were designated in November 2025, including AWS EMEA, Google Cloud EMEA, Microsoft Ireland Operations, Oracle, Bloomberg, and LSEG. Contracts with designated providers face enhanced oversight requirements and must meet Article 30’s full standard.
- US banks with EU branches or subsidiaries cannot treat DORA as a “local EU issue” — ICT services mutualized from US headquarters bring DORA obligations back to the parent.
- The most common Article 28 gaps in 2026: incomplete sub-outsourcing data, intragroup contracts missing mandatory fields, and Article 30 clauses that don’t meet the required standard on audit rights and exit strategies.
The Compliance Window Closed 17 Months Ago. NCAs Are Checking.
DORA became applicable on January 17, 2025. The regulation had been in force since January 2023, giving financial entities and their ICT providers two full years to prepare. Most compliance programs spent 2023 and 2024 building toward the deadline. Many got there. Many built something that looks compliant without meeting the actual data quality standards.
The Q1 2026 Register of Information submission was the first moment that changed. For the first time, national competent authorities (NCAs) received structured, machine-readable data on every in-scope ICT third-party relationship and ran automated cross-checks against it: providers absent from registers, inconsistencies between RoI entries and incident report history, sub-outsourcing chains showing no Tier 2 or Tier 3 providers for cloud deployments where those subcontractors are publicly documented.
For US financial institutions operating in the EU — whether through authorized branches, EU-chartered subsidiaries, or as ICT service providers to EU financial entities — the assumption that DORA is a “local compliance issue managed by the EU team” is itself a risk.
Here’s what’s still missing in 2026, and what the active enforcement environment means.
Who DORA Article 28 Actually Covers for US Firms
The 22,000 in-scope EU financial entities are the direct subjects of DORA. But the compliance footprint extends considerably further.
| Entity Type | DORA Article 28 Obligation |
|---|---|
| EU subsidiary of a US bank | Full DORA compliance — the subsidiary is an EU financial entity |
| EU branch of a US bank | Must apply DORA to EU branch operations; maintain RoI for EU-related ICT contracts |
| US bank providing ICT services to EU entities | Subject to CTPP oversight if designated; must cooperate with ESA oversight |
| US bank with ICT mutualized from US headquarters | EU entity is accountable; DORA requirements flow back to parent for EU-related services |
The mutualized services point is the one most commonly misunderstood. If a US-headquartered bank manages global contracts with AWS, Bloomberg, or a core banking vendor from New York — and those services also support the EU branch — the EU branch must register that contractual relationship in its own Register of Information, even if the contract is held at the parent level. Supervisors in the host member state will examine the EU entity’s compliance. The parent’s documentation must support the subsidiary’s register.
For EU branches, the host NCA has primary supervisory responsibility for DORA compliance. Branches that haven’t built a DORA-specific view of their ICT relationships — distinct from the parent’s global vendor inventory — are the ones generating supervisory inquiries in 2026.
The Register of Information: What the Q1 2026 Submissions Revealed
Article 28.3 requires every in-scope financial entity to maintain and regularly update a Register of Information covering all ICT third-party service arrangements. The register isn’t a vendor list — it’s a structured dataset with specific mandatory fields that NCAs can query and cross-reference against other supervisory data.
The ESAs ran a dry-run exercise in 2024, asking nearly 1,000 firms across the EU to submit test register data. Only 6.5% passed all 116 data quality checks on their first submission. Common failures: missing or invalid fields on 35–50% of contracts, incomplete sub-outsourcing data, and intragroup contracts as the most under-documented category.
Live Q1 2026 submissions showed the same patterns.
The most common data quality gaps:
Sub-outsourcing chains. Most institutions captured their direct (Tier 1) ICT providers but failed to map Tier 2 and Tier 3 sub-processors. For cloud deployments where AWS, Google, or Microsoft are the Tier 1 provider, NCAs know the sub-outsourcing chains exist — they’re documented in provider terms and service descriptions. A register showing no sub-outsourcing for these providers creates an immediate credibility problem with supervisors who have access to those same public documents.
Criticality mis-classifications. Incorrect flags on which ICT services support critical or important functions — either under-flagged to reduce compliance burden or over-flagged as a conservative default. Incorrect criticality classifications mean incorrect oversight requirements and contract terms for those services.
Intragroup contracts. Intergroup ICT arrangements — where one legal entity within a financial group provides technology services to another — are frequently missing mandatory fields or excluded from registers entirely. Supervisors are specifically looking for these.
Missing CIF flags. The “critical or important function” indicator at the contract level, tied to the function-level criticality assessment, is frequently absent or inconsistent with the entity’s stated critical function mapping elsewhere in supervisory submissions.
NCAs cross-referencing submitted RoI data against incident reports, SLA breach notifications, and other supervisory data can identify these inconsistencies programmatically. Incomplete submissions should expect supervisory follow-up before year-end.
The 19 Designated Critical ICT Third-Party Providers
On November 18, 2025, the European Supervisory Authorities published the first official CTPP list under DORA Article 31. Nineteen providers were designated across cloud, data center, telecom, financial data, and professional services:
Accenture · Amazon Web Services EMEA · Bloomberg · Capgemini · Colt Technology Services · Deutsche Telekom · Equinix (EMEA) · Fidelity National Information Services (FIS) · Google Cloud EMEA · IBM · InterXion Headquarters · Kyndryl · LSEG Data and Risk · Microsoft Ireland Operations · NTT DATA · Oracle · SAP · Tata Consultancy Services · Orange
The designation list is updated and published annually. Providers not on this year’s list could appear on future lists if their customer base among EU financial entities grows.
What CTPP designation means for your obligations:
Non-EU providers on the list — AWS EMEA, Google Cloud EMEA, IBM, and Microsoft Ireland Operations among others — must establish a legal presence within the EU within 12 months of designation — i.e., by November 2026. If a CTPP fails to comply with this requirement, the ESAs have authority to compel financial entities to suspend or terminate use of that provider’s services.
For financial entities using any of the 19 designated providers: every contract supporting a critical or important function must meet the full Article 30 requirements. The ESAs conduct direct oversight of CTPPs — separate from, and in addition to, the NCA examination of the financial entity. Errors in your Register of Information that affect CTPP data don’t just risk resubmission: they affect how the CTPP’s supervisory relationship is established and how your use of that provider is supervised going forward.
If a designated CTPP appears in your Register but your contracts predate DORA and don’t contain the required Article 30 clauses, that’s the documented gap. Remediating contracts with large cloud vendors has proven harder than anticipated — but it’s the gap supervisors are now specifically checking.
Article 30 Contract Gaps: What Existing Contracts Are Missing
Article 30 requires all ICT contracts to contain nine baseline clauses, with enhanced requirements for contracts supporting critical or important functions. The EBA, ESMA, and EIOPA have consistently identified Articles 28–30 as the primary source of compliance failures across institutions.
Baseline clauses required for all ICT contracts:
| Required Clause | Common Gap |
|---|---|
| Full description of services, including sub-contracting scope | Generic scope language that doesn’t specify sub-contracting rights |
| Locations where services are provided and data processed | Absent or defined as “globally” — NCAs want specific locations |
| Data access, recovery, and return procedures on insolvency or discontinuation | Often absent from pre-DORA contracts entirely |
| Cooperation with competent authorities and resolution authorities | Rarely included in standard US-negotiated vendor contracts |
| Termination rights and minimum notice periods | Present in most contracts but may not meet DORA’s minimum standards |
Enhanced requirements for critical/important function contracts:
Beyond the baseline nine, contracts supporting critical functions require: full SLA descriptions; business contingency plans; unrestricted audit rights for the financial entity, appointed third parties, and competent authorities; and documented exit strategies with a mandatory transition period.
The audit rights clause generates the most vendor resistance. DORA requires these rights to be “unrestricted” — not subject to prior approval, annual caps, or cost-recovery clauses that make audits economically impractical. Many US-based vendors have pushed back on contract language this expansive. The practical result is that numerous financial entities accepted diluted language that doesn’t meet the DORA standard.
Exit strategies — a documented plan covering how the financial entity would migrate services to an alternative provider or in-house solution — are largely absent from legacy contracts. The requirement is that exit strategies be practical, tested, and documented. Most firms have “exit provisions” specifying termination notice periods. These are not exit strategies under DORA. For the operational vendor offboarding framework behind a defensible exit plan, see our post on critical vendor exit planning.
For US firms managing these contracts from a US parent: the remediation burden falls on the EU entity’s compliance program, even when the contract negotiation happens at the parent level.
What US Firms Need to Fix in 2026
For US firms that identified gaps in their Q1 2026 posture, the practical agenda:
1. Audit your Register of Information against the 116 ESA data quality checks. The ESA dry-run validation framework is public. Run your register against it and identify where fields are missing or inconsistent. Corrections filed proactively before a supervisory inquiry will be received better than corrections made under examination pressure.
2. Map EU-related ICT contracts to the 19 CTPP designations. For any contract with a designated CTPP — particularly AWS EMEA, Google Cloud EMEA, Microsoft Ireland Operations, FIS, or Bloomberg — verify the contract contains the full Article 30 enhanced clauses. Begin contract remediation conversations now, before the November 2026 EU-presence deadline for non-EU CTPPs.
3. Build sub-outsourcing visibility to Tier 2. NCAs know that major cloud providers and managed service providers have documented subcontractors. A register showing no sub-outsourcing chains for these providers is a credibility issue with supervisors who have access to the same public documentation. Pull sub-processor lists from your CTPP contracts and map them into the RoI.
4. Document intragroup ICT arrangements separately. Intergroup services — where one legal entity within a financial group provides ICT to an EU entity — need to appear in the register with the same mandatory fields as external vendor contracts. This is the most commonly missed category in live submissions and generates specific supervisory follow-up.
For the vendor contract review checklist and ongoing monitoring templates that map directly to the DORA ICT third-party lifecycle, the Third-Party Risk Management (TPRM) Kit provides the vendor inventory structure, due diligence questionnaire, and contract risk review framework that support a defensible Article 28 compliance posture.
Our earlier overview of DORA third-party risk, contracts, and CTPP concentration risk covers the regulation’s foundational structure for teams still working through the baseline compliance picture. For the vendor incident response procedures that DORA’s business continuity plan and notification requirements demand, see our post on vendor breach response playbooks.
So What?
DORA wasn’t a compliance exercise that ended in January 2025. It was the starting point for an ongoing supervisory relationship where regulators have the tools — structured register data, incident history, CTPP oversight — to cross-check your ICT risk management against your stated controls.
For US firms with EU operations: the NCA in your host member state has your Q1 2026 RoI submission. Automated data quality checks are running against it. If the register was built from a procurement extract without validating field completeness or sub-outsourcing chains, the gaps are visible.
The answer isn’t to wait for the inquiry. Run the same checks your NCA is running, identify the gaps, and start remediation — especially on Article 30 contract uplift for CTPP relationships, which takes the most lead time to complete.
Sources: Digital Operational Resilience Act Article 28 — digital-operational-resilience-act.com; DORA Register of Information: Complete Guide to the 2026 Submission — regulation-dora.eu; DORA Critical ICT Third-Party Provider Designations — regulation-dora.eu; EU Names 19 Critical Tech Providers Under DORA — FStech; DORA Article 30 Key Contractual Requirements — Securiti; DORA Article 28: What Banks Need to Ask Their IT Service Providers — Indicium
◆ Need the working template?
Start with the source guide.
These answer-first guides summarize the required fields, evidence, and implementation steps behind the templates practitioners search for.
◆ Related template
Third-Party Risk Management (TPRM) Kit
Complete vendor risk management lifecycle from initial due diligence to ongoing oversight.
◆ Immaterial Findings · Weekly
Sharp risk & compliance insights. No fluff.
◆ FAQ
Frequently asked questions.
Does DORA Article 28 apply to US banks that only have a branch or subsidiary in the EU?
What exactly needs to be in the Register of Information under DORA Article 28?
What are the 19 Critical ICT Third-Party Providers and what does designation mean?
Do existing ICT contracts need to be renegotiated to meet DORA Article 30 requirements?
What happens if our Q1 2026 Register of Information submission was incomplete?
How is DORA Article 28 different from OCC Bulletin 2023-17 on third-party risk?
Author
Rebecca Leung
Rebecca Leung has 8+ years of risk and compliance experience across first and second line roles at commercial banks, asset managers, and fintechs. Former management consultant advising financial institutions on risk strategy. Founder of RiskTemplates.
◆ Related framework
Third-Party Risk Management (TPRM) Kit
Complete vendor risk management lifecycle from initial due diligence to ongoing oversight.
◆ Keep reading
Related posts.
Third-Party Risk
Third-Party Risk Management Lifecycle RACI: Fix the Handoffs Between Procurement, Security, Legal, Business Owners, and Risk
A TPRM lifecycle RACI that assigns clear ownership at each stage — planning, due diligence, contracting, onboarding, monitoring, and offboarding — so findings don't fall between functions.
Jul 24, 2026
Third-Party Risk
Vendor Due Diligence Without a SOC 2: What Evidence Can Actually Substitute
A vendor due diligence checklist for evaluating security evidence when a vendor has no SOC 2 report, with a risk-based substitution matrix.
Jul 23, 2026
Third-Party Risk
Three Vendors, One Existential Risk: What the OCC's Community Bank Core Provider RFI Actually Asked
The OCC published Bulletin 2025-39 asking community banks hard questions about their relationships with Fiserv, FIS, and Jack Henry. The questions reveal exactly what examiners are now checking — and what most TPRM programs haven't addressed.
Jul 23, 2026