Regulation (EU) 2022/2554 has applied since January 2025, harmonising ICT risk across the EU financial sector under five pillars. Directly applicable rather than transposed, it reaches the providers behind regulated firms as well as the firms, and it is supervised rather than certified by anybody.
DORA never mentions artificial intelligence. It does not need to.
A model your financial process depends on is ICT. That is the whole mechanism.
Our promise
“A clause is intent. The register is evidence.”
Every finding is written against a clause of the instrument itself — defensible line by line, to anyone who asks. The fee is fixed at $12,500, and nothing is charged until you approve it.
- Each additional system
- $3,000
- Re-audit, same scope
- $8,000
- Renewal, every twelve months
- $10,500 locked
This costs more than the estate ladder, and it should. The ladder is a private assessment written for you. A framework audit produces a published summary iDharma maintains for twelve months - a notice template where the law requires one, a 60-day expiry warning, and a quarterly check that the summary is still live and still linked.
Request this auditDORA, in three chapters
Nowhere in the text does artificial intelligence appear, and that is not an omission — DORA regulates dependency rather than technology. A model a business function relies on is ICT you depend on, which puts it inside all five pillars without one line written about models anywhere.
Most firms can describe leaving a cloud provider, because that work was done years ago. Very few can describe how a service built around one model provider carries on without it — and that is exactly what the third-party pillar asks, of the dependency that is hardest to replace.
Not a list of technologies, a list of dependencies.
If a function stops without it, it belongs in the register.
- EU financial entities, on a wide definition
- ICT providers serving the sector, including model providers
- AI vendors, through their customers’ contracts
- Non-EU groups, through their EU subsidiaries
- A business function that would stop without it
- A provider outside your walls who runs it
- A path into a service customers actually use
- A failure mode nothing currently watches for
The model is theirs. The duty is yours.
The entity the function belongs to
Outsourcing the model does not outsource the obligation. The regulated entity answers for the resilience of every service it runs, including the parts somebody else operates - and a supervisor will ask you, not your provider, about a dependency that you did not build and that you cannot see inside.
The supplier who gets it passed down
Financial customers must carry specific contractual provisions down to their ICT providers, so an AI vendor selling into the sector meets DORA through every negotiation. Become important enough to the sector and the critical-provider designation regime becomes a live question for you.
We assess. They supervise
There is no DORA certificate and nobody issues one, because your competent authority forms its own view of you. We map the dependencies, test all five pillars and write down what is missing - which is the work that has to exist before any supervisory conversation you have goes well at all.
“We have an exit plan — it covers the cloud.”
Your model provider is not your cloud.
It is the gap we find most often, and the hardest one to close late.
- Who it is for
- EU financial entities
- ICT third-party providers
- AI vendors selling into finance
- Groups with EU subsidiaries
- Payment institutions
A model quietly getting worse triggers nothing, because nothing is watching for it. Detection missing means classification never runs.
Cloud exit is documented and model-provider exit usually is not. They are different problems, and only one of them was rehearsed.
A fallback path exists on the diagram and has never been exercised under load. Untested failover is a finding waiting to be written.
Three questions. Then you’ll know.
No email. No signup. A starting point, not a determination.
Your dependency check
Four moves, and the first one decides the rest.
Assumes a DORA programme already exists. Where one does not, that comes first and all of this sits inside it rather than beside it.
-
Map
Before anythingEvery model added to the ICT asset register, and mapped to the business function that stops without it.
-
Contract
Then contractThe register of information brought current, the required provisions present, sub-provider chains followed.
-
Detect
Before it failsMonitoring that would notice degradation, and a classification path that treats it as a real incident.
-
Test and exit
Every day afterFailover exercised rather than diagrammed, and an exit strategy somebody has actually sat down and costed.
Teams reach for the contracts first, because clauses are tractable and dependencies are not. A provision added to an agreement for a system nobody mapped protects a dependency you have not identified - which is paperwork, not resilience.
What the regulation asks, what we ship
The five pillars, and the three artefacts that carry them. Paired, so every claim can be checked against the ask.
- ICT risk management Pillar 1 - The framework itself
- Whether the framework actually reaches models, inference endpoints and the pipelines behind them, or quietly stops at the applications sitting above them - which is where most ICT risk frameworks were last revised.
- Incident management Pillar 2 - Recognise, classify, report
- Evidence that an AI failure would be recognised as an ICT incident rather than a product defect, classified against the thresholds, and reported on a clock that starts when classification happens.
- Resilience testing Pillar 3 - Including the AI path
- A testing programme that reaches AI-dependent services, with degraded-mode behaviour exercised under load rather than assumed - what the service does when the model is slow, wrong or simply gone.
- Third-party risk Pillar 4 - Where AI concentrates
- Model and cloud providers carrying the provisions the regulation requires, with audit and access rights secured and the sub-provider chain behind each one followed all the way to the end.
- Information sharing Pillar 5 - Voluntary, and useful
- Threat intelligence arrangements that feed something rather than sit in a policy, with confidentiality respected and whatever comes back reaching the risk function that can act on it.
- The register The artefact everything hangs off
- Models entered as the ICT assets they are, each mapped to the business function that stops without it, and the contractual arrangement behind each provider recorded where the register expects it.
- The exit The one almost nobody has
- A documented, costed path to running the service without that provider - an alternative model, a degraded rules-based mode, or an accepted reduction, including where the honest answer is losing the capability.
- Concentration The question asked directly
- How much of the estate rests on a single provider, counted rather than felt, and stated in your own words before a supervisor asks the question in theirs.
The dependency, independently traced
From one regulated entity to the whole group.
-
Map
Every model, and the business function that would stop without it.
-
Test the five
All five pillars against the estate as it actually runs, AI included.
-
Report and hand over
You see the draft first. Then the register, the gaps and the exit work - dated.
Why teams choose iDharma to trace the dependencies
Independent by design
We sell none of the models, platforms or tooling we assess. Nothing we find is convenient for us.
Dependency, not tech
We assess what stops when a model does, which is the question this regulation actually asks.
The exit gets written
Including where the honest answer is that a capability would be lost. Better said than implied.
Financial-sector fluent
The register, the pillars and the supervisor are the vocabulary here, not an afterthought.
Four marks, struck on every report.
What you get
Concrete artefacts, each with a name and a format - you know what lands before you buy.
DORA readiness report
The full assessment: where the estate stands against all five pillars with the AI dependency treated as first-class rather than annexed, each gap ranked by supervisory consequence rather than by how easy it is to close. Where scope is genuinely arguable - and across a group with EU subsidiaries it usually is - it says so instead of picking the convenient reading.
Dependency map
Every model, endpoint and pipeline traced to the business function that stops without it, and to each provider standing behind it.
Register entries
The rows your register of information is missing, drafted in the shape it expects, with the contractual arrangements behind each one identified.
Contract gap list
Which of the required provisions are absent from which agreement, and which sub-provider chains nobody has yet followed all the way to the end.
Exit strategy
How each AI-dependent service continues without its provider, priced - including where the honest answer is that it would not continue.
Detection review
Whether model degradation would be noticed at all, and whether whatever notices it reaches somebody who is able to classify and report it.
Policy and procedure set
The ICT governance documents the pillars expect, under version control and written to your operations rather than to a template.
Real numbers, upfront.
- Scope
- Set on the scoping call
- Output
- A gap list, not a clearance
- Re-review
- As the estate changes - $10,500 against your mapped dependencies
The scoping call settles which entities are in, and prices it. Nothing is charged before you approve that scope.
Request this assessment- Dependency map & register entries
- All five pillars tested, AI included
- 29 policy and procedure documents
- Exit strategy, costed per service
Four things a supervisor will ask you to produce
DORA is not graded on intent. Each of these is either in your hand on the day somebody asks, or it is not.
The register,
current
Models entered as ICT assets, each mapped to the function that depends on it. A register predating your AI estate describes a firm you stopped being a while ago.
The contract,
checked
The provisions the regulation requires, actually present in the agreements you hold today, with the sub-provider chain behind each one followed all the way through.
The alarm,
wired
Something that would notice a model getting quietly worse. Without detection, classification never gets its chance and the reporting clock never starts at all.
The exit,
costed
How the service continues without that provider, priced. Sometimes the answer is that it would not, and writing that down plainly beats a plan nobody really believes.
Four cards, and the date on each one is part of the card.
Plain answers
Scope, vendors, the register, the exit, cost. Answered straight.
Request this assessmentDoes 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 worth understanding early.
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 somebody 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 reduction in service. Sometimes the honest answer is that the capability would be lost, and saying so plainly beats a plan nobody believes.
What does an iDharma DORA assessment cover, and what comes with it?
A scoping call first, because scope across a group is the variable that matters. Then the dependency map, the register entries, the contract gap list, detection review, a costed exit strategy and the policy suite the assessment writes against.
Request your DORA assessment
Tell us which entities are in and we come back with a scoping call inside a day.
What we need from you
Nothing you do not already have. Most of it comes out of your ICT register and your provider contracts, in an afternoon, and we tell you which of it extracts first.
- Which entities in the group are regulated, and where
- The ICT asset register as it stands today
- Contracts with your model and cloud providers
- Any existing DORA gap analysis, however partial
- What each AI-dependent service would do without it
What happens next
- You send the five items we need.
- We call to scope it within one business day.
- Nothing is charged until you approve the scope.
Where this page gets its facts
Where the claims on this page come from, and what they are worth - stated, not assumed.
What it is drawn from
- Regulation (EU) 2022/2554, the Digital Operational Resilience Act
- The technical standards published beneath it
- Applying since
- January 2025
- Enforced by
- Competent authorities
What it means
- General information about what the regulation requires — not legal advice, and not a determination about your entities.
- Where scope is genuinely arguable, and across a group with EU subsidiaries it usually is, our reports say so rather than pick the convenient reading. EU financial services counsel should confirm scope for your entities.
Scope & limitation
- No reporting window, article count or penalty figure appears on this page. The five pillars are printed because they are certain; the exact incident timelines and classification thresholds are not checked here, member-state penalties differ across the Union, and an unchecked figure on an indexed page is a published claim. Read those from the regulation and your authority.
- There is no certificate, from iDharma or anyone. DORA is supervised, not certified. We map, test and write down what is missing.
Something on this page out of date?
Tell usFrom Insights
Before you commission one
How to Prepare for an AI Audit: The Readiness Checklist
Six things to have ready before the engagement starts. Assembling them takes a fortnight off the clock — and tends to find the first two findings before an auditor does.
What Is an AI Audit? Scope, Standards, and What You Get
An independent review of what your AI actually does, measured against a named standard — not a certificate, and not a review of what the documentation says it does.
What an AI Governance Framework Actually Contains
Five working parts, not a policy document. What each one has to do, how to tell whether yours is real, and why a framework is not the same thing as compliance.
Startups, Meet Your AI Stack: Budget‑Friendly Tools That Scale
For early-stage founders, building an AI-powered toolkit doesn’t have to break the bank. From ideation to growth mode, here’s how startups can tap into affordable, effective AI tools to autom