DORA + EU AI Act: Dual-Regime Vendor Assessment for Financial Entities

TL;DR. Regulation (EU) 2022/2554 (DORA) entered application on 17 January 2025; Regulation (EU) 2024/1689 (EU AI Act) deployer obligations bite from 2 August 2026. Banks, insurers, payment institutions and other DORA-scoped financial entities must run a single vendor assessment that satisfies both regimes — plus BaFin MaRisk AT 9 in Germany and equivalent national rules. This guide maps the overlap, the gaps, and the structure that lets one assessment serve both audits.

1. Why financial entities cannot run these regimes in parallel silos

DORA and the EU AI Act are written for different supervisors and different harms. DORA treats ICT risk as an operational-resilience problem under EBA/ESMA/EIOPA oversight. The AI Act treats AI as a fundamental-rights and product-safety problem under the EU AI Office and national market-surveillance authorities.

For a vendor assessment they converge sharply. An AI vendor providing fraud-detection or claims-handling AI to a regulated financial entity is simultaneously:

• An ICT third-party service provider under DORA Art. 3(19), and
• A provider of an AI system under EU AI Act Art. 3(3),

…and the financial entity is simultaneously:

• A financial entity in scope of DORA (Art. 2),
• A deployer under EU AI Act Art. 3(4), and
• A regulated institution under sectoral law (CRR/CRD, Solvency II, IDD, PSD2/3) with its national framework (in Germany: KWG, VAG, ZAG, MaRisk).

Running one TPRM workflow per regime triples the artefact volume and produces inconsistent risk decisions. The defensible approach is one vendor assessment with multi-regime mapping, plus regime-specific reporting.

For background, see the EU AI Act Third-Party Risk pillar.

2. DORA Articles 28-30 — the third-party risk core

DORA's third-party regime sits in Chapter V, Articles 28 to 44. The three load-bearing articles for vendor assessment are:

Article 28(2) requires an integrated, complete, and updated ICT third-party risk strategy adopted by the management body. Article 28(3) requires a register of all third-party arrangements covering ICT services. Article 28(4) requires risk assessment before entering each arrangement, and re-assessment regularly thereafter.

Article 30(2) lists mandatory contract clauses (functions/services description; data-processing locations; SLAs and revisions; notice periods; cooperation rights with authorities; termination rights; training participation; sub-outsourcing conditions). For ICT services supporting critical or important functions, Article 30(3) adds full quantitative/qualitative SLAs, data-availability/integrity/security measures, processing regions, access/recovery rights on insolvency or termination, security-incident assistance, and audit/inspection rights for the financial entity, third parties, and competent authorities.

Each Article 30 obligation has an AI Act echo: the Art. 30(3) right of audit corresponds to Art. 26(11) cooperation; the data-region obligation overlaps Art. 26(4) input-data oversight. Mapping these to a single contract addendum is the operational-efficiency target for 2026 procurement teams.

3. Critical ICT Third-Party Providers (CTPP) — the supervisory layer

DORA Articles 31-44 introduce a Union-level oversight regime for ICT providers designated as critical (CTPP). Designation criteria (Art. 31(2)) include:

• Systemic impact on financial services in case of operational failure
• Importance of financial entities relying on the provider, including counts and concentration
• Reliance on multiple critical/important functions
• Substitutability of the provider

The European Supervisory Authorities (Joint Committee) designate CTPPs and exercise direct oversight via a Lead Overseer. Recommendations to a CTPP carry direct effect on financial-entity decisions.

For AI vendors: a foundation-model provider that becomes embedded in the AI layer of the EU financial system is a plausible future CTPP candidate. The current CTPP candidate pool is dominated by hyperscale cloud and core-banking providers, but the AI layer is rising fast.

Procurement implication: when assessing an AI vendor that depends on hyperscale cloud (OpenAI on Azure, Anthropic on AWS, Google models on GCP), the underlying cloud is plausibly a CTPP. Concentration risk must be assessed at the cloud layer, not just the AI vendor layer.

4. The dual-regime vendor scorecard

A single 13-dimension assessment can serve both DORA and AI Act with regime-specific tagging. The mapping:

Each dimension produces a finding that can be exported into both the DORA register (Art. 28(3)) and the AI Act vendor file simultaneously.

5. BaFin MaRisk AT 9 — where DORA inherits German specificity

Germany's MaRisk (Mindestanforderungen an das Risikomanagement) AT 9 module governs outsourcing for credit institutions and securities firms under KWG. The 7th amendment in 2023 aligned MaRisk AT 9 toward DORA's structure ahead of DORA's January 2025 application.

MaRisk AT 9 layers German specificity onto DORA in three areas relevant to AI vendor assessment:

• Risk-bearing capacity assessment. MaRisk AT 9 requires institution-specific concentration analysis tied to the bank's risk-bearing capacity (Risikotragfähigkeit), not just sector-level concentration as DORA Art. 29 contemplates.
• Significant outsourcing classification. MaRisk AT 9.1 establishes "wesentliche Auslagerungen" with stricter governance and information rights. AI vendors integrated into core banking processes (credit decisioning, fraud, AML) almost always cross the materiality line.
• Notification obligations. Section 24 KWG and MaRisk AT 9 require BaFin notification for significant outsourcing arrangements; the requirements stack on top of DORA Art. 28(3) register obligations.

For an insurer, the parallel German overlay is BaFin's VAG-VAIT and the Solvency II outsourcing rules under §32 VAG. For payment institutions, BAIT under ZAG. The structural pattern is identical: DORA is the floor, German sectoral guidance is the institution-specific overlay.

For comparison of how generic TPRM tools handle MaRisk AT 9 specificity, see the PartnerScope vs Vanta comparison.

6. Incident reporting under both regimes

A serious incident at an AI vendor can trigger reporting under three different regimes simultaneously:

A single incident — say, a fraud-detection model that misclassifies and exposes customer data — can require all three reports in different formats, in different windows, to different authorities. The vendor contract under DORA Art. 30 must contain the cooperation clauses that make this possible. The AI Act side requires Art. 26(5) coordination from the deployer back through the provider chain.

Procurement teams should pre-negotiate the incident-relay clause with explicit timelines aligned to the strictest of the three windows.

7. Concentration risk — the cross-regime sharpest edge

DORA Art. 29 requires preliminary assessment of ICT concentration risk before entering arrangements. The factors:

• Existence of substitutable providers
• Migration costs and complexity
• Sub-outsourcing chains
• Dependencies on a single provider for multiple critical functions
• Geographic concentration of operations and data

For AI vendors in 2026, concentration risk has three layers that a single-regime assessment misses:

1. Vendor concentration. How many of your AI workflows depend on this vendor?
2. GPAI concentration. How many of your AI vendors depend on the same underlying foundation model? See the GPAI deployer cluster.
3. Cloud concentration. How many of your AI vendors and GPAI providers run on the same hyperscale cloud?

The third layer is often invisible to a single TPRM workflow because each AI vendor declares its own cloud as a sub-processor without revealing the cumulative concentration across the financial entity's full vendor population. Aggregating across the DORA Art. 28(3) register surfaces this; running per-vendor questionnaires does not.

8. Frequently asked questions

My bank is in scope of DORA. Does the EU AI Act add anything? Yes. DORA covers ICT operational resilience; the AI Act covers AI-specific risks (classification, GPAI, FRIA, prohibited practices). Article 26 deployer obligations apply to your bank's AI vendors regardless of DORA. The two regimes overlap heavily on contract clauses and incident reporting but do not substitute.

Are AI vendors automatically critical ICT third-party providers (CTPP)? No. CTPP designation is at Union level by the Joint Committee under DORA Art. 31. Most AI vendors are below the threshold; some hyperscale cloud and a small number of foundation-model providers are plausible candidates. The designation list is published and updated by the ESAs.

How does Article 27 FRIA relate to DORA risk assessments? The Article 27 fundamental rights impact assessment under the AI Act is mandatory for Annex III(5)(a) public-benefits eligibility deployment, certain Annex III(6) law-enforcement deployments, and deployments by private parties providing public services. For financial entities providing essential services (Annex III(5)(b) credit, Annex III(5)(c) insurance pricing), FRIA is not formally mandatory but is best-practice. DORA does not require FRIA but does not preclude it.

Where does the BaFin MaRisk AT 9 register sit relative to DORA Art. 28(3)? The DORA Art. 28(3) register is the floor. MaRisk AT 9 layers German-specific data points (notification status, significant-outsourcing classification, risk-bearing capacity allocation). One internal register can serve both, with MaRisk-specific fields appended. A vendor assessment should populate both simultaneously.

Can one PartnerScope assessment satisfy both DORA and AI Act inputs? Yes. The 13-dimension scorecard maps every dimension to both regimes (and to NIS2 / CSDDD where applicable). Every Pro and Enterprise assessment delivers a regime-tagged findings export that can be filed into both the DORA Art. 28(3) register and the AI Act vendor file with no rework. Pricing remains €299 (Pro) or €4,900/quarter (Enterprise for 15 vendors).

CTA

Run a free 60-second EU AI Act Snapshot at partnerscope.eu — designed to plug into DORA Art. 28(3) registers and BaFin MaRisk AT 9 documentation. Or read the complete pillar guide.