When Your Cloud Provider Gets Designated a DORA Critical ICT Third-Party Provider, What Does the 2026 Oversight Regime Actually Require?

When one of your cloud, data-centre, or managed-service providers lands on the European Supervisory Authorities' annual list of critical ICT third-party service providers, the relationship stops being a private commercial arrangement. A public supervisor moves into it. DORA entered application on 17 January 2025, and the oversight of critical ICT third-party providers (Chapter V, Section II) is the part of the regulation that reaches beyond regulated financial entities and pulls the provider itself into a direct supervisory relationship with the EU.

This is the mechanism most compliance teams underestimate. Designation does not change who you contract with. It changes what the supervisor can demand of that provider, what the provider must tell you, and what your own competent authority can order you to do if things go wrong. If you depend on a designated provider, the DORA obligations sitting in your register just acquired an external counterparty with inspection powers.

Here is what the 2026 regime actually requires, article by article.

What is a DORA critical ICT third-party provider (CTPP), and how do the 2026 ESA designations work?

A critical ICT third-party provider is an ICT service provider that the ESAs, acting through the Joint Committee and on a recommendation from the Oversight Forum, formally designate as critical for the EU financial sector (Article 31(1)). Designation is not self-assessed and it is not something a provider opts into by default. It is a supervisory decision, published and updated yearly as a Union-level list (Article 31(9)).

Each designated provider is assigned a Lead Overseer: the ESA (EBA, ESMA, or EIOPA) responsible for the financial entities that together hold the largest share of total assets among all financial entities using that provider's services (Article 31(1)(b)). The Lead Overseer becomes the primary point of contact for every matter related to oversight of that provider (Article 33(1)).

The process has procedural guardrails. The Lead Overseer notifies the provider of the assessment outcome, and the provider has six weeks to submit a reasoned statement with relevant information (Article 31(5)). After designation, the ESAs notify the provider of the effective start date for oversight, which must be no later than one month after notification. Critically for your side of the relationship: the designated provider must notify the financial entities it serves of its designation as critical (Article 31(5)).

Two edge cases matter. A provider not on the list can request designation and receive a decision within six months (Article 31(11)). And a provider established in a third country that is designated as critical may only be used by financial entities if it establishes a subsidiary in the Union within 12 months of designation (Article 31(12)).

Which criteria push a provider over the CTPP threshold, and how do you know if yours qualifies?

DORA sets four cumulative designation criteria in Article 31(2), all assessed in relation to the ICT services the provider supplies:

• Systemic impact. The consequences for the stability, continuity, or quality of financial services if the provider suffered a large-scale operational failure, weighing the number of financial entities and their total asset value that depend on it.
• Systemic character of the customers. Whether global systemically important institutions (G-SIIs) or other systemically important institutions (O-SIIs) rely on the provider, and the interdependence between those institutions and other financial entities.
• Reliance for critical or important functions. The degree to which financial entities depend on the provider for critical or important functions, whether directly or indirectly through subcontracting arrangements.
• Substitutability. The lack of real alternatives, and the difficulty of migrating data and workloads elsewhere because of cost, time, technical complexity, or increased operational risk.

Where the provider belongs to a group, the criteria are assessed for the group as a whole (Article 31(3)), and the group must designate one legal person as a coordination point with the Lead Overseer (Article 31(4)).

Certain providers are carved out entirely (Article 31(8)): financial entities that provide ICT services to other financial entities, providers already subject to Eurosystem oversight under Article 127(2) TFEU, intra-group ICT providers, and providers supplying ICT services solely in one Member State to entities active only in that Member State.

You cannot compute the designation yourself, because the balance-sheet and cross-entity dependency data sit with the supervisors. But you can read the signals. If your provider is a hyperscale cloud platform underpinning critical or important functions, is hard to substitute, and serves a large share of the sector, it is a designation candidate. Your practical trigger is simpler than the criteria: the provider must tell you when it is designated. Your job is to have the third-party risk register in a state where that notification maps cleanly onto every function and contract it touches.

What can the Lead Overseer actually demand — inspections, recommendations, and penalties?

Once designation takes effect, the Lead Overseer runs a full oversight framework against the provider. It first assesses whether the provider has comprehensive, sound, and effective rules to manage the ICT risk it poses to financial entities, covering ICT security and availability, physical and data-centre security, risk management and business continuity, governance, incident reporting, data and application portability, testing, audits, and applicable standards (Article 33(2)-(3)). From that assessment it adopts a detailed annual individual oversight plan for each provider (Article 33(4)).

The concrete powers sit in Article 35(1):

• Request information (Article 37). By simple request or by decision, the Lead Overseer can require business and operational documents, contracts, policies, ICT security audit reports, ICT-related incident reports, and information on parties to whom the provider has outsourced functions.
• Investigations and inspections (Articles 38 and 39). The Lead Overseer, assisted by joint examination teams, may enter any business premises, land, or property, conduct on-site and off-site inspections, and even seal premises, books, or records for the duration of an inspection. Inspections cover the full range of ICT systems, networks, devices, and data used to provide services to financial entities (Article 39).
• Recommendations (Article 35(1)(d)). These can address specific ICT security requirements, terms designed to prevent single points of failure or systemic ICT concentration risk, and planned subcontracting. The Lead Overseer can go as far as recommending that the provider refrain from entering a further subcontracting arrangement where cumulative conditions are met: the subcontractor is established in a third country, the subcontracting concerns critical or important functions, and the arrangement poses a clear and serious risk to Union financial stability.

The oversight reaches outside the EU. Where objectives cannot be met inside the Union, the Lead Overseer may inspect third-country premises, subject to the provider's consent and no objection from the relevant third-country authority (Article 36).

And there are teeth. Where a provider does not comply with the required measures, and at least 30 days have passed since it was notified, the Lead Overseer imposes a periodic penalty payment to compel compliance (Article 35(6)). It is levied daily, for up to six months, at up to 1% of the provider's average daily worldwide turnover in the preceding business year (Article 35(7)-(8)). The payments are administrative, enforceable, and publicly disclosed.

What does CTPP status operationally require of the provider itself?

The provider's obligations under oversight are largely duties of cooperation and transparency rather than a new control catalogue, but they are enforceable through the penalty regime above.

A designated provider must cooperate in good faith with the Lead Overseer and assist it in fulfilling its tasks (Article 35(5)). It must supply requested information and remains fully responsible if what it supplies is incomplete, incorrect, or misleading (Article 37(4)). It must submit to on-site inspections ordered by decision (Article 39(6)); opposing an inspection carries a specific consequence, because the competent authorities of the relevant financial entities can then require those entities to terminate their contracts with the provider (Article 39(7)).

Where the Lead Overseer issues recommendations, the provider has 60 days to notify its intention to follow them or provide a reasoned explanation for not doing so (Article 42(1)). If it fails to respond, or the explanation is deemed insufficient, the Lead Overseer publicly discloses the non-compliance, including the provider's identity and the nature of the issue (Article 42(2)). A group-based CTPP established in a third country must also maintain its Union subsidiary and notify the Lead Overseer of changes to that subsidiary's management structure (Article 31(13)).

If you are a financial entity depending on a designated CTPP, what changes in your obligations?

This is where designation reaches back into your own compliance file. The foundational rule does not move: under Article 28(1)(a), a financial entity remains fully responsible for compliance with all obligations under DORA and applicable financial services law, regardless of what it has outsourced. Designation does not transfer accountability to the provider.

What changes is the supervisory pathway. When the Lead Overseer addresses recommendations to your provider, your own competent authority informs you of the risks identified, and you must take those risks into account in managing ICT third-party risk (Article 42(3)). If your competent authority judges that you have failed to sufficiently address those specific risks, it can notify you that a decision may follow within 60 days (Article 42(4)).

As a measure of last resort, the competent authority can order you to temporarily suspend, in part or in full, the use of a service provided by the critical provider until the identified risks are addressed, and where necessary, to terminate the relevant contractual arrangements (Article 42(6)). In other words, a supervisory finding against your provider can become an order to stop using it. When that happens, the authority must grant you the necessary time to deploy your financial entity exit strategy and transition plans as referred to in Article 28.

That single sentence is why your exit planning is no longer a documentation exercise. It is the mechanism you rely on when a suspension order arrives.

How do you turn concentration risk and exit planning into audit-ready evidence rather than a slide?

DORA is prescriptive about the artefacts, which means the difference between compliant and exposed is whether the evidence exists in a form a supervisor can inspect.

Start with the register of information. Article 28(3) requires financial entities to maintain and update, at entity, sub-consolidated, and consolidated level, a register of all contractual arrangements for ICT services, distinguishing those that support critical or important functions from those that do not. You report on it to your competent authority at least yearly, and you must make the full register, or specified sections, available on request. The ESAs were mandated to deliver standard register templates through implementing technical standards (Article 28(9)), so the format is not yours to invent.

Concentration is a required pre-contract assessment, not a retrospective observation. Before contracting, you must identify whether the arrangement reinforces ICT concentration risk as referred to in Article 29 (Article 28(4)(c)). Article 29 makes this concrete: assess whether the provider is not easily substitutable, whether you hold multiple arrangements with the same or closely connected providers for critical or important functions, and how long or complex subcontracting chains affect your ability to monitor the function and your authority's ability to supervise you.

Exit strategy is the third artefact, and DORA specifies its quality. For ICT services supporting critical or important functions, you must put in place exit strategies that are comprehensive, documented, sufficiently tested, and periodically reviewed (Article 28(8)). They must let you exit without disruption to business activities, without limiting regulatory compliance, and without detriment to clients. You must identify alternative solutions, develop transition plans to move data and workloads to another provider or back in-house, and hold contingency measures for continuity. Article 30 backs this with contractual requirements: the contract must specify the locations where services are provided and data is processed, provide for access, recovery, and return of data on insolvency or termination, and set out termination rights and minimum notice periods.

The failure mode is predictable. Teams hold the register in one spreadsheet, the concentration analysis in a risk memo, and the exit plan in a slide deck last touched at onboarding. When a suspension order lands under Article 42(6), those three artefacts have to agree with each other and with the contract, immediately. Keeping the register, the concentration assessment, and the exit and transition plans in one operational resilience system, each item traceable to the DORA article that requires it, is what converts a designation event from a fire drill into a lookup.

This is the design principle behind Aegis GRC: answer the underlying question once, and let the platform map it to every obligation it satisfies. Source-grounded, traceable to the article. No AI hallucinations. See how Aegis GRC keeps your ICT third-party register and DORA obligations audit-ready and source-grounded — explore at aegis-grc.com.

FAQ: designations, subcontracting chains, and non-EU providers

Does my provider have to tell me it has been designated, or do I have to monitor the ESA list myself? Both channels exist, and you should use both. Article 31(5) obliges the designated provider to notify the financial entities it serves. The ESAs also publish and update the list of critical ICT third-party providers yearly at Union level (Article 31(9)). Relying only on the provider's notification leaves you exposed if it is late; reconcile it against the published list.

We depend on a provider indirectly, through a subcontractor. Does the oversight regime still touch us? Yes. The designation criteria in Article 31(2) explicitly count reliance on a provider for critical or important functions whether financial entities rely on it directly or indirectly through subcontracting. Article 29 further requires you to assess how long or complex subcontracting chains affect your ability to monitor the function. Indirect dependency is in scope; map your fourth parties, not just your direct providers.

Our critical provider is based outside the EU. What is different? If a third-country provider is designated as critical, you may only continue using it if it establishes a Union subsidiary within 12 months of designation (Article 31(12)). The Lead Overseer can also exercise inspection powers on third-country premises, subject to the provider's consent and no objection from the local authority (Article 36). Third-country subcontracting for critical or important functions is a specific concern the Lead Overseer can address through recommendations, up to advising the provider to refrain from the arrangement (Article 35(1)(d)).

Can our regulator actually force us to drop a critical provider? As a last resort, yes. Under Article 42(6), your competent authority can require you to temporarily suspend, in whole or in part, the use of a critical provider's service, and where necessary to terminate the contract, until the risks identified in the Lead Overseer's recommendations are addressed. The authority must give you time to deploy your exit and transition plans, which is precisely why those plans must already be tested and current.