Compliance

DORA and your AI provider: the register of information checklist

Who falls under the DORA regulation, what the contract with an ICT provider must contain (articles 28 to 30), and the ten questions to put to any AI vendor.

Published July 18, 2026

DORA, the Digital Operational Resilience Act (Regulation (EU) 2022/2554), has applied since 17 January 2025. For a financial entity, it changed what choosing an AI vendor means: a purchasing decision turned regulated contractual arrangement, recorded in a register your supervisor can request at any time.

The subject is almost always covered in regulator prose or audit-firm PDFs. Here is the practitioner's version: who is in scope, what your contract must obtain from any ICT provider, and the ten questions to send your AI vendor, as they are.

Who is in scope (and who is not)

DORA applies to "financial entities": some twenty categories listed in article 2, including credit institutions, insurance and reinsurance undertakings, management companies, investment firms, payment and e-money institutions, and crypto-asset service providers.

Three cases deserve a plain answer:

  • Insurance brokers are on the list (as "insurance intermediaries"), but article 2(3) excludes those that are microenterprises or SMEs. In practice, the vast majority of French brokerage firms fall outside the scope.
  • CIFs (France's registered financial investment advisers) do not appear on the list. A wealth-advisory firm is not a financial entity within the meaning of DORA.
  • An ordinary company is not concerned. If you run an SME or mid-cap in industry, trade or services, DORA asks nothing of you: your obligations remain the GDPR and contract law. Before buying any "DORA compliance" service, check that you actually appear in the article 2 list.

You are on the list? Then every digital-services vendor, AI included, is an "ICT third-party service provider" under the regulation, and the rest of this guide concerns you directly.

Your AI vendor is an ICT provider

DORA does not regulate AI as such: it regulates the contractual relationship between the financial entity and its ICT service providers. An agent platform, a model provider, an inference host all sit in the same category as your core banking system or your CRM.

Two mechanisms carry most of the weight:

  • The register of information (article 28(3)): the financial entity maintains and updates a register of all its ICT contractual arrangements, distinguishing those that support critical or important functions. It informs its competent authority every year of newly concluded arrangements, and makes the full register available on request.
  • Mandatory contractual provisions (article 30): the contract itself must contain a minimum set of clauses, reinforced when the service supports a critical or important function.

The practical consequence: the DORA compliance of an AI project is decided before signature. A vendor unable to fill in its line of the register or to sign the article 30 clauses is a compliance problem, however good its product.

What the contract must obtain from your provider

Translated into a buyer's language, six requirements shape the contract:

Data location, written into the contract (article 30(2)(b)). The locations, regions or countries, where the services are provided and the data is processed, storage location included, appear in the arrangement, and the provider commits to notifying you before changing any of them. "Our servers are somewhere in the Union" does not satisfy this clause.

Return of data (article 30(2)(d)): access, recovery and return of your data in an easily accessible format, in the event of the provider's insolvency or discontinuation of business as well as on plain termination of the contract.

Subcontracting transparency (articles 30(2)(a) and 29(2)): the contract states whether subcontracting a service supporting a critical or important function is permitted, and on what conditions. Before signing, the financial entity assesses the risks of the subcontracting chain, especially where a subcontractor is established in a third country. For an AI service the question is concrete: who supplies the model, who hosts the inference, who sees the data.

Audit rights (article 30(3)(e)): for critical or important functions, unrestricted rights of access, inspection and audit, for you, for a third party you appoint and for your competent authority, with no other clause allowed to impede their exercise.

Exit strategy (articles 28(8) and 30(3)(f)): documented and tested exit strategies, and, in the contract, a mandatory transition period during which the provider keeps delivering the service while you migrate to another provider or bring the function back in-house. Reversibility is not a sales argument here: it is a clause.

Incident assistance (article 30(2)(f)): assistance in the event of an ICT incident related to the service, at no extra cost or at a cost set in advance.

The checklist: ten questions to send your AI vendor

Written to be pasted into an email. The answers feed straight into your register of information and your pre-contractual risk assessment.

  1. In which countries will our data be processed and stored, and do you contractually commit to notifying us before changing any of those locations?
  2. Which jurisdiction governs your company, your hosts and your subcontractors? Can an authority in a third country compel access to our data?
  3. Which parts of the service are subcontracted (models, hosting, inference, support), to whom, and where?
  4. Does the contract let us permit or refuse the subcontracting of a service supporting a critical function, and be notified of any change of subcontractor?
  5. Do you grant rights of access, inspection and audit, for us, for an appointed third party and for our competent authority?
  6. Can you produce a usable audit log: who did what, when, on which data?
  7. On termination or insolvency, in what format and within what timeframe do you return all of our data, and what does the contract guarantee about its deletion afterwards?
  8. Do you accept a mandatory transition period during which you keep the service running while we migrate or bring it back in-house?
  9. Does the service rest on formats and components that another provider or an internal team could take over, or are we captive to a proprietary architecture?
  10. Do you supply, at signature and at every change, the information needed to keep our register of information up to date?

A serious vendor answers all ten in writing. Evasive answers to questions 1 to 3 are the most telling: location can be written into a contract, jurisdiction cannot. A provider subject to the CLOUD Act cannot neutralise by clause the obligations its own law imposes on it.

The AI Act boundary, in one paragraph

DORA governs the relationship with the provider; the European AI Act governs the uses. For finance, one boundary is worth knowing: annex III classifies as high-risk the AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score (with an exception for fraud detection), along with risk assessment and pricing for natural persons in life and health insurance, with obligations applying from 2 August 2026. An agent that prepares files, extracts documents and drafts summaries is not intended for those uses: it sits outside that category. Our position fits in one line: never a credit decision, never insurance pricing, never autonomous investment advice. The agent prepares, the human decides. The full timeline is in our AI Act guide.

This vocabulary is already ours

Read the checklist again: data location, audit log, reversibility, a controlled subcontracting chain. These are the clauses DORA imposes on ICT providers, and they are the properties root Workspace is built on: your own instance in France, isolated per client, with an audit log and reversibility written into the contract, on models you control. The regulation asks of providers what sovereignty has required from the start. If your next AI project has to face the compliance desk, better that it arrives with the answers already written.

Frequently asked questions

Who falls under DORA?

The "financial entities" listed in article 2 of Regulation (EU) 2022/2554: credit institutions, insurance and reinsurance undertakings, management companies, investment firms, payment and e-money institutions, crypto-asset service providers, among others, some twenty categories in all. The regulation has applied since 17 January 2025, directly across the Union, with no national transposition.

Does DORA apply to insurance brokers and to CIFs?

Brokers are on the list as insurance intermediaries, but article 2(3) excludes those that are microenterprises or SMEs: the vast majority of French firms therefore fall outside the scope. CIFs are not on the list: a registered financial investment adviser is not a financial entity within the meaning of DORA. In both cases, the article 30 clauses remain good contractual practice; the obligation itself does not exist.

What must the contract with an ICT provider contain?

At minimum (article 30(2)): a complete description of the services and the subcontracting regime, the locations where data is processed and stored, data protection and return, service levels, incident assistance and termination rights. If the service supports a critical or important function, article 30(3) adds precise performance targets, unrestricted rights of access, inspection and audit, and an exit strategy with a mandatory transition period.

Is a non-financial company concerned by DORA?

No. An SME or mid-cap outside the financial sector has no obligation under DORA: its obligations remain the GDPR and ordinary contract law. The checklist above still works as it stands: location, audit and reversibility are sound purchasing questions, obligation or not.