EU / European Union / revised 28 Oct 2026
DORA Compliance for AI Systems in Banking and Insurance
A model API used by a bank or insurer is an ICT service supplied by a third party, so DORA's third-party risk rules apply in full. DORA does not demand EU-only processing, but it does require you to know and contract for where data is processed, to keep that information in the register of information, and to have a tested way out. Routing is where those obligations become operational.
- Citation
- Regulation (EU) 2022/2554 (Digital Operational Resilience Act), Articles 28 to 30; Commission Implementing Regulation (EU) 2024/2956
- Regulator
- National competent authorities, with the EBA, EIOPA and ESMA as European Supervisory Authorities and Lead Overseers
- In force
- 17 January 2025 (date of application)
- Maximum penalty
- Administrative penalties set by Member States under Article 50; for critical ICT third-party providers, periodic penalty payments of up to 1% of average daily worldwide turnover for up to six months (Article 35)
Article 28: general principles and the register
Financial entities manage ICT third-party risk as an integral part of their ICT risk management framework and remain fully responsible for compliance when they outsource. Article 28(3) requires a register of information covering all contractual arrangements for ICT services, distinguishing those that support critical or important functions, reported to the competent authority on request. The templates are set by Commission Implementing Regulation (EU) 2024/2956.
Before contracting, Article 28(4) requires an assessment of whether the arrangement supports a critical or important function, of supervisory conditions, and of risks including concentration. Article 28(8) requires exit strategies for ICT services supporting critical or important functions.
Article 29: concentration risk
Entities must assess whether a contract would lead to dependence on a provider that is not easily substitutable, or to multiple arrangements with the same or closely connected providers. Where subcontracting chains reach third countries, Article 29(2) asks entities to weigh the insolvency law of that country and any constraints on urgent data recovery.
Article 30: key contractual provisions
Contracts must state the locations, namely the regions or countries, where contracted functions and services are provided and where data is processed, including storage location, and require the provider to notify the entity in advance if it plans to change them (Article 30(2)(b)). Contracts for critical or important functions must also include service levels, notice periods, participation in threat-led penetration testing where relevant, unrestricted rights of access, inspection and audit, and exit strategies with a mandatory transition period (Article 30(3)).
- 01
Location as a contracted, observable fact
Article 30(2)(b) makes the processing location a contractual term. A per-request receipt naming provider region and facility lets you show that the contracted location is the one actually used. - 02
Change detection
Providers sometimes move capacity between regions. Alert when a resolved endpoint's region differs from the region recorded for that arrangement in the register. - 03
Substitutability by design
An OpenAI-compatible interface across several providers keeps a second provider warm, which supports the exit strategy required by Article 28(8) and reduces concentration under Article 29. - 04
Register export
Generate the provider, service and location fields of the register of information from the routing configuration, so the register matches production rather than a procurement spreadsheet. - 05
Incident evidence
Major ICT-related incidents must be classified and reported. Gateway telemetry on latency, error rates and failover events gives the timestamps a report needs.
| # | Rule | Legal rationale |
|---|---|---|
| 01 | Allow only endpoints whose provider, region and service appear in the tenant's register of information. | Article 28(3) requires the register to cover all ICT contractual arrangements; an unregistered endpoint is an undocumented arrangement. |
| 02 | Deny requests when the resolved provider region differs from the contracted region for that arrangement. | Article 30(2)(b) fixes the processing locations in the contract and requires advance notice of changes. |
| 03 | For critical or important functions, require at least two registered providers in the failover pool, both inside the contracted jurisdiction. | Article 28(8) exit strategies and Article 29 concentration assessment favour tested substitutes. |
| 04 | Tag every request with the critical-function identifier used in the register. | Linking runtime traffic to register entries lets supervisors trace which function depended on which provider during an incident. |
eu-dora-ict
The rules above, written as Open Policy Agent Rego (v1 syntax). The gateway evaluates the pack in-process in every regional data plane before forwarding a request; YTT Secunet measures median evaluation under 3 ms in production.
Packs are versioned and signed. The version that decided each request is named in the residency receipt, so an auditor can match the decision to this exact text.
How the policy engine workspackage yttsecunet.policies.eu_dora_ict
import rego.v1
arrangement := data.dora.register[input.tenant][input.endpoint.arrangement_id]
deny contains "endpoint not in register of information" if not arrangement
deny contains msg if {
input.endpoint.region != arrangement.contracted_region
msg := sprintf("region %s differs from contracted %s", [input.endpoint.region, arrangement.contracted_region])
}
deny contains "critical function lacks a registered substitute" if {
arrangement.critical_or_important
count(input.failover_pool) < 2
}
deny contains "failover outside contracted jurisdiction" if {
some ep in input.failover_pool
ep.jurisdiction != arrangement.jurisdiction
}
default allow := false
allow if count(deny) == 0Each item is verifiable against configuration, signed receipts or contract records. Tick through it with your DPO.
Does DORA require EU data residency for AI?
No. DORA requires that locations are known, contracted and monitored, and that third-country risks are assessed. Data protection residency requirements still come from the GDPR.
Is a foundation model provider a critical ICT third-party service provider?
Designation as critical is made by the European Supervisory Authorities based on criteria in Article 31. Whether or not a provider is designated, the financial entity's own obligations under Articles 28 to 30 apply.
When did DORA apply?
DORA applies from 17 January 2025. Competent authorities began collecting registers of information in 2025.
Sovereign route ready
Stop risking 4% global turnover GDPR fines on AI inference.
Deploy sovereign, cryptographically proven AI routing in 15 minutes.