A Critical Third-Party ICT Provider (CTPP) under DORA, Regulation (EU) 2022/2554, is an ICT vendor whose failure or disruption could trigger systemic consequences across the EU financial sector. From January 2025, the three European Supervisory Authorities (EBA, EIOPA and ESMA) gained binding powers to designate such providers, send Joint Examination Teams into their operations, and impose daily penalty payments for non-compliance. For compliance officers and CISOs in banking, insurance and investment management, this framework fundamentally changes the risk calculus of relying on non-EU hyperscalers.
How the CTPP Designation Process Works Under DORA Article 31
DORA Article 31 sets out the criteria and mechanism by which ICT providers can be formally designated as critical to the EU financial system. Designation is not automatic: the ESAs assess each candidate against quantitative thresholds (number of financial entities served, systemic relevance of those entities, cross-border footprint) and qualitative factors such as substitutability and dependency depth.
The process begins when financial entities submit their Register of Information data to national competent authorities, who consolidate and forward it to the ESAs. The DORA Oversight Forum, composed of representatives from EBA, EIOPA and ESMA, then reviews aggregated dependency data to identify concentration patterns. A provider meeting the threshold criteria receives a preliminary designation notice and has the right to submit observations before a final decision is issued.
In November 2025, the ESAs published the first list of designated CTPPs. The providers in scope are primarily large cloud infrastructure vendors, software-as-a-service platforms supporting critical banking functions, and data analytics providers embedded in trading and risk management workflows. The list is intentionally not limited to non-EU firms, but in practice the largest and most systemically embedded providers are US-headquartered hyperscalers operating under US law.
ESA Oversight Powers and What Joint Examination Teams Actually Do
Once designated, a CTPP is subject to ongoing oversight led by a single Lead Overseer drawn from EBA, EIOPA or ESMA, depending on which financial sub-sector the provider serves most significantly. The Lead Overseer coordinates with the other two ESAs through the Oversight Forum, ensuring that a provider serving banks, insurers and investment firms simultaneously is examined holistically rather than through three parallel processes.
The primary operational mechanism is the Joint Examination Team (JET). A JET is a multi-disciplinary group assembled by the Lead Overseer and composed of staff from the ESAs and relevant national competent authorities. JETs have the power to conduct on-site inspections at the CTPP’s premises, request documentation, interview key personnel, and review technical architecture including subcontracting arrangements and incident response procedures.
JETs do not replace the financial entity’s own audit rights, but their findings carry supervisory weight: a JET recommendation issued to a CTPP becomes an oversight measure that the CTPP must implement within a defined timeline. Financial entities relying on that CTPP will need to monitor remediation progress and assess whether unresolved findings create residual risk in their own ICT risk framework.
Under DORA Article 35, if a CTPP fails to implement oversight measures, the Lead Overseer can impose periodic penalty payments of up to 1% of average daily worldwide turnover per day of non-compliance, for up to six months. This enforcement mechanism is notably stronger than what most national regulators could previously impose on extra-territorial technology providers.
The EBA has stated that “the digital operational resilience of the financial sector cannot depend on a handful of third-party providers that are beyond the reach of European supervisors,” reflecting the political and supervisory intent driving the CTPP framework.
Operational Risk Exposure for Financial Entities Relying on Non-EU Hyperscalers
The designation of a hyperscaler as a CTPP creates a specific category of regulatory exposure for every financial entity that uses it for critical or important functions. That exposure operates on two levels.
At the contract level, DORA Article 30(2) requires that contractual arrangements with ICT third-party service providers include a full description of all functions, data processing locations and exit provisions. Regulation (EU) 2022/2554 specifies: “Financial entities must ensure that contractual arrangements with ICT third-party service providers include, at a minimum, a full description of all functions and ICT services to be provided and the locations where such services are to be provided and where data is to be processed.” Standard hyperscaler terms of service rarely satisfy these requirements out of the box, requiring bespoke negotiation that smaller institutions often lack the leverage to achieve.
At the jurisdictional level, US-headquartered providers remain subject to the CLOUD Act, FISA Section 702 and historical Patriot Act provisions, meaning US government agencies can compel data access regardless of where the data is physically stored. A CTPP designation by the ESAs does not neutralise US legal jurisdiction over that provider’s infrastructure. The financial entity therefore carries dual exposure: regulatory risk if the CTPP fails to satisfy DORA oversight measures, and jurisdictional risk if the CTPP is compelled to disclose client data to a non-EU government authority.
The European Systemic Risk Board has documented that three US-based providers account for the majority of cloud infrastructure usage in the EU financial sector, a concentration that DORA was explicitly designed to address. The systemic implications of a service disruption at any one of these providers extend across borders and sectors simultaneously.
According to the IBM Cost of a Data Breach Report 2024, the average total cost of a data breach reached USD 4.88 million, the highest figure ever recorded. For financial entities, breaches originating in the supply chain tend to carry higher costs and longer detection timelines than internally sourced incidents.
The Register of Information: Practical Documentation and Audit Obligations
DORA imposes a Register of Information requirement on every in-scope financial entity. This is not a one-time exercise but a continuously maintained contractual inventory covering all ICT third-party arrangements, with granular detail extending to subcontractors.
Commission Delegated Regulation (EU) 2025/532 (the subcontracting RTS) specifies that financial entities must map the full subcontracting chain for any function classified as critical or important. Each tier of the chain must be assessed for compliance with the same security and resilience standards applied to the primary provider, and the financial entity must retain contractual audit rights reaching down to sub-processors.
| Register of Information element | What it must capture | Common gap in current practice |
|---|---|---|
| Function classification | Whether the supported function is critical or important under the DORA RTS | Functions classified as non-critical without documented rationale |
| Data processing locations | Countries where data is stored, processed and backed up | Hyperscaler contracts specify regions, not countries, leaving ambiguity |
| Subcontracting chain | Identities and roles of all material sub-processors | Chains undocumented beyond tier one; no audit rights below primary provider |
| Exit and substitutability | Documented exit plan and alternative providers | Exit plans exist on paper but have never been tested |
| Incident reporting alignment | Contractual obligation on provider to notify within DORA timelines | Provider notification SLAs exceed the financial entity’s reporting deadline |
National competent authorities can request the Register of Information at any time, and the ESAs use aggregated Register data to identify systemic concentration. An incomplete or inconsistently maintained register is itself a supervisory finding, separate from any underlying security deficiency.
How Sovereign and Swiss-Hosted Alternatives Reduce CTPP Risk
DORA applies to EU financial entities regardless of where their providers are domiciled, so switching to a sovereign or Swiss-hosted alternative does not remove DORA compliance obligations. What it does is reduce two specific categories of risk that are structurally difficult to manage within large US-controlled platforms.
First, it reduces concentration risk. A financial entity that migrates critical workloads from a designated CTPP to a provider that is neither designated nor systemically concentrated removes its direct dependency on a supplier under active ESA oversight. If the former CTPP receives a negative JET finding or faces enforcement action, the migrated entity is not operationally exposed.
Second, Swiss-hosted infrastructure under the revised Federal Act on Data Protection (revFADP) removes the US jurisdictional layer. A Swiss-incorporated provider with no US parent company and no US-located infrastructure is not subject to CLOUD Act or FISA 702 compulsion. Contractual data residency commitments made by a Swiss provider are enforceable under Swiss law and not subject to override by a foreign government agency. This addresses the dual-exposure problem described above, and the resulting contractual structure is substantially easier to document in the Register of Information.
For organisations considering sovereign Nextcloud-based workspaces as a replacement for Microsoft 365 or Google Workspace, the practical compliance benefit is that full data location control, combined with open-source auditability and the absence of training-data provisions, allows a financial entity to complete its Register of Information entry for that service with a level of precision that hyperscaler contracts rarely permit.
DORA covers more than 22,000 financial entities across the EU, according to the European Commission’s own impact assessment. At that scale, the supervisory data gathered through Registers of Information will make sector-wide concentration patterns visible to regulators in a way that was previously impossible. Entities that proactively diversify away from designated CTPPs will be in a structurally stronger position when that visibility is used to drive supervisory action.
FAQ: DORA CTPP Oversight for Financial Entities
Which authority leads the oversight of a specific CTPP under DORA?
The three ESAs (EBA, EIOPA and ESMA) each act as Lead Overseer for designated CTPPs, allocated based on the financial sector where the provider has the greatest systemic footprint. All three coordinate through the DORA Oversight Forum to avoid duplicative examinations.
Can a CTPP be fined for non-compliance with DORA oversight requirements?
Yes. Under DORA Article 35, the Lead Overseer can impose periodic penalty payments of up to 1% of the CTPP’s average daily worldwide turnover for each day of non-compliance, for a maximum of six months. This represents a meaningful financial deterrent for even the largest global providers.
What is the Register of Information and who must maintain it?
Every financial entity in scope of DORA must maintain a Register of Information documenting all contractual arrangements with ICT third-party providers. The register must capture supported functions, data locations, subcontracting chains and criticality assessments. It must be submitted to the relevant national competent authority on request and kept continuously up to date.
Does Swiss-hosted infrastructure count as outside DORA jurisdiction?
DORA applies to financial entities established in the EU regardless of provider location. However, Swiss-hosted providers not designated as CTPPs and not subject to US law remove the specific legal exposure that comes with US-controlled hyperscalers. They also allow contractually enforceable data residency within a neutral jurisdiction that the Register of Information can reflect precisely.
What is Commission Delegated Regulation (EU) 2025/532 and why does it matter for subcontracting?
This delegated regulation specifies the RTS on subcontracting of critical or important functions under DORA. It requires full mapping of subcontracting chains, equivalent security standards at each tier, and contractual audit rights extending to sub-processors. Financial entities that cannot produce this documentation for a hyperscaler’s full stack face a direct compliance gap.