DORA-Compliant Contracts with IT Service Providers (Art. 28 et seq.)

DORA contract design refers to the obligation of financial entities to equip contracts with IT and AI service providers under Art. 28 et seq. of Regulation (EU) 2022/2554 (DORA) with binding clauses: service description, data locations, audit rights, exit/termination, sub-outsourcing consent, incident reporting and service levels. DORA has applied since 17 January 2025 and, in BaFin supervisory practice, primarily addresses CRR institutions and Solvency II insurers.

• Who is affected? Financial entities within the DORA scope (banks, insurers and other financial entities) as well as their IT/AI service providers, who are not contractually viable without the mandatory clauses.
• What is at the core? Art. 28-30 govern ICT third-party risk; Art. 30 contains the binding set of clauses. The scope scales with the criticality of the outsourced function.
• What is the most frequent stumbling block? For hyperscalers, the clause text is standard as of 2026; for AI startups, audit rights, exit and sub-outsourcing clauses are missing and become a procurement blocker.

Why AI service providers fall under DORA

The key determination for AI projects: AI systems are not a special case but a sub-category of "network and information systems" under Art. 3(2) DORA. The BaFin guidance on ICT risks in the use of AI at financial entities, dated 18 December 2025, makes this explicit and thereby pulls the full DORA set of obligations into AI governance: Art. 5-15 (ICT risk management), Art. 24-27 (resilience testing, including threat-led penetration testing) and Art. 28-30 (ICT third-party risk). The addressees are primarily CRR institutions and Solvency II insurers.

For Switzerland, an analogous but not fully congruent regime exists: the FINMA supervisory communication 08/2024 of 18 December 2024 and FINMA Circular 2023/1 (Operational risks and resilience) shape the expectations towards external ICT suppliers. In Austria, as of May 2026, there is no formal sectoral AI guideline from the FMA; Austrian institutions largely orient themselves towards BaFin and the EBA. DORA itself, as an EU regulation, applies directly in Germany and Austria.

An important point of context up front: this article is a professional orientation, not legal advice. Model contractual clauses and their application to a specific individual case must be reviewed by legal counsel.

The set of clauses under Art. 30 DORA

Art. 30 DORA requires that the rights and obligations of the financial entity and the ICT third-party provider be clearly allocated and set down in writing. The regulation distinguishes two tiers: a minimum scope for all ICT contracts (Art. 30(2)) and an extended catalogue for services that support a critical or important function (Art. 30(3)).

Under the DORA framework, the set of clauses covers in particular mandatory audit rights, exit clauses, sub-processor controls and service-level agreements with data-residency, latency and computing-capacity commitments. For hyperscalers, this text is currently standard; for AI startups, it is a frequent procurement blocker. Background: DORA has substantially modified the former EBA Outsourcing Guidelines (EBA/GL/2019/02) as well as the ESMA Outsourcing Guidelines (ESMA50-164-4285) and transposed them into a directly applicable regulatory standard.

Simple versus critical/important functions

The depth of obligation depends on whether the outsourced ICT service supports a critical or important function - that is, a function whose failure would materially impair the institution's financial resilience, the continuity of services or compliance with the conditions of authorisation. This classification is the first task of any DORA contract design and determines the scope of the contract.

For an AI service, the guiding question is specifically: does the agent intervene in a critical process (e.g. real-time fraud detection in payments, regulatory reporting), or does it merely support a downstream, easily replaceable auxiliary process (e.g. internal text generation with no reference to customer data)? For critical/important functions, the additional requirements of Art. 30(3) apply: documented exit strategies, complete and unrestricted audit rights, SLAs with precise quantitative and qualitative performance targets, and unambiguous data-location specifications.

Mandatory clauses at a glance

The following table maps the central contractual components to their purpose and indicates whether they apply to all ICT contracts or in a stricter form for critical/important functions. The article references follow the DORA framework (Art. 30(2) for the minimum scope, Art. 30(3) for critical/important functions).

Concentration risk and CTPP designation

DORA addresses not only the individual contract but also systemic concentration risk. On 18 November 2025, the European Supervisory Authorities (ESAs) designated 19 critical ICT third-party providers (CTPPs) for the first time - among them AWS, Microsoft Azure, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix and Swift. These 19 providers are subject to direct EU oversight from 2026; the DORA Joint Oversight Forum will carry out its first comprehensive examinations over the course of 2026.

For contract design on the institution side, this has two practical consequences: exit plans must be tested annually, and multi-cloud strategies are effectively enforced. AI-agent workloads on hyperscalers remain under additional scrutiny. As of 2026, it is open whether institutions will therefore systematically force multi-cloud in practice or whether exit plans will remain rather symbolic - a complete multi-cloud AI architecture for banks is technically and commercially demanding. In DACH practice, this gives rise to a preferred sourcing pattern: sovereign or on-premise solutions for sensitive workloads, hyperscalers where the CTPP concentration risk is actively managed.

Practical example: integrating AI-supported fraud detection

A Solvency II insurer wants to deploy a third-party provider's AI agent for real-time fraud detection in payments. The steps of a DORA-compliant contract design can be outlined as follows:

1. Classification: Fraud detection is a critical or important function, because its failure materially impairs the continuity of the service. The extended catalogue of Art. 30(3) therefore applies.
2. Service description and SLA: The contract sets out the scope of functions, availability and measurable target values. Within the network, for example, the KIWI system from Finanz Informatik checks payments against 460 criteria - a benchmark for the necessary precision of the service description and performance commitments.
3. Data locations: Specification that training and inference data are processed within the EU; for Swiss customer data, the FINMA expectation of CH data storage must be taken into account.
4. Audit rights and sub-outsourcing: Unrestricted audit rights for the institution and supervisors; every subcontractor that helps perform the critical function is subject to the consent requirement.
5. Incident reporting: The provider is contractually obliged to report ICT incidents promptly enough that the insurer can meet its DORA Art. 19 reporting obligation. To put the relevance into context: in the first three quarters of 2025, 525 major ICT incidents were reported to BaFin, around 70 per cent of them by credit institutions.
6. Exit: Documented exit strategy with return of data in a usable format and migration support; the exit plan is tested annually.

In addition, there is the interface with the EU AI Act: for financial entities, DORA incident reporting under Art. 19 substitutes the reporting obligation under Art. 73 of the AI Act - with the exception of reporting fundamental rights violations. Duplicate reports can thus be avoided where the workflows are aligned with one another.

For agencies and B2B

For marketing agencies and B2B service providers selling AI solutions to banks or insurers, the message is clear: without the Art. 30 set of clauses, vendor selection regularly fails in the final round. Those who include audit rights, exit and sub-outsourcing clauses, data-location commitments and a robust incident-reporting chain in their standard contract from the outset shorten the procurement process and qualify in the first place for regulated clients. For B2B decision-makers on the institution side, it is advisable to standardise the criticality classification as a first step and to scale the contractual clauses accordingly. Blck Alpaca supports the substantive and communicative preparation of such compliance topics - the legal review of the specific contracts remains a matter for legal counsel.