DORA Third-Party ICT Risk: Contracts, Concentration Risk, and the 19 Critical Providers You Now Answer To

TL;DR:

• DORA entered into application January 17, 2025. All in-scope ICT vendor contracts must include nine mandatory clauses (Article 30), with additional requirements for contracts supporting critical functions.
• Financial entities had until April 30, 2025 to submit their Register of Information to competent authorities — a detailed inventory of all ICT third-party contractual arrangements.
• The ESAs designated 19 Critical ICT Third-Party Providers (CTPPs) in November 2025, including major cloud infrastructure providers. This triggers direct ESA oversight of those providers — and indirect compliance obligations for financial entities that rely on them.
• Concentration risk isn’t just a checkbox. DORA requires financial entities to have documented, tested exit strategies for any critical ICT service where a single provider failure could disrupt operations.

Here’s the scenario no TPRM team wants to be in: a regulator asks to see your DORA-compliant vendor register, your ICT contracts are three years old, and your exit strategy for your primary cloud provider is “migrate to a competitor, eventually.” That’s not a plan — it’s a hope. And under DORA, it’s a finding.

DORA — the EU’s Digital Operational Resilience Act — entered into application on January 17, 2025. After two years of preparation, implementation guidance, and regulatory technical standards, the rules are live. About 22,000 EU-regulated financial entities are now expected to comply across five pillars: ICT risk management, incident reporting, operational resilience testing, third-party risk management, and information-sharing arrangements.

The third-party risk requirements are where most organizations are still scrambling. Here’s what actually needs to be in place.

What DORA’s Third-Party Risk Framework Actually Requires

DORA doesn’t just ask whether you’ve assessed your vendors. It specifies the documentation you maintain, the contract terms you enforce, the concentration risks you monitor, and the exit strategies you’ve rehearsed. Let’s take each in turn.

The Register of Information: Your ICT Vendor Inventory

Under DORA, financial entities are required to maintain a Register of Information (RoI) — a structured inventory of all contractual arrangements with ICT third-party service providers. This isn’t a simple vendor list. The RoI must capture:

• The services provided and whether they support critical or important functions
• The ICT provider’s location (data center geography, governing law)
• Contract start and end dates, including notice periods for termination
• Annual expenses related to each ICT service
• Sub-contracting arrangements and the location of sub-processors
• Whether the provider is a CTPP (once designations are published)

The RoI must be maintained at the entity level, sub-consolidated level, and consolidated group level. Competent authorities required submission of these registers by April 30, 2025 — based on the timeline announced by the European Banking Authority and the other European Supervisory Authorities. If yours isn’t filed, that conversation with your supervisor is already overdue.

Article 30: The Nine Contractual Must-Haves

Article 30 of DORA establishes baseline contractual safeguards for every ICT third-party service agreement. Nine elements must be present in every in-scope contract:

1. A clear description of all functions and services to be provided
2. Locations where services are provided and where data is processed or stored
3. Data security provisions, including access controls and encryption standards
4. Availability, authenticity, integrity, and confidentiality requirements
5. ICT incident notification procedures — what the provider must report to the financial entity and when
6. Cooperation obligations for ICT security measures, audits, and access requests
7. Termination rights and minimum notice periods
8. Sub-contracting conditions, including the financial entity’s right to object
9. Data portability: how personal and non-personal data can be retrieved upon termination

For contracts supporting critical or important functions, DORA layers on additional requirements. These include more extensive audit and access rights (including regulator access to the provider’s premises), obligations for the provider to participate in threat-led penetration testing (TLPT), and stricter controls on subcontracting — specifically, the provider must notify the financial entity before subcontracting any critical or important function.

The Herbert Smith Freehills analysis of DORA’s contractual requirements puts it plainly: financial entities needed every in-scope vendor agreement to include these terms by January 17, 2025. If you inherited a vendor portfolio with pre-DORA contracts, remediation is your current problem.

Concentration Risk: Why Regulators Are Watching Your Cloud Stack

DORA’s approach to concentration risk is unusually specific. Financial entities must monitor concentration risks related to ICT third-party providers, especially when only a few providers dominate the market for a given service category. Where that concentration creates potential systemic risk, entities must develop contingency plans addressing what happens if a key provider fails.

This isn’t hypothetical risk management. Regulators designed these provisions with cloud infrastructure specifically in mind.

The 19 CTPPs Designated in November 2025

On November 18, 2025, the European Supervisory Authorities — the EBA, EIOPA, and ESMA — published their first list of designated Critical ICT Third-Party Providers. Nineteen providers made the cut.

The ESAs apply a four-factor test to determine criticality:

1. Systemic impact: Would a large-scale operational failure of this provider disrupt the stability or quality of EU financial services?
2. Systemic importance of relying entities: How significant are the financial entities that depend on this provider for critical functions?
3. Concentration of reliance: What percentage of EU financial entities rely on this provider, and for what?
4. Substitutability: Could financial entities realistically switch providers within a reasonable timeframe?

The November 2025 designations confirmed what most TPRM practitioners already suspected: EU financial institutions are heavily concentrated in a small number of US-headquartered cloud infrastructure providers. The list includes major hyperscalers providing cloud computing, data hosting, and software-as-a-service platforms to EU financial entities. The designations confirm that these providers’ operational failures would create systemic-level exposure across the EU financial sector.

What Critical Designation Means for Your Vendor

Designated CTPPs are now subject to direct ESA oversight. The lead ESA for each CTPP has the authority to:

• Request information and documentation from the provider
• Conduct ongoing monitoring activities
• Launch investigations and on-site inspections
• Issue binding recommendations on cybersecurity measures and contract terms
• Recommend adjustments to the terms under which ICT services are provided to financial entities

Crucially, the ESAs can recommend changes to the terms and conditions of the provider’s agreements with financial entities — including subcontracting arrangements. If an ESA finds that your cloud provider’s standard contract doesn’t meet DORA standards, the provider may be required to update it. That change flows back to you.

Exit Strategies Are Now a Compliance Requirement

The concentration risk provisions of DORA include a requirement that most organizations have underweighted: financial entities must have documented and rehearsed exit strategies for critical ICT services.

This goes beyond a clause in your contract. DORA requires that financial entities can demonstrate they have:

• Assessed what operational continuity would look like if a critical provider became unavailable
• Identified alternative providers or alternative operational arrangements
• Documented the exit procedures including data retrieval, portability, and transition timelines
• Tested those procedures — not just written them down

The contractual side supports this: Article 30 requires termination rights with specified minimum notice periods, and exit clauses must ensure that both personal and non-personal data processed by the financial entity can be accessed, recovered, and returned in a readily accessible format if the contract terminates for any reason, including provider insolvency.

If your TPRM team has been treating exit planning as a theoretical exercise for your vendor risk assessments, DORA has upgraded it to an operational requirement.

What TPRM Teams Should Be Doing Right Now

If you’re responsible for vendor risk at an EU financial entity — or at a US institution with EU operations — here’s what the compliance state should look like:

The practical challenge for most TPRM teams is that vendor contracts weren’t negotiated with DORA in mind. Remediation often means going back to established providers — including cloud hyperscalers with non-negotiable standard terms — and either accepting DORA-compliant addenda (where providers have offered them) or documenting the gap and escalating to legal.

For contracts with designated CTPPs specifically, watch for communications from those providers about ESA oversight activities. The oversight framework creates information flow requirements in both directions.

So What?

DORA’s third-party risk requirements aren’t conceptually new — TPRM practitioners have been doing vendor due diligence, contract reviews, and concentration risk assessments for years. What DORA does is make the standard specific, the documentation mandatory, and the oversight direct.

The Register of Information creates a regulatory-grade inventory that competent authorities can inspect. Article 30’s contractual requirements create a checklist that examiners can verify clause by clause. The CTPP oversight framework creates a direct supervisory relationship between regulators and your most critical providers — and that relationship will generate compliance obligations that flow back to you.

The organizations that will struggle aren’t the ones that haven’t heard of DORA. They’re the ones that understood it conceptually but haven’t translated it into updated contracts, filed registers, and tested exit procedures. The gap between knowing what DORA requires and having it documented is where findings happen.

If you need to build or overhaul your vendor risk management process, the Third-Party Risk Management (TPRM) Kit covers vendor risk tiering, due diligence questionnaires, contract review checklists, and ongoing monitoring frameworks — structured for financial services teams working against regulatory requirements like DORA.

For the intersection of cyber resilience and third-party risk, see Cyber Resilience and Business Continuity: Building a Unified Response Framework. On the vendor AI risk side specifically, 72% of Banks Don’t Know Which Vendors Use AI covers the TPRM due diligence gap for AI-powered vendor services. And if your DORA work is exposing gaps in your broader vendor resilience program, Third-Party Business Continuity: Vendor Resilience Planning covers how to build continuity requirements into your vendor oversight framework.

Sources:

• EBA: ESAs announce timeline for CTPP designation under DORA
• Morgan Lewis: EU Regulators Announce List of Critical ICT Third-Party Providers
• Sidley Data Matters: Time to Register Your ICT Third-Party Service Providers under DORA
• Reed Smith: DORA Designation and Oversight of Critical Third-Party Service Providers
• Herbert Smith Freehills Kramer: DORA is now live — are your ICT contracts compliant?