DORA and AI vendor outsourcing: what financial entities have to do

DORA is the EU's first horizontal regulation on operational resilience for the financial sector. It consolidates and replaces a patchwork of EBA, EIOPA and ESMA guidelines on outsourcing and ICT risk into one binding text with five pillars: ICT risk management (Articles 5-16), ICT-related incident reporting (Articles 17-23), digital operational resilience testing (Articles 24-27), third-party ICT risk management (Articles 28-30) and information sharing (Article 45) [1].

AI services - whether a foundation-model API, a hosted classifier, an agentic workflow platform or a custom-built model managed by an AI consultancy - are treated as "ICT services" under Article 3(21). That means every AI vendor providing services that support critical or important functions of a financial entity falls inside the third-party ICT risk regime. There is no AI carve-out, no de minimis threshold, and no exception for "non-cloud" AI services.

Scope covers credit institutions, payment institutions, e-money institutions, investment firms, AIFMs, UCITS managers, central counterparties, trade repositories, crypto-asset service providers, insurance and reinsurance undertakings, and a long tail of other regulated entities. The European Supervisory Authorities estimate roughly 22,000 entities are directly bound, plus their entire ICT supply chain by contractual flow-down [2].

Articles 28 to 30 are the heart of the third-party regime. Article 28 sets out general principles: financial entities remain fully responsible for compliance even when they outsource, must integrate ICT third-party risk into their overall risk-management framework, and must maintain a register of information on all contractual arrangements for ICT services. The register is reportable annually to competent authorities under the Implementing Technical Standards.

Article 29 imposes a pre-contractual due-diligence requirement: assess whether the arrangement covers a critical or important function, evaluate the provider's suitability, identify concentration risk and account for sub-contracting chains. Article 30 sets the mandatory contractual provisions, which include description of services and locations of data processing, service-level agreements with measurable targets, audit and access rights for the financial entity and the competent authority, incident-reporting cooperation, exit strategy and transition support, and insolvency safeguards.

For AI vendors, the practical impact is that standard SaaS-style click-through terms do not satisfy DORA. Contracts must give the financial entity (and its supervisor) on-site audit rights, data-location commitments, sub-processor controls and a documented exit plan that lets the entity migrate the workload to an alternative provider without prohibitive switching costs [3].

DORA introduces a new direct supervisory regime for ICT providers designated as Critical Third-Party Providers (CTPPs). The European Supervisory Authorities, jointly via the Joint Examination Teams led by the lead overseer, publish the criticality criteria and the list of designated CTPPs. Designation criteria include systemic impact, sector concentration, substitutability of the service, and the entity's network of clients in the financial sector.

CTPPs are subject to direct oversight powers including general investigations, on-site inspections, recommendations and, in extremis, financial penalties of up to 1% of average daily worldwide turnover. The first CTPP designations are expected during 2026, and large hyperscale cloud providers and several systemic AI infrastructure providers are widely anticipated to be in the first cohort. Even AI vendors that are not designated CTPPs feel the impact through their hyperscale dependencies, since financial entities must trace and document the sub-contracting chain.

The practical consequence for buyers: when scoping an AI engagement, it is no longer enough to know who the immediate AI vendor is. The financial entity must document the upstream model provider, the hosting region, the operational support locations and the realistic migration path to a substitute provider.

DORA is supplemented by a body of Level 2 measures - Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) developed by the ESAs. The RTS on threat-led penetration testing (TLPT) sets out the requirements for advanced testing of critical ICT systems, modelled on the TIBER-EU framework. Financial entities must run TLPT at least every three years on systems supporting critical or important functions, which can include AI inference pipelines and decision-support systems used in customer-facing or risk-management workflows.

The RTS on classification of ICT-related incidents and the ITS on incident reporting impose tight notification timelines: an initial notification within 4 hours of classification as major, an intermediate report within 72 hours, and a final root-cause report within one month. AI-specific incidents - model outages, severe accuracy degradation, prompt-injection breaches affecting integrity, training-data leaks - all qualify when they affect a critical function, and the incident report must include the third-party provider involved.

Pooled testing arrangements are permitted, which means multiple financial entities can test a shared CTPP jointly. Buyers should confirm in vendor selection whether the AI provider supports pooled TLPT participation, since the cost and disruption of running fully bilateral tests is otherwise borne entirely by the financial entity [4].

DORA and the EU AI Act (Regulation 2024/1689) are complementary, not overlapping. DORA governs the operational resilience of the system - availability, recoverability, third-party risk, incident reporting. The AI Act governs the AI-specific properties of the system - risk classification, training data, transparency, human oversight, accuracy and post-market monitoring. The same AI system in a bank's credit-scoring pipeline is subject to both regimes simultaneously: DORA for the ICT-resilience layer, AI Act Annex III high-risk obligations for the AI substantive layer.

For high-risk AI systems under the Act, Article 17's quality management system overlaps materially with DORA's ICT risk-management pillar. Enterprises that build a unified governance programme - one register that captures ICT contracts, AI Act technical documentation, and ISO/IEC 42001 management-system evidence - avoid duplicate work. Treating them as three separate streams typically triples the documentation burden without improving resilience.

Impetora's TRACE methodology was designed for AI systems that have to survive bank, insurer and asset-manager third-party risk reviews. Trust covers the contractual layer: data residency commitments, sub-processor disclosure, audit rights, exit and transition planning aligned with Article 30. Readiness produces the workflow and data audit that becomes the input to the financial entity's own register of information and risk-classification work. Architecture covers the production-grade design with logging, monitoring, recoverability and segregation that DORA's ICT risk-management pillar expects. Citations and Evidence covers the audit-trail layer that is reportable to competent authorities on request.

The practical path for a financial-services AI engagement: scope the system against the criticality criteria first, document sub-processor and hosting chain explicitly, draft exit and transition plans as part of the design (not as an afterthought), and structure incident-response runbooks that meet the 4-hour, 72-hour and one-month reporting windows.