DORA, financial services
DORA for AI: ICT third-party risk, exit strategies and concentration risk
DORA has applied to EU financial entities since 17 January 2025. When a bank, insurer or payment institution buys model, agent or inference services, those services are ICT third-party arrangements with contract, register, concentration-risk and exit-strategy duties. The European Supervisory Authorities published the first list of critical ICT third-party providers on 18 November 2025. Swfte is not on it.
Who this applies to
- Financial entities
- Banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers and other entities in DORA's scope.
- ICT third-party providers
- Any provider of ICT services to a financial entity is in a contractual relationship governed by DORA's Chapter V. Providers designated as critical face direct oversight by the ESAs.
- Fintech and AI builders serving banks
- You will be asked for DORA-aligned contract terms, sub-outsourcing transparency and exit support even if you are not designated.
Chapter V in plain terms
See Regulation (EU) 2022/2554.
- Article 28, general principles. Financial entities remain fully responsible. They keep a register of information on ICT third-party arrangements, and must maintain exit strategies for ICT services that support critical or important functions.
- Article 29, concentration risk. Before entering an arrangement that supports a critical or important function, assess whether the provider can be replaced, whether you already depend on the same provider, and what risks arise from sub-contracting chains, including to third countries.
- Article 30, key contractual provisions. The contract must be in writing and cover, among other things, a description of services, the locations where data is processed and stored, data protection, availability, integrity, access, recovery and return of data on insolvency or termination, service levels, assistance on incidents, cooperation with authorities and termination rights. For critical or important functions it adds full service-level descriptions, participation in resilience testing, sub-outsourcing conditions and exit strategies with a mandatory transition period.
- Articles 31 to 44, critical providers. The ESAs designate critical ICT third-party providers and oversee them with a lead overseer.
Secondary commentary summarising Chapter V: Rescana, Vendorica. Read the primary text for your contract.
Critical ICT third-party providers
On 18 November 2025 the ESAs published the first list of 19 designated critical providers, according to Morgan Lewis and PwC Legal (secondary sources). The list includes large cloud providers and other infrastructure and technology providers, is reviewed periodically, and may change. Swfte is not a designated critical ICT third-party provider. For official wording, use the ESAs' own publication.
What an AI exit plan contains
- Model portability. Applications call models through a stable interface so a model or vendor can be replaced without a rebuild.
- Prompt and evaluation portability. Prompts, test sets and evaluation harnesses are stored in your control and in open formats.
- Data return and deletion. Contracted return of prompts, outputs, logs, fine-tunes and retrieval content, and deletion confirmation.
- Index rebuild. The ability to rebuild embeddings and retrieval indexes from source documents.
- Tested fallback. A named fallback model or provider, with a recorded switch-over test.
- Transition period. A contracted period of continued service while you migrate.
- Trigger list. The events that start the exit: insolvency, regulatory action, security incident, material service change.
For the broader costs of leaving a model, see model exit cost audit framework. The Data Act's cloud switching rules are a complementary lever (Data Act and AI).
Contract-clause checklist for AI vendors
| Clause | Why it matters for AI |
|---|---|
| Locations of processing and storage | Prompts, context, inference compute, logs and backups may sit in different places. Name each. |
| Sub-outsourcing and notification | Model hosts, GPU suppliers and tool providers are sub-contractors. Require notification and a right to object for critical functions. |
| Data return, deletion and insolvency access | Includes fine-tunes, embeddings and logs, not only raw documents. |
| Service levels and incident assistance | Define what an AI incident is and how the vendor assists with reconstruction. |
| Participation in resilience testing | Include red-teaming and failover tests for critical functions. |
| Exit assistance and transition period | State the period and the support, and map it to your tested fallback. |
| Audit and access rights | For you and your supervisors. |
Do not assume figures such as fine ceilings for DORA. They are set nationally, and this page does not state any.
How the platform supports it
Each row maps a requirement to a platform control, the evidence artifact it produces, and the Trust & Governance Fabric facets involved. Swfte provides the controls and the evidence. You remain responsible for the decisions.
| Requirement | Platform control | Evidence artifact | Fabric facets |
|---|---|---|---|
| Art. 28: register of information, who provides what | Trust Profile lists approved models, permitted systems and owners; sub-processor transparency. | Approved-model register; sub-processor list. | Identity, Policy, Compliance |
| Art. 28 exit strategy and Art. 29 concentration risk for model providers | A model gateway across 50+ LLMs lets you route, split or replace models behind one interface. | Routing configuration; fallback test records. | Policy, Risk, Traceability |
| Art. 30: locations of data processing and storage | Data residency recorded in the Trust Profile; EU region hosting is designed for and scoped via a dedicated deployment. | Trust Profile data-residency field and deployment description. | Data controls, Compliance |
| Incident assistance and traceability | Full action trace from data to model to agent to decision to outcome. | Reconstructable incident timeline. | Traceability, Auditability, Monitoring |
| Oversight and testing of ICT services | Monitoring, policy-decision records and evaluation of agents before release. | Monitoring dashboards and test results. | Monitoring, Risk, Evidence |
Compliance-by-design. Swfte provides the technical controls, governance mechanisms and evidence to support deployment within applicable requirements. The exact posture depends on your use case, jurisdiction, deployment and configuration. This is not legal advice.
Hosting today: customer data is stored in AWS eu-west-1 (Ireland), as stated on the trust page. EU region, in-country, dedicated and on-prem options are the platform position: what it is designed to let you do, scoped with you through a dedicated deployment engagement, not self-serve.
What this does not cover
- Swfte is not a designated critical ICT third-party provider and does not claim to meet any DORA oversight standard.
- It does not maintain your register of information or decide which functions are critical or important.
- It does not replace your own exit-strategy testing, concentration-risk assessment or supervisor dialogue.
- It does not guarantee any service level. No SLA is claimed here. Contract terms are agreed with you.
- Being able to evidence controls does not by itself meet your DORA duties. That depends on your whole ICT estate and your supervisor.
Frequently asked questions
Does DORA apply to LLM and AI vendors?
Yes, as ICT third-party service providers. A financial entity's use of model, agent or inference services falls under Chapter V: register of information, concentration-risk assessment, contract provisions and, for critical or important functions, exit strategies.
Who is a critical ICT third-party provider?
Providers designated by the ESAs. The first list of 19 was published on 18 November 2025, according to secondary sources. Swfte is not on it. Check the ESAs' official list.
What must an exit plan include?
For critical or important functions, a documented and tested strategy including a transition period, data return, and an identified alternative. See the AI exit plan section above for the AI-specific elements.
What is concentration risk for AI?
Dependence on one model vendor, one cloud region or one GPU supplier for critical functions, including through sub-contracting chains. Article 29 requires assessing it before entering the arrangement.
Does the Data Act help?
It complements DORA. Cloud switching rights, a maximum two-month notice and the end of switching charges on 12 January 2027 make exit cheaper, but they do not replace your DORA exit strategy.
Sources
Last verified 2026-10-06. Primary sources are EUR-Lex and European Commission pages. Items marked as secondary are commentary or trackers; check the primary text before relying on them.
- Regulation (EU) 2022/2554, DORA (EUR-Lex)
- Morgan Lewis: DORA, EU regulators announce list of critical ICT third-party providers (Secondary.)
- PwC Legal: ESAs publish first list of critical ICT third-party providers under DORA (Secondary.)
- Rescana: DORA third-party risk management (Secondary summary of Chapter V.)
- European Commission: Data Act explained
Across the platform
The controls on this page are part of the Trust & Governance Fabric that runs through every layer of the Sovereign Intelligence Platform.
AI governance
Governance that runs inside AI, not beside it.
AI sovereignty
Seven kinds of control over your AI estate.
Trust Profile
The record of what each AI system is and may do.
Trust centre
What Swfte can show today, and what it does not claim.
Build EU-first AI with the evidence already running
Start with one entry point. Add governance, in-region options and evidence as your requirements grow.