Feature Business Continuity
DORA's ICT Register: Only 40% Filed Before the March Deadline. What Enforcement Looks Like Now.
DORA's ICT third-party register deadline passed on March 31, 2026. Only 40% of required entities submitted on time, and just 6.5% passed all quality checks. Here's what enforcement looks like — and why US fintechs that serve EU clients or provide cloud services can't treat this as someone else's problem.
Table of Contents
TL;DR
- The DORA ICT third-party register deadline was March 31, 2026. As of March 16, only 40% of required entities had submitted — and the 2024 dry run showed only 6.5% of submissions passed all 116 data quality checks
- Enforcement is now active: supervisory letters are going out for non-compliant registers, and national competent authorities have shifted from guidance to examination
- In November 2025, the ESAs designated 19 Critical ICT Third-Party Providers — including AWS, Google Cloud, Microsoft, Oracle, and SAP — for direct supervisory oversight, raising the stakes for any financial entity with meaningful cloud concentration
- US fintechs providing ICT services to EU clients are effectively in scope through their EU clients’ Article 28 obligations — your contracts, audit rights, and exit planning provisions are now being examined
The March 31, 2026 deadline for DORA’s ICT Register of Information wasn’t a soft target. It was the first mandatory, regulator-submitted inventory of every ICT third-party arrangement supporting a critical or important function at every in-scope EU financial entity. Banks, investment firms, insurance companies, payment institutions, crypto-asset service providers — all of them had to submit a structured xBRL-CSV file cataloging every vendor contract touching their operational backbone.
As of March 16 — fifteen days before the deadline — only 40% of required entities had filed.
That’s not a minor compliance lag. That’s a sector-wide readiness gap on one of DORA’s most foundational requirements. And now that the deadline has passed, regulators aren’t waiting.
What the ICT Register Actually Requires
The DORA Register of Information isn’t a vendor list. It’s a structured regulatory submission that maps every contractual arrangement for ICT services — including subcontracting chains — to the critical and important functions they support.
Each entry must capture: the provider’s legal identity and jurisdiction, the nature of the service, the contract start and end dates, the business functions supported, a classification of whether the arrangement supports a critical or important function, the storage and processing locations of data, and a mapping of material subcontractors.
The submission format is xBRL-CSV, using the ESAs’ prescribed templates. It must reflect the status of arrangements as of December 31 of the prior year and be submitted by March 31 of each year. Different national competent authorities set internal pre-deadline windows — Luxembourg by March 1, the Netherlands by March 20, Ireland by March 31 — with validation cycles running into April.
This is not a form you fill out in a week. Firms that started in February were already late.
The 6.5% Problem
The 2024 dry-run exercise should have been a warning shot. Nearly 1,000 firms participated. Only 6.5% passed all 116 data quality checks.
The failures weren’t exotic. The most common issues were:
- Wrong file format: Submissions in Excel or CSV formats that didn’t conform to the xBRL-CSV technical specification
- Blank mandatory fields: Contract end dates missing (sometimes because contracts had no defined end date — which itself is a DORA problem), service descriptions too generic to map to critical functions
- Broken unique identifiers: Provider entries duplicated or unlinked because legal entity identifiers weren’t consistent across entries
- Incomplete subcontractor chains: Firms documented their direct vendors but stopped there, missing the fourth-tier cloud dependency that regulators are increasingly asking about
EY’s post-submission analysis is explicit on what happens next: quality checks don’t stop at submission. NCAs run validation passes. Firms with flagged entries get follow-up requests. The CSSF (Luxembourg’s regulator) specifically warned firms to keep DORA compliance resources mobilized throughout April to handle rejection and remediation workflows.
The 2026 submissions will be checked against the same 116 validation criteria. If your 2025 dry run performance was poor, your 2026 mandatory submission carries the same risk.
The 19 Designated Critical ICT Third-Party Providers
On November 18, 2025, the European Banking Authority (EBA), EIOPA, and ESMA jointly published the first list of Critical ICT Third-Party Providers (CTPPs) under DORA Article 31. The list includes 19 firms covering the full stack of financial institution dependencies: hyperscale cloud providers, data center operators, telecom infrastructure providers, and specialist financial technology firms.
Among the designated CTPPs: AWS, Google Cloud, Microsoft, Oracle, SAP, and Deutsche Telekom.
What designation means in practice:
For the CTPPs themselves: Direct ESA oversight. Regular information requests, on-site inspections, and — critically — the ability for ESAs to issue binding recommendations on risk management and governance. Non-compliance carries penalties of up to 1% of daily global turnover, applied daily until the finding is remediated.
For financial entities using them: Every institution with material reliance on a designated CTPP faces heightened scrutiny on three fronts:
- Concentration risk documentation — Can you demonstrate you’ve assessed what happens if AWS has a multi-region outage?
- Contract provisions — Does your contract with a designated CTPP meet DORA’s Article 30 requirements: exit strategy, audit rights, business continuity provisions, data portability?
- ICT register accuracy — Is the designated CTPP correctly classified in your register with full subcontractor chain documentation?
For context: if you’re running on AWS (most fintechs are), your EU clients’ regulators are now actively examining the contract terms, concentration exposure, and exit planning behind that relationship. If your EU clients ask you for updated contractual language or audit cooperation, this is why.
What Enforcement Actually Looks Like
DORA has been enforceable since January 17, 2025. The informal tolerance period — where regulators provided guidance and accepted good-faith remediation plans — effectively ended with the March 2026 ICT register submission cycle.
The enforcement pattern that emerged in the first year is instructive:
Supervisory letters are the primary tool. An NCA that receives an incomplete, rejected, or flagged register will issue a supervisory letter requiring a remediation plan, often within a defined window (30–60 days). These letters create formal regulatory correspondence that examinations and enforcement decisions can reference.
Examination topics have shifted. Where 2025 examiners were largely assessing whether firms had a DORA program, 2026 examinations are looking at program quality: Are ICT incident classifications correct? Are subcontractor chains documented? Is concentration risk quantified? Did the ICT register reflect actual contractual reality?
Penalties under DORA scale by entity type. For financial entities under national supervisory jurisdiction: NCAs set their own penalty frameworks, but DORA Article 35 allows member states to impose fines for non-compliance. For Critical ICT Third-Party Providers under direct ESA oversight: up to 1% of global daily turnover, applied per day until remediated, plus potential periodic penalty payments.
ComplianceHub’s analysis of the 2026 enforcement wave describes the shift clearly: “Regulators have moved from guidance to enforcement, from tolerance to examination, and from remediating plans to demonstrating controls.”
Why US Fintechs Are in the Conversation
DORA is an EU regulation. It applies to EU-regulated financial entities. US fintechs that operate only in the US have no direct DORA obligation.
But “directly in scope” is the wrong frame if your business touches EU financial institutions.
DORA Article 28 requires EU financial entities to ensure their ICT third-party arrangements meet specific requirements — and to impose those requirements contractually on their ICT providers. If you provide cloud infrastructure, data services, analytics, payments processing, or any other ICT function to EU banks or payment institutions, your EU clients are required to:
- Include you in their ICT register
- Impose contractual provisions covering security standards, audit rights, exit strategies, and business continuity
- Assess your subcontracting chain
- Conduct due diligence on your operational resilience
What this means practically: your EU client’s compliance team will send you contract amendment requests, security questionnaires, and audit cooperation requests that are DORA-driven. The content of those requests — exit strategy clauses, notification timelines, subcontractor disclosure — reflects what Article 30 requires of them.
PSP Lab’s analysis on ICT third-party registers under DORA (and the UK’s parallel PS26/2 framework) notes that US firms serving both EU and UK clients will face nearly identical requirements from two regulatory directions simultaneously. The firm that doesn’t have an audit-ready vendor security posture document will be fielding these requests from both markets indefinitely.
TLPT: The Next Deadline on the Horizon
Threat-Led Penetration Testing (TLPT) is DORA Article 26’s requirement for advanced red-team exercises against live production systems. It follows the TIBER-EU framework and must be conducted at least every three years.
Not every firm needs to do TLPT. National competent authorities designate which entities are required based on systemic importance, size, and ICT risk profile. But for those that are designated, the timeline is unforgiving.
A full TLPT cycle — from provider procurement through intelligence gathering, red team execution, purple teaming, and attestation — takes 9 to 14 months. Firms targeting their first TLPT completion by early 2028 need to be in the provider procurement phase by Q1 2027.
The practical catch: TLPT requires participation from ICT third-party providers that support the functions in scope. Your cloud provider, your core banking system provider, your critical SaaS vendors — if they’re in scope, their cooperation is mandatory, not optional. And Article 26 keeps you responsible for DORA compliance even when the failure is the vendor’s refusal to participate.
If you’re a significant institution or suspect you may be designated, start the TLPT planning conversation now. The firms that treat this as a 2027 problem will still be in procurement in 2028.
So What? What to Do Now
If you’re an EU-regulated financial entity:
Remediate your ICT register. If your 2026 submission was rejected, flagged, or you didn’t submit at all, get the remediation plan moving. The window between submission cycle and examination isn’t long, and supervisory letters citing the register gap are already going out.
Audit your designated CTPP contracts. Pull every contract you have with the 19 designated CTPPs — starting with AWS, Microsoft, and Google Cloud — and check them against DORA Article 30: exit strategy clauses, audit rights, notification obligations, subcontractor disclosure. Gaps here are examination-ready findings.
Document concentration risk. If more than one critical or important function runs on a single designated CTPP, that’s a concentration risk that needs to be quantified, risk-accepted, and documented. Regulators want to see you’ve thought about the failure scenario, not just that you’ve identified the dependency.
Start TLPT scoping if you might be designated. Talk to your NCA. If you’re in the size or systemic importance range that puts you in scope, start the feasibility assessment now. A 9–14 month execution timeline leaves no runway for late starts.
If you’re a US fintech serving EU clients:
Expect contract amendment requests. DORA-driven contractual changes from EU clients aren’t optional for them — and declining to cooperate creates compliance failures that put the relationship at risk.
Build your vendor security posture document. A single, current document covering your security controls, subcontractor chain, business continuity provisions, and incident notification procedures will answer 80% of the DORA-driven questionnaires you’ll receive this year. Without it, you’re answering the same questions 15 different ways for 15 different clients.
The ICT third-party register framework isn’t going away. The 2027 submission will check for the same quality criteria. Get the 2026 gaps fixed before the next cycle opens.
The RiskTemplate Third-Party Risk Management (TPRM) Kit includes vendor due diligence questionnaires, risk tiering methodology, and ongoing monitoring frameworks built for financial services — the right foundation for the vendor documentation DORA’s enforcement cycle is now actively checking.
Related reading:
◆ 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.
What is the DORA Register of Information and who has to file it?
What happened to firms that missed the March 31, 2026 deadline or submitted an incomplete register?
Are US fintechs and cloud providers subject to DORA?
What is TLPT and which firms need to do it?
What are the 19 Critical ICT Third-Party Providers (CTPPs) and what does their designation mean?
What were the most common ICT register quality failures in the 2024 dry run?
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.
Business Continuity
Your BCP Is a Document. The FFIEC BCM Booklet Wants a Management Process. Here's What Examiners Are Testing.
The FFIEC Business Continuity Management booklet shifted the examination standard from recovery planning to operational resilience — but most fintechs and community banks still have a document, not a management process. Here are the seven BCM components, the most common examination findings, and what a defensible program actually looks like.
Sep 7, 2026
Business Continuity
The Integration Requirement Your BCP Is Missing: What FFIEC Examiners Actually Check on Vendor Business Continuity
Collecting your vendor's SOC 2 and test summary isn't FFIEC BCM compliance. Examiners want to see that you've integrated your critical vendors' continuity plans into your own BCP—with evidence of end-to-end testing and notification tracking.
Aug 24, 2026
Business Continuity
ISO 22301 Clause 9.3 Management Review: Agenda, Inputs, Decisions, and Evidence
Build an ISO 22301 management review decision pack that maps Clause 9.3 inputs to evidence, decisions, owners, and follow-up.
Aug 21, 2026