DORA ICT Third-Party Risk: When AI Providers Qualify as Critical ICT Service Providers

DORA ICT third-party risk refers to the obligation of financial entities to actively manage the risks arising from outsourced ICT services. Under Regulation (EU) 2022/2554 (DORA, applicable since January 17, 2025), AI and LLM providers may be covered as ICT third-party service providers. The financial entity using them must then manage them in accordance with Articles 28 to 30: register of information, contractual requirements, concentration risk management. If the European Supervisory Authorities (ESAs: EBA, EIOPA, ESMA) classify a provider as critical, the provider itself becomes subject to the oversight framework under Art. 31 et seq.

• Who is affected? DORA addresses financial entities (including CRR institutions and Solvency II insurers), not AI providers directly. The AI service is covered through the financial entity.
• Why AI? The BaFin guidance of December 18, 2025, classifies AI systems as a subset of "network and information systems" under Art. 3(2) DORA, which pulls the full set of DORA obligations into AI governance.
• Core obligation first: Every contractual ICT service, including an LLM service used in production, belongs in the register of information that is made available to the supervisory authorities.

Why AI/LLM providers become ICT service providers

DORA regulates the digital operational resilience of financial entities, not AI as a technology. The decisive lever is the broad definition of ICT services and of network and information systems. As soon as a financial entity uses an AI service in production, such as a hosted language model, a fraud-scoring API, or a cloud-based document assistant, that service becomes part of its ICT third-party risk.

The BaFin guidance on ICT risks in the use of AI at financial entities, published on December 18, 2025, makes this link explicit in German supervisory practice: AI systems are a subset of "network and information systems" under Art. 3(2) DORA. As a result, AI-supported workloads fall under the DORA obligations on ICT risk management (Art. 5–15), on resilience testing including threat-led penetration testing (Art. 24–27), and on ICT third-party risk (Art. 28–30). By its own account, the guidance is non-binding support and does not define supervisory expectations. It is meant to help financial entities implement the DORA requirements when they use AI. Its primary addressees are CRR institutions and Solvency II insurers.

The practical consequence: an AI provider is not subject to DORA "automatically." The service is covered through the financial entity that uses it, and that entity must manage, contractually bind, and document its provider in a way that makes the DORA requirements achievable.

The register of information

The central management tool for ICT third-party risk is the register of information. Financial entities must maintain a complete register of all contractual arrangements on ICT services and make it available to the competent supervisory authorities. The register records which function a service supports, whether it supports a critical or important function, who the provider is, and which subcontractors are involved.

For AI, this means: an LLM or ML service used in production is not a "tool on the marketing budget." It is an ICT service that must be registered once it amounts to a contractual outsourcing arrangement. The register is also the data source the ESAs use to identify which providers are so widespread across the sector that they should be classified as critical.

Critical ICT third-party service providers (CTPP) and the oversight framework

DORA establishes a dedicated oversight framework for critical ICT third-party service providers (CTPPs). It is set out in Art. 31 et seq. and is therefore separate from the obligations of financial entities in Art. 28 to 30. On November 18, 2025, the ESAs designated the first 19 CTPPs, including AWS, Microsoft Azure, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix, and Bloomberg (list published by the ESAs).

Once designated, these providers are subject to direct oversight at the EU level. For each CTPP, one of the three ESAs (EBA, EIOPA, or ESMA) acts as Lead Overseer (Art. 31(1)(b)). The Lead Overseer is supported by a joint examination team (Art. 40) and can issue recommendations (Art. 35). These recommendations are not legally binding. The provider must, however, state within 60 calendar days whether it will follow them, or explain why not. If the provider does not respond or its explanation is insufficient, the Lead Overseer makes this public. As a last resort, the national competent authorities can require financial entities to suspend the service (Art. 42).

Important for the AI debate: most AI/LLM workloads in production today run on designated hyperscalers such as AWS, Microsoft Azure, or Google Cloud. Even if an AI startup is not (yet) designated as a CTPP itself, it often runs technically on top of a designated provider. Oversight of the underlying hyperscaler does not change the financial entity's own responsibility for outsourcing, exit capability, and concentration risk.

When a provider counts as critical

The ESAs designate providers based on four criteria in Art. 31(2) DORA: the systemic impact of a large-scale outage on the provision of financial services, the systemic importance of the dependent financial entities (such as global systemically important institutions and other systemically important institutions, G-SIIs and O-SIIs), the dependence of critical or important functions on the provider, and substitutability. Delegated Regulation (EU) 2024/1502 turns this into a two-step process. In step 1, a provider must meet all quantitative thresholds. One of them: it supports critical or important functions of at least 10% of the financial entities in a category, and these entities together hold at least 10% of that category's total assets. Only providers that meet all thresholds are assessed qualitatively in step 2. The data comes from the financial entities' registers of information.

The first list includes no provider whose core business is AI models, such as OpenAI, Anthropic, or Mistral. Our assessment: pure AI and LLM providers rarely meet the thresholds today, because their services still support few critical or important functions at banks and insurers and are often procured through the hyperscalers' platforms. A provider that is not on the list can apply to be designated as critical under Art. 31(11). Intragroup ICT service providers and providers that operate in only one member state for financial entities active solely in that member state are not designated (Art. 31(8)).

Concentration risk and exit strategy

Concentration risk is particularly pronounced in the AI context. If nearly every bank in the EU depends for its AI workloads on one of the few designated hyperscalers or on central solutions run by banking groups or networks, a systemic concentration of risk emerges. DORA therefore requires financial entities to manage their dependency actively. Before entering into a contract on ICT services that support critical or important functions, they assess whether the provider is hard to substitute or whether contracts are piling up with the same provider (Art. 29). For such services, they need exit strategies. The exit plans must be comprehensive and documented and must be sufficiently tested and reviewed periodically (Art. 28(8)). DORA does not set a fixed cycle for this, unlike for ICT business continuity plans, which must be tested at least once a year (Art. 11(6)).

In practice, a systematic multi-cloud AI architecture remains technically and commercially demanding in 2026. That is why there is often a gap between an exit plan on paper and a provider switch that can actually be carried out.

Outsourcing and contractual requirements (Art. 30)

DORA Art. 30 defines a mandatory set of contractual clauses for ICT services. This means that for these services, DORA Art. 28–30 take precedence over the EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02) and the corresponding ESMA guidelines. Core elements of the clauses:

• Description of services including the conditions for subcontracting (sub-processors) (para. 2(a))
• Locations where services are provided and data is processed, including the storage location, and advance notice of planned changes (para. 2(b))
• Service level descriptions (para. 2(e)), for critical or important functions with precise quantitative and qualitative performance targets (para. 3(a))
• Termination rights (para. 2(h)), for critical or important functions also exit strategies with a mandatory transition period (para. 3(f))
• For critical or important functions, unrestricted rights of access, inspection, and audit for financial entities and supervisors (para. 3(e))

DORA does not explicitly require commitments on latency or computing capacity. Whether you need them depends on the performance targets of the function in question.

In our assessment, these clauses are largely boilerplate at hyperscalers but a frequent procurement blocker for AI startups. AI vendors without reliable audit rights, sub-processor transparency, and documented processing locations often drop out of the selection process at EU financial entities before the final round.

Overview: obligation, who is affected, legal basis

Practical example: LLM assistant at a regional bank

A mid-sized bank introduces an LLM-based internal knowledge assistant that runs through the API of an AI provider, which in turn hosts on Microsoft Azure. DORA-relevant steps:

1. Classify: Does the assistant support a critical or important function? If so, the requirements become stricter.
2. Register: The contract and the service are added to the register of information, including the subcontractor Azure (a designated CTPP).
3. Secure contractually (Art. 30): audit rights, an exit strategy with a transition period, conditions for subcontracting, defined locations for service provision and data processing (here the bank chooses the EU), and an SLA with quantitative performance targets.
4. Assess concentration risk: Does a critical function rely on a single hyperscaler? Document the exit plan and test it regularly.
5. Incident process: Major ICT-related incidents involving the service, such as hallucinated regulatory citations as a material operational risk event, must be reported under DORA.

Pseudocode of the governance logic:

```
if AI_service.is_contractual_outsourcing:
Register.add(AI_service, sub_processors=[hyperscaler])
if AI_service.supports_critical_function:
Contract.check(Art30_clauses) # audit, exit, SLA, sub-processor
ExitPlan.test(interval="regular")
ConcentrationRisk.assess(provider, function)
Incident.activate_reporting_path(severity="major")
```

The article numbers cited are based on the text of the DORA regulation, and the CTPP status on the ESAs' list of November 18, 2025. This article is not legal advice; whether and how DORA applies to a specific AI service requires a case-by-case assessment by qualified legal and regulatory advisors.

For agencies and B2B decision-makers

For marketing agencies and service providers that deliver AI functions to banks, insurers, or other financial entities, DORA is a hard sales criterion, not a side issue. If you want to sell LLM-based solutions into the regulated financial sector, build audit capability, sub-processor transparency, EU data residency and a reliable exit path into your plans from the start. Otherwise the project fails in procurement, not on model quality. Blck Alpaca helps you design DORA-compliant AI workflows and anchor them in outsourcing and vendor processes, so your AI initiative in the financial sector makes it to the final selection round in the first place. For the case-by-case legal assessment, also consult qualified legal counsel.