The ESAs published their first report on DORA major ICT incidents in June 2026, and the finding was unambiguous: system failures and external events, meaning third-party provider failures, are the primary drivers of serious operational incidents in EU financial services[1]. The same month, ESMA launched a common supervisory action specifically targeting digital operational resilience at crypto-asset service providers, with third-party reliance named as a headline scope item[2]. If you are an FCA-regulated firm using a third-party AI provider, these reports are about you, whether or not your regulator has said so directly yet.

Most financial advice firms, wealth managers, and IFAs now use at least one third-party AI tool: a document summarisation service, an AI-assisted CRM, a paraplanning aid, a client communication tool. Many use several. Almost none have a vendor risk assessment that would satisfy DORA’s requirements for ICT third-party service providers, let alone one built for the specific characteristics of AI systems.

This guide sets out what a vendor risk assessment aligned with DORA’s requirements for AI providers actually looks like, and how to build one without a compliance team or a six-figure legal budget.

Why standard vendor due diligence does not cover AI providers

Standard vendor due diligence asks whether a supplier is financially stable, holds the right certifications, and has a service level agreement. That is a reasonable starting point for a payroll provider or a document management system. It is inadequate for an AI provider.

AI systems introduce risks that do not appear in traditional supplier assessments. A language model’s outputs are probabilistic, not deterministic. The same input can produce different outputs on different days. The model your provider deploys today may be silently updated tomorrow, with no change to the contract and no formal change notification, altering the behaviour of a system you have integrated into client-facing processes.

DORA, which became applicable to UK-relevant financial entities through the FCA’s parallel operational resilience framework, requires firms to assess and manage the risks of ICT third-party dependencies as a core obligation, not a best-practice supplement[3]. For AI providers specifically, that means the assessment must go further than uptime guarantees and ISO certifications.

What DORA actually requires from your third-party assessments

DORA’s third-party risk requirements, reflected in the FCA’s PS26/2 operational incident and third-party reporting rules[4], cluster around four areas that are directly relevant to AI provider relationships.

Concentration risk. If your firm’s operations are critically dependent on a single AI provider, and that provider experiences an outage, a model degradation event, or a service withdrawal, how long does it take before that affects clients? DORA requires firms to identify and document concentration risk explicitly. Firms building workflows entirely around one API without exit or fallback planning are exposed here.

Subcontracting transparency. When your AI provider uses a foundation model from a third party (OpenAI, Anthropic, Google, or another), that is subcontracting in DORA’s terms. You need to know the subcontracting chain, and your contract with the AI provider must reflect it. The ESAs’ draft RTS on subcontracting was rejected on mandate grounds in May 2026, creating some short-term uncertainty[5], but the underlying obligation to understand and document your subcontracting chain remains.

Change management. DORA requires that material changes to ICT systems, including those made by third-party providers, go through your change management process. AI providers update models frequently. Automated deployment pipelines can reduce deployment time by approximately 25% compared to earlier cycles[6], which means a provider can push a material model change into production faster than your change approval window was designed to catch. Your contract needs notification rights, and your assessment needs to document how you will monitor for undisclosed model changes.

Exit plans. DORA requires documented exit strategies for critical and important ICT third-party service providers. For AI providers, that means you need a technically feasible alternative, not just a theoretical one. If the entire workflow would need to be rebuilt from scratch on a different provider’s API, you do not have an exit plan, you have an aspiration.

How to structure the assessment itself

A vendor risk assessment aligned with DORA’s requirements for an AI provider should cover seven areas. You do not need a lengthy document for each, but you do need documented answers, reviewed at least annually and whenever the provider makes a material change.

1. Classify the function. Is this a critical or important ICT service? DORA’s stricter requirements apply to services where disruption would have a material impact on clients, operations, or regulatory obligations. If the AI tool is involved in client communications, suitability assessments, reporting, or compliance monitoring, it is almost certainly critical or important. Document the classification and the reasoning.

2. Map the subcontracting chain. Ask your AI provider directly: which foundation model or models does your product use? Who operates the infrastructure? Where is data processed and stored? Where are model outputs generated? This information is not always volunteered, but you have a right to it. The EIOPA generative AI market survey confirmed that reliance on third-party providers is the primary systemic risk factor the ESAs identified across the EU financial sector[7].

3. Assess concentration risk. Could you switch to an alternative provider within your recovery time objective if this provider failed? Is this provider also used by other critical systems in your firm? The answers determine whether concentration risk is a finding your assessment needs to escalate.

4. Review model change notification rights. Your contract should require the provider to notify you before material changes to the underlying model, with enough lead time to test and validate before the change reaches production. If it does not, that is a gap. For AI tools integrated into suitability or client-facing processes, shadow testing, running the new model in parallel with the current one before it goes live, is a sensible minimum control[8]. All AI outputs in these processes require human review before use in regulated decisions or documents.

5. Evaluate data handling and sovereignty. Where is client data sent when you use this tool? Is it used to train future models? Is it processed outside the UK or EU? For firms with data sovereignty obligations, locally-hosted or on-premises AI models are becoming a practical alternative, with capable models now running on standard office hardware rather than requiring specialist GPU infrastructure[9]. That is not always the right answer, but it should be a documented choice, not an oversight.

6. Assess credential and access security. If the AI tool has API access to your systems, your CRM, your document management platform, your reporting tools, what credentials does it use? 54% of enterprises have already experienced at least one AI agent security incident, and the most common factor is shared credentials[10]. Each integration should use a dedicated, scoped credential set. Access should be logged and reviewed. If a vendor cannot tell you what your data is accessed with and where those logs sit, that is a material gap.

7. Document your exit plan. What would it take to stop using this provider and switch to an alternative within 30 days? Within 90 days? The plan does not need to be elaborate, but it needs to be technically honest. If the answer is “we would need to rebuild significant parts of the workflow”, that is a finding that affects your concentration risk classification.

The one thing most firms are not doing

Most firms using AI tools in 2026 have not revisited their vendor assessments since the tools were adopted. The assessment, if it exists at all, was done once, at onboarding, and has not been updated since.

DORA does not treat vendor risk assessment as a one-time exercise. It treats it as an ongoing obligation, and AI providers are the category where ongoing review matters most.

Model versions change. Subcontracting chains change. Data processing locations change. A provider that was a manageable dependency twelve months ago may now sit at the centre of three or four integrated workflows, with no documented exit route and no change notification mechanism in your contract.

The minimum viable position is an annual review cycle, with a trigger for out-of-cycle review whenever a provider makes a material product change, changes its underlying model provider, or is acquired.

What to do next

If you do not currently have a documented vendor risk assessment for your AI providers, here is a practical starting sequence:

First, list every AI tool your firm uses. Include tools embedded in platforms you already use, AI features inside your back-office system, your CRM, your document platform. If the tool uses a language model at any point in its process, it belongs on this list.

Second, classify each one. Does it touch client data? Does it touch suitability, advice, or reporting? If yes to either, treat it as critical or important until you have a reason not to.

Third, write to each provider. Ask three questions: What foundation model or models do you use? Where is data processed? What is your process for notifying clients of material model changes? Their response, and the ease or difficulty of getting it, will tell you a great deal.

Fourth, check your contracts. Look for change notification rights, data processing terms, and exit provisions. If they are silent on model changes, flag it with whoever manages your supplier contracts.

Fifth, document what you find. The document does not need to be long. It needs to exist, to be dated, and to be reviewed. That is what distinguishes a defensible position from a gap finding in a regulatory review.

The FCA has made clear that operational incident reporting obligations now explicitly cover third-party providers[4], and the regulators have signalled that they expect firms to have done the groundwork, not to be starting it when an incident occurs.

If you want to work through what an AI vendor assessment aligned with DORA’s requirements should look like for your firm specifically, a discovery call with Cordrey Consulting is a practical place to start.

This article is for informational purposes only and does not constitute regulated financial advice or a compliance opinion. Consult a qualified compliance professional for advice specific to your firm.

This article reflects the EU AI Act as understood at the date of publication. Implementation timelines have been subject to amendment. Verify current requirements against primary EU sources and take qualified legal advice for your specific circumstances.

This article does not constitute legal advice. Data protection obligations vary by circumstance and jurisdiction. Consult a qualified solicitor or data protection adviser for advice specific to your firm.

Sources

[1] ESMA, ‘ESAs publish first report on DORA major ICT-related incidents’, European Securities and Markets Authority, June 2026. Available at: https://www.esma.europa.eu/press-news/esma-news/esas-publish-first-report-dora-major-ict-related-incidents

[2] ESMA, ‘ESMA launches common supervisory action on CASPs’ digital operational resilience’, European Securities and Markets Authority, July 2026. Available at: https://www.esma.europa.eu/press-news/esma-news/esma-launches-common-supervisory-action-casps-digital-operational-resilience

[3] EIOPA, ‘Joint Committee Annual Report 2025’, Joint Committee of the European Supervisory Authorities, May 2026. Available at: https://www.eiopa.europa.eu/publications/joint-committee-annual-report-2025_en

[4] FCA, ‘PS26/2: Operational incident and third-party reporting’, Financial Conduct Authority, May 2026. Available at: https://www.fca.org.uk/publications/policy-statements/ps26-2-operational-incident-third-party-reporting

[5] EIOPA, ‘ESAs’ Opinion on the draft Regulatory Technical Standard on subcontracting under DORA’, European Insurance and Occupational Pensions Authority, May 2026. Available at: https://www.eiopa.europa.eu/publications/joint-committee-annual-report-2025_en

[6] Zen van Riel, ‘Deploy Production AI in 2026: Cut Errors by 50% Fast’, AI Engineer Blog, 18 July 2026. Available at: https://zenvanriel.com/ai-engineer-blog/deploy-production-ai-2026-cut-errors-50-percent

[7] EIOPA, ‘Generative AI: Market survey, outlook, use cases and risk management’, European Insurance and Occupational Pensions Authority, 2026. Available at: https://www.eiopa.europa.eu/publications/generative-ai-market-survey-outlook-use-cases-and-risk-management_en

[8] Zen van Riel, ‘Deploy Production AI in 2026: Cut Errors by 50% Fast’, AI Engineer Blog, 18 July 2026. Available at: https://zenvanriel.com/ai-engineer-blog/deploy-production-ai-2026-cut-errors-50-percent

[9] Zen van Riel, ‘Democratizing AI Through Model Optimization’, AI Engineer Blog, 18 July 2026. Available at: https://zenvanriel.com/ai-engineer-blog/democratizing-ai-through-model-optimization

[10] VentureBeat, ‘The agent security gap: 54% of enterprises have already had an AI agent incident, and most still let agents share credentials’, 18 July 2026. Available at: https://venturebeat.com/ai/the-agent-security-gap-54-of-enterprises-have-already-had-an-ai-agent-incident-and-most-still-let-agents-share-credentials