DORA — the EU's Digital Operational Resilience Act, Regulation (EU) 2022/2554 — has applied to financial entities across the EU since 17 January 2025. It is not a proposal or an upcoming deadline; it is a live regime, and AI and LLM providers used by in-scope financial entities can be captured under it as ICT third-party service providers. This post covers when that capture happens and what it means in practice, without asserting the exact article numbers behind each obligation — DORA's specific ICT third-party-risk provisions are still being confirmed against primary text for this post, so the obligations below are described by function rather than by citation.

This is not legal advice. DORA scoping and contractual obligations are fact-specific, and the right reading for your organization depends on your regulatory classification and counsel.

What DORA actually covers

DORA applies to a broad range of EU financial entities — banks, investment firms, insurers, payment institutions, and more — and to the ICT third-party providers those entities rely on. Its purpose is operational resilience: ensuring the financial sector can withstand, respond to, and recover from ICT-related disruptions, including those originating with a vendor rather than the financial entity itself.

The regime has two halves that matter for an AI or agent deployment: obligations the financial entity itself must meet (risk management, incident classification and reporting, resilience testing, third-party risk management), and a direct-oversight regime for the ICT providers judged critical enough to the sector as a whole to warrant supervision by EU authorities directly, rather than only through their financial-entity customers' contracts.

When does an AI vendor become an "ICT third party" under DORA?

DORA's ICT third-party-risk provisions are written broadly enough to capture any provider delivering ICT services that support a financial entity's business functions — and an LLM API, an AI agent platform, or a model-hosting provider fits that description whenever the financial entity is using it to support a regulated business process, not just an internal experiment with no production dependency.

The practical trigger is functional, not technical: if a financial entity is relying on an AI vendor for something that touches a business function DORA covers — trading, payments, customer-facing decisioning, risk modeling, or the infrastructure those depend on — that vendor is very likely in scope as an ICT third party, regardless of whether the vendor markets itself as an "AI company" rather than a traditional IT vendor. The label on the vendor's homepage does not determine DORA scope; the function the vendor performs for the financial entity does.

This has a direct consequence for procurement: teams evaluating an LLM provider, an agent platform, or an AI governance tool for use inside a DORA-regulated entity need to run that evaluation as a regulated ICT third-party assessment, not a standard SaaS procurement review.

What DORA expects of the financial entity, not just the vendor

A recurring misconception is that DORA obligations attach to the vendor and the financial entity is simply a customer. In fact, DORA's third-party-risk framework holds the financial entity accountable for managing the risk its vendors introduce — outsourcing the technology does not outsource the regulatory obligation. In practice, financial entities are expected to:

  • Maintain a register of information covering their ICT third-party relationships, including which business functions each vendor supports.
  • Assess concentration risk — what happens if a single AI provider serving multiple critical functions has an outage or a security incident.
  • Build contractual terms with ICT vendors that address audit rights, exit strategies, and incident-notification obligations, rather than accepting a vendor's standard terms as sufficient by default.
  • Include AI and ICT vendor failure scenarios in resilience testing, rather than testing only internally-operated systems.

For an AI vendor relationship specifically, this means a financial entity cannot treat "the model provider handles security" as a complete answer. The entity needs its own visibility into how the AI system is used, what data flows through it, and what happens operationally if the vendor becomes unavailable or is compromised.

The Critical ICT Third-Party Provider designation

On 18 November 2025, the European Supervisory Authorities (the ESAs — EBA, EIOPA, and ESMA acting jointly) designated the first 19 Critical ICT Third-Party Providers (CTPPs) under DORA, subject to direct EU oversight beginning in 2026. That list includes major cloud providers — including AWS, Microsoft Azure, Google Cloud, and Oracle — the same hyperscale infrastructure most enterprise AI and agent workloads run on.

The significance for AI governance teams: if your AI stack sits on top of one of the designated CTPPs, part of the ICT risk picture is now subject to direct EU supervisory oversight independent of your own contract with that provider. That does not remove your own DORA obligations as the financial entity — you still need your own third-party risk assessment and contractual controls — but it changes the baseline assurance available for the infrastructure layer, since the CTPP itself now answers to EU supervisors directly rather than only to its customers' contracts.

2026: the enforcement phase

Compliance commentary broadly characterizes 2026 as DORA's enforcement phase — the period in which supervisors expect financial entities to demonstrate evidenced resilience (test results, incident records, verified contractual controls) rather than present policy documents describing intended practice. For an AI vendor relationship, that shift matters concretely: a due-diligence questionnaire answered once at contract signing is no longer treated as sufficient evidence. Supervisors expect ongoing monitoring, periodic reassessment, and test scenarios that specifically exercise the AI vendor dependency — what happens to the regulated business process if the AI provider is unavailable, degraded, or returns compromised output.

A practical checklist for AI vendor risk under DORA

  1. Map every AI vendor to the business function it supports, and flag any that touch a DORA-covered function, not just IT-classified systems. Building an AI agent inventory covers the underlying discipline of maintaining that map as agents and connections change over time.
  2. Confirm whether the vendor's infrastructure runs on a designated Critical ICT Third-Party Provider, and treat that as one input to your risk assessment, not a substitute for it.
  3. Review AI vendor contracts for audit rights, incident-notification terms, and exit provisions — standard SaaS terms rarely cover these by default. This is the same supply-chain discipline covered more generally in securing the agent supply chain.
  4. Include AI vendor failure and degradation scenarios in resilience testing, not just infrastructure outages.
  5. Maintain evidence, not just policy — the 2026 enforcement posture expects demonstrated testing and monitoring records a supervisor can review. An AI agent compliance checklist for 2026 is a reasonable template to extend with DORA-specific vendor evidence.

How this fits the broader compliance picture

DORA is one of several regimes converging on AI vendor accountability at once. EU financial entities running AI agents also need to work through the EU AI Act's provider/deployer split — see the EU AI Act explained for engineering teams — and US-facing broker-dealers and RIAs face a parallel but distinct set of expectations covered in what FINRA and the SEC expect from AI agents. Firms with a multi-jurisdiction footprint should also see US state AI laws compared for the parallel state-level layer in the US. Firms building a vendor risk-management program that satisfies multiple regimes at once should also review AI agent governance for financial services and the AI governance pillar guide for the underlying controls — vendor registries, contractual review, and continuous monitoring — that DORA, the AI Act, and FINRA's expectations all draw on in different forms.

Praesidia is an AI agent security and governance control plane — agent identity and access, guardrails, audit evidence, and cost controls in one place — and the connection registry and vendor visibility it maintains is the kind of evidence base a DORA third-party risk assessment for an AI vendor relies on.

Common questions

Does DORA apply to companies outside the EU? DORA applies to financial entities operating in the EU and to the ICT third-party providers that serve them, including providers headquartered outside the EU if they serve in-scope EU financial entities. A US-based AI vendor serving EU banks or insurers can be captured by DORA's third-party provisions through that relationship, even without an EU legal entity of its own.

If our AI vendor is not on the Critical ICT Third-Party Provider list, are we off the hook? No. The CTPP designation only identifies providers subject to direct EU supervisory oversight. Every AI vendor supporting a DORA-covered business function is still subject to the financial entity's own third-party risk management obligations, regardless of whether that specific vendor made the critical-provider list.

Is DORA the same as the EU AI Act? No — they are separate regimes with different scopes. DORA is about operational and ICT resilience for the financial sector specifically and has applied since January 2025. The EU AI Act is a horizontal AI regulation covering risk classification, transparency, and high-risk system requirements across all sectors, with its own separate timeline. A financial entity using AI agents needs to satisfy both independently.

What is the single biggest gap financial entities have in AI vendor risk under DORA? Based on the shift toward an evidenced-enforcement posture in 2026, the most common gap is treating vendor due diligence as a one-time contracting exercise rather than continuous monitoring. A questionnaire completed at signing does not demonstrate resilience a year later; supervisors are expecting ongoing evidence.

Do we need to re-negotiate existing AI vendor contracts to comply? Possibly — DORA's expectations around audit rights, incident notification, and exit provisions are frequently absent from standard AI vendor terms written before these obligations were clarified. Reviewing existing contracts against DORA's third-party risk requirements, with counsel, is a reasonable near-term action even if a full renegotiation is not immediately necessary.