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 rules, 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: FINMA Guidance 08/2024 of 18 December 2024 and FINMA Circular 2023/1 (Operational risks and resilience) shape the expectations towards external ICT suppliers. For Austria, as of October 2026 we are not aware of any sectoral AI guideline from the FMA comparable to the BaFin guidance. When presenting its 2025 annual report in June 2026, the FMA named the use of AI in the financial sector and its upcoming supervision as a priority for the current year. 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 catalog 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, data-location specifications and service-level agreements with precise quantitative and qualitative performance targets; for AI services, these often include latency and capacity commitments in practice. 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 authorization. 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, unrestricted rights of access, inspection and audit, SLAs with precise quantitative and qualitative performance targets, and participation in TLPT. Data locations, by contrast, must already be specified in every ICT contract under Art. 30(2)(b).

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

Beyond the individual contract, DORA also addresses 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, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix, Accenture and Bloomberg. Since then, these providers have been subject to direct EU oversight. For each CTPP, a Lead Overseer (EBA, EIOPA or ESMA) conducts the oversight, including general investigations and on-site inspections, assisted by a joint examination team (Art. 33 and 38 to 40 DORA). The Oversight Forum under Art. 32 prepares joint positions and supports the Lead Overseer; it does not carry out examinations itself.

For contract design on the institution side, exit planning matters most, regardless of whether the provider is a designated CTPP: under Art. 28(8) DORA, exit plans for critical or important functions must be comprehensive and documented, and they must be sufficiently tested and reviewed periodically. The regulation does not set a fixed annual cycle. In addition, Art. 29 requires an assessment of concentration risk before a contract covering such functions is concluded. DORA does not mandate multi-cloud. As of 2026, it is open whether these exit and concentration requirements will nonetheless lead institutions to move to multi-cloud systematically or whether exit plans will remain rather symbolic. A complete multi-cloud AI architecture is technically and commercially demanding for banks. 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 bank (CRR institution) 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 catalog of Art. 30(3) therefore applies.
2. Service description and SLA: The contract sets out the scope of functions, availability and measurable target values. For fraud detection, this includes, for example, the maximum response time per transaction and detection-quality metrics such as the false positive rate.
3. Data locations: Specification that training and inference data are processed within the EU.
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 a contractual consent requirement.
5. Incident reporting: The provider is contractually obliged to report ICT incidents promptly enough that the bank 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 percent 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 sufficiently tested and reviewed periodically, as Art. 28(8) DORA requires.

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 reliable incident-reporting chain in their standard contract from the outset shorten the procurement process and qualify for regulated clients in the first place. For B2B decision-makers on the institution side, it is advisable to standardize 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 and the technical AI agent integration; the legal review of the specific contracts remains a matter for legal counsel.