DORA, and the model you now depend on.
DORA is not an AI regulation. It is an operational resilience regulation, and a model in a financial process is ICT you depend on — which brings it inside the risk framework, the incident regime, the testing programme and, most consequentially, the third-party rules.
What is DORA?
The EU's Digital Operational Resilience Act, which harmonises ICT risk requirements across the financial sector. It covers ICT risk management, incident reporting, resilience testing, third-party risk and information sharing — and it reaches ICT providers to the sector, not only regulated firms.
- Type EU regulation Directly applicable, with technical standards beneath it.
- Sector Financial entities A wide list — banks, insurers, investment firms, payment institutions and more.
- Reaches ICT providers Including a designation regime for critical third-party providers.
- AI status Not named, fully in scope A model in a financial process is ICT you depend on.
Who is covered?
A broad list of financial entities, plus the technology suppliers behind them.
- EU financial entities A wide definition covering most of the regulated financial sector rather than banks alone.
- ICT third-party providers Including cloud and model providers serving the sector, with a designation regime for the most critical.
- AI vendors selling into finance Your financial customers must pass contractual requirements down to you. Expect them in every negotiation.
- Groups with EU entities Scope follows the regulated entity, so a non-EU group with EU regulated subsidiaries is in through them.
How iDharma supports DORA with AI in scope
| Pillar | What the assessment does |
|---|---|
| ICT risk management | Whether the framework reaches models, inference endpoints and the pipelines behind them, or stops at the applications. |
| Asset and dependency mapping | Models mapped to the business functions that depend on them — the artefact the whole regulation is built around. |
| Incident management | Whether an AI failure would be recognised as an ICT incident, classified correctly and reported inside the window. |
| Resilience testing | Whether the testing programme covers AI-dependent services, including degraded-mode and failover behaviour. |
| Third-party risk | Model and cloud providers in the register, with the contractual provisions DORA requires actually present. |
| Exit strategies | What happens if a model provider becomes unavailable. This is where AI-dependent services are usually weakest. |
| Concentration risk | How much of the estate depends on one provider, which is a question a supervisor will ask directly. |
Exit is the hard one. Firms can usually describe a cloud exit. Very few can describe how a service dependent on a specific model provider continues if that provider stops being available — and DORA asks precisely that.
Five pillars, with models in them
The requirements are unchanged. What is listed under each is what an AI dependency adds.
ICT risk management
The framework itself
- Governance and board accountability
- Models as ICT assets in the register
- Dependency mapping to business functions
- Protection, detection and recovery
Incident management
Recognise, classify, report
- AI failures recognised as ICT incidents
- Classification against the thresholds
- Reporting inside the required windows
- Root cause that reaches the model
Resilience testing
Including the AI-dependent path
- Testing programme covering AI services
- Degraded-mode behaviour tested
- Advanced testing where it applies
- Findings tracked to closure
Third-party risk
Where AI concentrates
- Register of information kept current
- Required contractual provisions present
- Exit strategy that has been thought through
- Concentration understood and reported
Information sharing
Voluntary, useful
- Threat intelligence arrangements
- Sector participation where relevant
- Confidentiality respected
- Findings fed back into risk
What AI adds
The four new questions
- Is the model an ICT asset in the register?
- Would degradation be detected?
- Can you exit the provider?
- How concentrated is the dependency?
Four gaps we consistently find
Models absent from the register
The ICT asset register covers infrastructure and applications and stops short of the models running on them.
Degradation is not an incident
A model quietly getting worse does not trigger anything, because nothing is watching for it.
No exit for a model provider
Cloud exit is documented. Model provider exit usually is not, and the two are not the same problem.
Untested failover
A fallback path exists on the diagram and has never been exercised under load.
Bringing AI into the DORA framework
Assumes a DORA programme exists. If it does not, that comes first and this sits inside it.
-
Phase 1
Map
Dependencies first
- Add models to the ICT asset register
- Map to the business functions they serve
- Identify every provider in the path
- Assess concentration
-
Phase 2
Contract
The provisions DORA requires
- Register of information updated
- Required clauses in provider contracts
- Audit and access rights secured
- Sub-provider chains understood
-
Phase 3
Detect
Make failure visible
- Monitoring for model degradation
- Incident classification covering AI
- Reporting path rehearsed
- Thresholds agreed in advance
-
Phase 4
Test and exit
The part that is usually theoretical
- Resilience testing on AI-dependent services
- Degraded-mode behaviour exercised
- Exit strategy documented and costed
- Findings closed rather than logged
Frequently asked questions
Does DORA regulate AI?
No. It regulates operational resilience, and a model your financial process depends on is ICT within that framework. The effect is that AI is comprehensively in scope without ever being named.
We are an AI vendor, not a financial entity. Are we affected?
Through your customers, immediately and unavoidably — they must pass specific contractual provisions down to you. And if you become significant enough to the sector, the critical third-party provider designation regime is a possibility worth understanding early.
Does it apply to non-EU groups?
Scope follows the regulated entity. A non-EU group with EU regulated subsidiaries is in through those subsidiaries, and in practice the group's shared services get pulled in with them.
Is a model an ICT asset?
If a business function depends on it, treat it as one. We have yet to see an ICT asset register that included models before someone asked the question, and it is the first gap we look for.
What does an exit strategy look like for a model provider?
A documented, costed path to continuing the service without that provider — an alternative model, a degraded rules-based mode, or an accepted service reduction. The honest answer is sometimes "we would lose this capability", and stating that plainly is far better than a plan nobody believes.
Would model degradation count as an incident?
It can, if it affects the availability or integrity of a service. The practical problem is detection: most firms would not notice, which means classification never gets a chance to happen.
Ready for DORA with AI in scope?
Register, dependencies, contracts, detection and an exit strategy that survives being read aloud.
This page is guidance on how we scope an assessment, not legal advice. EU financial services counsel should confirm scope for your entities.