Does DORA apply to AI systems specifically or only to general ICT?

DORA applies to all ICT third-party services that support a financial entity's operations, including AI and LLM services. The regulation does not single out AI, but the same framework that governs cloud providers and SaaS platforms governs AI providers. The criticality classification turns on whether the AI supports a critical or important function. Article 30 contract requirements, the register obligations under Article 28, and the operational resilience testing under Article 24 all extend to AI systems that fall inside the financial entity's ICT scope.

Which LLM vendors are likely to be designated as Critical ICT Third-Party Providers?

The first round of CTPP designations targeted hyperscale cloud providers. The current criteria for designating an LLM vendor turn on systemic importance, substitutability, and concentration of financial entities relying on the service. Hyperscaler-hosted model offerings (AWS Bedrock, Azure OpenAI) already sit under their parent cloud designations. Independent model providers like OpenAI and Anthropic may reach the CTPP threshold based on their concentration inside the EU financial sector. The ESA designations are reviewed annually and the criteria themselves are evolving.

What goes in the ICT register for an AI vendor?

The register entry for an AI vendor has to identify the vendor, the specific services consumed (e.g., GPT-4o API, Claude 3.5 Sonnet API, Bedrock Titan), the functions supported by those services, the criticality classification, the location of data processing, the contract terms, and the renewal and termination provisions. The register also has to capture sub-outsourcing where applicable: if the LLM vendor uses sub-processors (e.g., Anthropic's compute on AWS), the chain has to be documented. Article 28 explicitly requires sub-outsourcing visibility.

How does DORA interact with the EU AI Act for financial services?

The two regimes overlap and stack. The EU AI Act applies horizontally across all sectors and creates risk-classification obligations for AI systems used by EU deployers. DORA applies specifically to EU financial entities and creates third-party-risk obligations for the ICT services those entities consume. A high-risk AI system used by an EU bank has to satisfy both: the EU AI Act's Articles 9 through 15 obligations on the AI system, and DORA's Article 30 obligations on the contract for that AI system. The audit-record artifact satisfies both regimes because the content and retention requirements converge.

What does an Article 30 audit clause look like for an LLM vendor?

The Article 30 audit clause has to grant the financial entity and its competent authorities the right to access, inspect, and audit the vendor's relevant systems, premises, and records. For an LLM vendor, this typically translates to access to the vendor's SOC 2 reports, ISO 27001 certifications, customer-facing audit findings, and provider-side logging of the financial entity's API usage. On-premises inspection rights are rarely exercised but have to be available in the contract. For CTPP-designated vendors, the audit clause has to permit ESA Lead Overseer access in addition to the financial entity's own audit team.

DORA Third-Party AI Risk: How EU Banks Have to Treat LLM Vendors Under the ICT Critical-Provider Regime

The Digital Operational Resilience Act became enforceable on January 17, 2025. EU financial entities, including banks, insurers, investment firms, and trading venues, now have to maintain a register of all ICT third-party service providers, classify the ones that support critical or important functions, and meet the Article 30 contract-content rules. Large language model providers such as OpenAI, Anthropic, Google, AWS Bedrock, and Azure OpenAI sit inside this regime. So do the AI features inside Microsoft 365, Salesforce, and the trading and risk platforms financial entities already use. The supervisory question is whether the register correctly captures the AI usage and whether the audit evidence survives a competent-authority review.

The DORA framing for AI is the same framing it applies to any ICT third-party: classification, contract, diligence, monitoring, exit. The execution gap shows up at the audit-trail layer, because most financial entities do not have an audit record at the AI request layer that can answer the regulator's questions.

I want to walk through how DORA treats LLM vendors, the Article 30 contract requirements that apply to those vendors, the Critical ICT Third-Party Provider designation that may apply to the largest of them, and where the audit evidence has to come from.

The ICT third-party register and where AI usage sits inside it

Article 28 of DORA requires every financial entity to maintain a register of contractual arrangements with ICT third-party service providers. The register has to identify each provider, the functions the provider supports, whether those functions are classified as critical or important, the location of data processing, and the contractual terms.

LLM providers belong in the register. OpenAI's API, Anthropic's API, Bedrock's hosted models, Azure OpenAI Service, and the embedded AI features inside SaaS products that financial entities use are all ICT services. The criticality classification turns on what the AI does. An LLM that drafts internal marketing copy is not supporting a critical or important function. An LLM that screens trade settlements, evaluates credit applications, or supports anti-money-laundering workflows is.

The register has to be complete. Shadow AI usage, where business units have signed up for AI tools without going through procurement, breaks the register's completeness. Article 28 explicitly requires the register to cover all arrangements, including intra-group ones. A financial entity that cannot point to a complete inventory of AI usage will fail Article 28 even before the question of contract content arises.

Article 30: the contract-content rules that apply to LLM vendors

Article 30 sets out the minimum content for ICT service contracts. For contracts supporting critical or important functions, the requirements are extensive and apply to LLM vendor contracts the same way they apply to any other ICT service.

The Article 30(2) minimums apply to every ICT contract:

A clear description of the functions and services
The locations where data is processed
Service level descriptions, including updates
Confidentiality and personal data protection provisions
Provisions on access, inspection, and audit rights
Termination rights and notice periods
Provisions for cooperation with competent authorities
Provisions on assistance during incidents

For contracts supporting critical or important functions, Article 30(3) adds further requirements:

Full service level descriptions with quantitative and qualitative performance targets
Notification obligations for the ICT provider when changes may affect the service
Reporting obligations covering incidents
Cooperation with competent authorities, including the right of supervisors to access provider premises
Termination rights tied to specific scenarios including the provider's breach of applicable law
Mandatory exit strategies with assistance during transition

Standard LLM vendor terms of service do not meet Article 30(3) on day one. Most major model providers have published DORA-aligned addenda that financial entities can negotiate. The negotiation is non-trivial because the model provider has to commit to audit rights and on-premises inspection that a hyperscale model provider is not architecturally set up to grant by default.

The Critical ICT Third-Party Provider regime

DORA introduced a direct-supervision regime for ICT providers that are themselves so large that their failure could affect the EU financial system. Under Articles 31 to 44, the European Supervisory Authorities can designate certain providers as Critical ICT Third-Party Providers. Designated providers are subject to direct oversight from a Lead Overseer (ESA), with powers to request information, conduct on-site inspections, and impose remediation requirements.

The first round of CTPP designations targeted hyperscale cloud providers (AWS, Azure, Google Cloud) and major SaaS platforms. The current question is whether OpenAI, Anthropic, or other independent model providers reach the CTPP threshold based on their concentration inside the EU financial sector. The ESA criteria turn on the systemic importance of the provider's services, the substitutability of those services, and the concentration of financial entities relying on them.

For financial entities, the practical effect of CTPP designation is that the contract content rules under Article 30 have to be supplemented with provisions reflecting the Lead Overseer's authority. The audit-and-inspection language has to permit ESA access, not just bank access. The reporting language has to align with what the Overseer requires.

Operational resilience testing and AI systems

Article 24 requires financial entities to conduct a digital operational resilience testing program that includes threat-led penetration testing (TLPT) every three years. AI systems that support critical or important functions fall inside the scope of TLPT.

The TLPT framework expects testing of the full attack surface, including the AI components. Penetration testers will probe model API endpoints, attempt prompt injection against deployed agents, and test the audit trail for evidentiary integrity. A financial entity whose AI gateway lacks identity propagation will produce TLPT findings showing that the attacker's identity cannot be traced. A financial entity whose audit log is application-controlled will produce findings showing that the log can be modified by the same code path that ran the decision.

Mitigation findings from TLPT have to be remediated under regulatory timelines. The most common AI-related findings sit at the request-layer architecture: missing identity, missing policy state, missing tamper protection on the audit log.

Where the audit evidence comes from

Article 19 of the EU AI Act mandates six-month log retention for high-risk systems. DORA's audit-and-inspection rights under Articles 28 and 30 require the financial entity to produce records on supervisory request. The two regimes converge on the same artifact: a per-decision audit record at the AI request layer that captures identity, classification, policy state, and outcome.

The artifact has to be generated outside the application. Application-controlled logs fail the audit-rights test because the same code path that ran the decision also wrote the log. A regulator who asks "show me every credit-decisioning AI call this customer's data flowed through" needs a record that the application cannot have altered or omitted.

The artifact has to capture identity. The natural-person identity of the customer, the natural-person identity of the bank employee handling the decision, the application identity, and the agent identity if an autonomous agent was involved. Standard application logging captures the application identity. DORA-grade audit evidence requires all four.

The artifact has to capture policy state. Which policy version was in effect at the moment of decision, which routing rule was applied, which classification was assigned to the input data, and what outcome was returned. Policy state is what shows the regulator that the decision was governed.

DeepInspect

DORA's third-party AI risk requirements converge on the same architectural primitive: identity-aware policy enforcement at the AI request layer, with a per-decision audit record that survives an ESA review. DeepInspect is built for this. It sits between authenticated users or agents inside a financial entity and any LLM endpoint, regardless of whether the endpoint is OpenAI, Anthropic, Bedrock, Azure OpenAI, or a self-hosted model. Identity is verified per request. Policy is evaluated per request. Routing decisions, including region selection for residency requirements, fire per request. The per-decision audit record is the artifact the regulator asks for.

The architecture answers the DORA audit-rights question that internal application logs fail. The records identify the natural person whose decision the AI affected, the classification of the data involved, the policy version in effect, and the outcome returned. The records are written outside the application, so the application cannot alter them.

If you are a financial entity working through your ICT register and the DORA Article 30 addendum negotiations with your LLM vendors, book a technical deep dive at deepinspect.ai.