DORA for AI Vendors: What Your Financial Customer's Obligation Requires From You
DORA regulates financial entities, not their suppliers — but the obligations reach you through the contract. What an AI vendor is actually asked to provide.
Who this guide is for
AI and software vendors supplying EU financial entities
TL;DR — DORA does not regulate you. It regulates your customer, and then requires them to push specific terms into your contract. The practical result is the same: you are asked for records you may not be keeping, and the ask is contractual rather than negotiable.
The Digital Operational Resilience Act — Regulation (EU) 2022/2554 — has applied since January 2025. Its subjects are financial entities: banks, insurers, payment institutions, investment firms and a long tail of others. If you are a software vendor, you are not in scope.
That is the technically correct answer, and it is why some vendors were surprised when DORA started showing up in their sales cycle anyway. The regulation obliges financial entities to manage ICT third-party risk, and it specifies what their contracts with ICT providers must contain. You experience DORA through those contracts.
The distinction that determines how hard this gets
DORA treats one question as decisive: does your service support a critical or important function of the financial entity? The contractual requirements come in two tiers, and the enhanced tier applies only to services that do.
| Baseline — Article 30(2), every ICT contract | Enhanced — Article 30(3), critical or important functions |
|---|---|
| Description of the services, and the locations where they are provided and data is processed | Full service level descriptions with precise quantitative and qualitative performance targets |
| Provisions on the availability, authenticity, integrity and confidentiality of data | Notice periods and reporting obligations to the financial entity |
| Service level descriptions | Business contingency plans, and documented ICT security measures |
| Assistance during an ICT incident at no additional cost, or at a cost agreed in advance | Participation in the entity's threat-led penetration testing |
| Full cooperation with the entity's competent authorities | Unrestricted rights of access, inspection and audit |
| Termination rights and minimum notice periods | Exit strategies with an adequate transition period |
This distinction is worth arguing carefully rather than conceding by default. An AI feature that summarises internal documents is not the same as an AI system in the credit-decisioning path, and the second one carries obligations the first does not. Getting classified into the enhanced tier when you do not belong there imports audit rights and testing participation you will be living with for the life of the contract.
Argue the classification on the function your service supports, not on how important you feel the deal is. The financial entity has to defend the classification to its supervisor, so a well-reasoned position from you is useful to them — an unsupported one is not.
You are in their register of information
Every financial entity has to maintain a register of its contractual arrangements for ICT services and report it to its supervisor. You are a row in that register. So, in some form, are the parties you depend on.
This is the part AI vendors most often miss. Your model provider is a subcontractor in your customer's supply chain — a fourth party from their point of view. If your product routes prompts to a hosted model, that provider is part of the chain the entity has to describe. Whether you volunteer it or they discover it during due diligence determines how the rest of the conversation goes.
- Name the model providers you route to, and for which functions.
- State where processing happens, at the level of region rather than marketing language.
- Say what happens if a provider degrades or withdraws a model version — including whether you can fail over and how long it takes.
- Flag when you change providers. A silent swap is a change to their register they did not make.
Incident reporting reaches you through the contract
DORA requires financial entities to classify ICT-related incidents against defined criteria and report significant ones to their competent authority on a staged clock — an initial notification, an intermediate update, and a final report with root cause. The entity carries that obligation. You carry the part of it that lives inside your systems.
In practice that means your contract will oblige you to notify them of incidents affecting their service, quickly enough that they can meet their own deadline, and with enough substance for them to classify it. An incident notice that says 'degraded performance, now resolved' does not let anybody classify anything.
AI-specific incidents are the awkward category. A model provider's rate limiting, a silent quality regression after a version change, or an agent looping and exhausting a budget are all operational incidents affecting their service — and none of them look like a traditional outage on a status page.
What counts as evidence here
DORA assessment separates design effectiveness from operating effectiveness — whether the control is built correctly, and whether it functioned consistently over time under real conditions. A policy document addresses the first. Only records address the second.
| Design effectiveness | Operating effectiveness |
|---|---|
| An architecture diagram of your AI pipeline | Per-run records showing which path traffic actually took |
| A documented escalation procedure | The incidents where it was invoked, and how long each step took |
| A change-management policy | The versioned trail of prompt and model changes with approvers |
| A described human-oversight step | The instances where a human intervened, with identity and outcome |
| A stated data-residency position | Configuration and records showing where content went |
The right-hand column is a data-retention problem before it is a compliance problem. Most of these records exist somewhere in an application for a few days and are then rotated away. The obligation is about a period, and the period is longer than your log retention.
A workable sequence
Establish whether your service supports a critical or important function for each financial customer, and write down the reasoning. This single classification drives most of what follows.
Map your fourth parties — model providers, hosting, any subprocessor in the AI path — and prepare to state them plainly. They will end up in your customer's register either way.
Extend retention for the records that answer operating-effectiveness questions, and separate them from debug logging so a retention change to one does not silently change the other.
Define what an AI-specific incident is for your product, so that a quality regression or a provider degradation triggers a notification rather than a shrug.
Package the recurring answers once. The next financial customer asks a version of the same set, and assembling it per deal does not scale.
Where Dobby fits
Dobby connects to your AI activity out-of-band — reading run telemetry from CrewAI, LangChain, OpenAI, Google ADK or a custom SDK — and never sits in the request path. Each run is evaluated against the frameworks you activate, including DORA, and the output is an evidence pack you can hand to a financial customer: executive summary, control matrix, a severity-ranked gap report with remediation, findings, framework coverage and a SHA-256 manifest.
The per-control verdict has four states — compliant, violated, needs-review, unverifiable — and the fourth is the one that matters in a DORA conversation. Operating effectiveness is exactly the kind of thing a scan can fail to prove. When the telemetry is not sufficient, Dobby reports unverifiable rather than passing the control, so the gap shows up in your gap report instead of in their audit.
Non-custodial by design: for the Fintech AI Evidence module, raw prompt and response content is routed to a dataset you own rather than held by Dobby. Run metadata and verdicts are processed in Dobby's managed control plane.
This guide is a practitioner's summary, not legal advice. DORA's requirements are set out in the regulation and its regulatory technical standards, and how they apply to a specific arrangement is a question for your counsel and your customer's.