DORA · EU 2022/2554 · FIVE PILLARS

DORA never mentions artificial intelligence. It does not need to.

A model your financial process depends on is ICT. That is the whole mechanism.


A compliance professional seated at a desk in a warm, low-lit office, signing a printed document with a pen, further papers and a cup of coffee on the desk beside them and a window throwing daylight across the page.
Dependency is the thing being regulated
ICT risk Incident reporting Resilience testing Third-party risk Information sharing

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 audit
The case file

DORA, in three chapters

The Regulation

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.

The Silence

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.

The Exit

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.

What is in scope

Not a list of technologies, a list of dependencies.

If a function stops without it, it belongs in the register.

Who is caught № 01
  • 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
DORA · iDharma · Presented for review
What pulls a model in № 02
  • 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
DORA · iDharma · Presented for review
Whose job is which

The model is theirs. The duty is yours.

You

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.

Your provider

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.

The line

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.

What most teams assume

“We have an exit plan — it covers the cloud.”

What the regulator asks

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
Why this matters in 2026
A large bound ledger lying open under a brass lamp, its pages carrying printed tables and charts, with a red ribbon marker between them and a fountain pen resting alongside.
01 The ICT asset register covers infrastructure and applications, and stops short of the models running on them — which means every pillar beneath it is assessed against the wrong estate.
02

A model quietly getting worse triggers nothing, because nothing is watching for it. Detection missing means classification never runs.

03

Cloud exit is documented and model-provider exit usually is not. They are different problems, and only one of them was rehearsed.

04

A fallback path exists on the diagram and has never been exercised under load. Untested failover is a finding waiting to be written.

The 60-second check

Three questions. Then you’ll know.

No email. No signup. A starting point, not a determination.

0 of 3

In the register -

The register decides what gets assessed. Registers were built when the estate was infrastructure and applications. Models arrived afterwards, as product features rather than as ICT anybody catalogued.

Detection -

Detection comes before classification. Reporting runs on a clock that starts when an incident is classified. Nothing raised means nothing classified, so a detection gap is a reporting gap in disguise.

Exit position -

A cloud exit is not a model exit. The estate was built to move off a cloud. It was not built to move off a model, because outputs are not equivalent and prompts do not transfer cleanly.

The calendar

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.

  1. Map

    Before anything

    Every model added to the ICT asset register, and mapped to the business function that stops without it.

  2. Contract

    Then contract

    The register of information brought current, the required provisions present, sub-provider chains followed.

  3. Detect

    Before it fails

    Monitoring that would notice degradation, and a classification path that treats it as a real incident.

  4. Test and exit

    Every day after

    Failover exercised rather than diagrammed, and an exit strategy somebody has actually sat down and costed.

The trap

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.

Pillar & artefact

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 engagement

The dependency, independently traced

From one regulated entity to the whole group.

  1. Map

    Every model, and the business function that would stop without it.

  2. Test the five

    All five pillars against the estate as it actually runs, AI included.

  3. Report and hand over

    You see the draft first. Then the register, the gaps and the exit work - dated.

Request an assessment
An auditor in a black trouser suit over a black top, with a dark bob, standing against a warm pale wall and pointing into the open space alongside.
The dependency map, settled before anyone contracts against it.
Struck in your favour

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.

Deliverables

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.

Data map

Dependency map

Every model, endpoint and pipeline traced to the business function that stops without it, and to each provider standing behind it.

Drafted

Register entries

The rows your register of information is missing, drafted in the shape it expects, with the contractual arrangements behind each one identified.

Per provider

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.

Costed

Exit strategy

How each AI-dependent service continues without its provider, priced - including where the honest answer is that it would not continue.

Per service

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.

Repository

Policy and procedure set

The ICT governance documents the pillars expect, under version control and written to your operations rather than to a template.

Format & fee

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
DORA · Readiness assessment $12,500 flat
  • Dependency map & register entries
  • All five pillars tested, AI included
  • 29 policy and procedure documents
  • Exit strategy, costed per service
Show your hand

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.

FAQ

Plain answers

Scope, vendors, the register, the exit, cost. Answered straight.

Request this assessment
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 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.

Get started

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.

  1. Which entities in the group are regulated, and where
  2. The ICT asset register as it stands today
  3. Contracts with your model and cloud providers
  4. Any existing DORA gap analysis, however partial
  5. What each AI-dependent service would do without it

What happens next

  1. You send the five items we need.
  2. We call to scope it within one business day.
  3. Nothing is charged until you approve the scope.
Request an assessment
Sources & standing

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 us