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 risks arising from outsourced ICT services. Under Regulation (EU) 2022/2554 (DORA, applicable since 17 January 2025), AI and LLM providers may be captured as ICT third-party service providers and then trigger the body of obligations in Articles 28 to 30: the Register of Information, contractual requirements, concentration risk management and, where applicable, the oversight framework for critical providers.

• Who is affected? DORA addresses financial entities (including CRR institutions, Solvency II insurers), not AI providers directly. The AI service is captured via the financial entity.
• Why AI? The BaFin guidance of 18 December 2025 classifies AI systems as a sub-category of "network and information systems" under Art. 3 No. 2 DORA, thereby drawing the full body 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, which is made available to the supervisory authorities.

Why AI/LLM providers become ICT service providers

DORA does not regulate AI as a technology but rather the digital operational resilience of financial entities. The decisive lever is the broad definition of ICT services and network and information systems. As soon as a financial entity deploys an AI service in production – for example 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 in financial entities of 18 December 2025 makes this connection explicit in German supervisory practice: AI systems are a sub-category of "network and information systems" under Art. 3 No. 2 DORA. Consequently, for AI-supported workloads the DORA obligations on ICT risk management (Art. 5–15), on resilience testing including threat-led penetration testing (Art. 24–27) as well as on ICT third-party risk (Art. 28–30) apply. The guidance is formally non-binding, but in supervisory practice it materially reverses the burden of proof: those who do not follow it must document the equivalence of alternative measures during BaFin examinations. The primary addressees are CRR institutions and Solvency II insurers.

Practical consequence: an AI provider is not subject to DORA "automatically". The service is captured via the using financial entity – and the latter must steer, contractually bind and document its provider in such a way that the DORA requirements can be met.

The Register of Information

The central control instrument for ICT third-party risk is the Register of Information. Financial entities must maintain a complete record of all contractual arrangements for ICT services and make it available to the competent supervisory authorities. This register captures 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 under the marketing budget" but a registrable ICT service as soon as it corresponds to a contractual outsourcing. The register is at the same time the data basis on which the European Supervisory Authorities (ESAs) identify which providers are so widely used across the sector that they must 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 providers (CTPP). On 18 November 2025, the ESAs designated the first 19 CTPPs – including AWS, Microsoft Azure, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix and Swift. These providers are subject to direct EU oversight from 2026. The DORA Joint Oversight Forum will conduct its first comprehensive examinations over the course of 2026 and is expected to issue binding recommendations.

Important for the AI discussion: most AI/LLM workloads in production today run on precisely these hyperscalers. Even if an AI start-up is not (yet) designated as a CTPP itself, it often technically sits 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.

Concentration risk and exit strategy

Concentration risk is particularly pronounced in the AI context. When nearly every DACH bank relies on one of the few designated hyperscalers or on central shared solutions for AI workloads, a systemic cluster arises. DORA therefore requires financial entities to actively manage their dependency: exit plans must be tested annually, and multi-cloud or substitutability strategies are effectively enforced. According to the research, a systematic multi-cloud AI architecture will remain technically and commercially demanding in 2026 – the gap between a "symbolic exit plan" and a provider switch that can actually be exercised is a real supervisory topic.

Outsourcing and contractual requirements (Art. 30)

DORA Art. 30 defines a mandatory set of contractual clauses for ICT services that replaces or overlays existing outsourcing regimes. The EBA Outsourcing Guidelines (EBA/GL/2019/02) as well as the ESMA Outsourcing Guidelines (ESMA50-164-4285) have been substantially modified by DORA Art. 28–30. Core elements of the clauses:

• Mandatory audit and access rights for financial entities and supervisors
• Exit clauses with an orderly exit path
• Control of subcontractors (sub-processors)
• Service level agreements with data residency, latency and computing capacity commitments

According to the research, these clauses are currently largely standard text with hyperscalers, whereas with AI start-ups they are a frequent procurement blocker. For AI vendors without robust audit rights, without sub-processor transparency and without documented data residency, the selection process at DACH financial institutions often ends before the final round.

Overview: obligation, who is affected, reference

Practical example: LLM assistant in a regional bank

A medium-sized bank introduces an LLM-supported internal knowledge assistant that runs via 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 service are added to the Register of Information – including the subcontractor Azure (designated CTPP).
3. Secure contractually (Art. 30): Audit rights, exit clause, sub-processor transparency, SLA with data residency in the EU.
4. Assess concentration risk: Does a critical function rest on a single hyperscaler? Define an exit path and test it annually.
5. Incident process: Major ICT-related incidents of the service – for example hallucinated regulatory citations as a material operational-risk event – are reportable 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="annual")
ConcentrationRisk.assess(provider, function)
Incident.activate_reporting_path(severity="major")
```

The article numbers, dates and CTPP status cited stem from the underlying research or established DORA knowledge. This article does not constitute legal advice; whether and how DORA applies to a specific AI service requires a case-by-case assessment by qualified legal and supervisory advisers.

For agencies and B2B decision-makers

For marketing agencies and service providers that supply AI capabilities to banks, insurers or other financial entities, DORA is a hard sales criterion, not an add-on. Anyone wishing to sell LLM-supported solutions into the regulated financial sector should factor in audit capability, sub-processor transparency, EU data residency and a robust exit path from the outset – otherwise the project fails not on model quality but on procurement. Blck Alpaca supports the DORA-compliant design of AI workflows and their embedding into outsourcing and vendor processes, so that your AI initiative in the financial sector even makes it into the final selection round. You obtain the case-by-case legal assessment additionally from qualified advisers.