DORA Doesn’t Have an AI Problem. Your Threat Assessments Do.
AI and operational resilience the regulation.
There are many pieces of content, titled something close to How AI Changes Your DORA Obligations, it lists numerous things you should be thinking about, and it ends explicitly or otherwise with a phone number.
We think that take is wrong. Not slightly wrong. Wrong in a way that points firms at the wrong problem and lets them feel productive while doing it.
The consensus position is that DORA was drafted before the current AI wave, does not mention AI, and therefore has a gap that needs closing. That argument is comfortable because it puts the deficiency somewhere else rather than in your risk function. It is also, on examination, mostly false.
- High Confidence DORA’s silence on AI is a design choice, not an oversight, and it is the correct one. Technology-neutrality is a strength of the regulation: an AI system is already an ICT asset under DORA, and a foundation-model provider is already an ICT third-party service provider. Naming AI in the Level 1 text would have dated the regulation and pre-built a gap for whatever arrives next.
- High Confidence The genuine weakness is operational, not legal. DORA’s third-party risk regime and its incident-classification taxonomy were built around assumptions that AI quietly breaks and this is a Level 2/3 problem (RTS, ITS, supervisory guidance), not a reason to reopen the regulation.
- Mod–High Confidence The binding constraint on AI operational resilience is the quality of threat assessment feeding the ICT risk-management framework. Most in-scope firms are working from a generic, vendor-supplied picture of “AI risk” rather than a real adversary assessment, and DORA’s neutrality is being used as cover for not doing the harder intelligence work.
- Moderate Confidence Foundation-model concentration is a systemic exposure that DORA’s critical-third-party regime was built to catch but is only partially equipped to manage. Standard mitigations audit rights, substitutability, exit planning degrade badly against a small number of structurally irreplaceable model providers.
The lazy consensus, and why it fails
First and foremost DORA is written as a set of outcomes, not a list of technologies. It does not enumerate the systems you must protect it tells you to identify, classify, protect, detect, respond, recover, and test, and to do so across all ICT assets and all ICT third-party arrangements. That construction is doing real work. An AI model running inside a critical or important function is an ICT asset. The vendor of that model is an ICT third-party service provider. The pipeline that fine-tunes it, the vector store it queries, the orchestration layer that gives an agent its tools all of it falls inside scope already, without a single amendment.
This is not a loophole. It is the point. Regulators who name technologies in primary legislation spend the next decade watching the technology move and the text rot. The drafters of DORA chose neutrality precisely so the regulation would still bind when the threat surface changed shape. It has changed shape. The regulation still binds.
So the “DORA needs an AI update” line is not just lazy it is a category error. It treats a coverage question as if it were a coverage gap. The coverage is fine. What is not fine is something else entirely.
Where the real gap is
The legitimate weaknesses are operational, and they are specific.
Third-party risk (Articles 28–30). DORA’s third-party regime assumes you can perform meaningful due diligence, secure audit or access rights, understand the subcontracting chain, and construct a workable exit strategy. Against a frontier-model provider, several of those assumptions fail at once. You will rarely get audit access. The training data is opaque. The subcontracting chain runs into infrastructure you cannot see. And “exit strategy” becomes close to meaningless when the dependency is a model that two or three firms on earth can produce and no competitor can substitute on equivalent terms. Worse, the contract can change underneath you: a model update ships, behaviour shifts, and a control you validated against last quarter’s model is now validated against nothing. DORA’s third-party chapter did not anticipate a supplier whose product silently mutates inside the contract term.
Concentration. The same handful of foundation models now sit underneath thousands of downstream financial-services applications. That is precisely the systemic, correlated dependency the critical-ICT-third-party designation exists to surface. The designation will likely catch the largest providers. The regime’s tools for managing that exposure once designated — substitutability, resilience testing of the provider, orderly exit — are weaker against models than against, say, a cloud region.
Incident classification. The RTS taxonomy for major-incident reporting has no native category for an AI-specific failure: a prompt-injection compromise, a poisoned fine-tuning set, an agent acting outside its authorisation, or material client harm caused by a confident, fluent, wrong output. Firms will reach for the nearest existing label, and the supervisory data will be correspondingly blurred.
None of this requires amending DORA. All of it can be addressed through updated RTS, ESA Q&As, and supervisory guidance. That is the realistic and sufficient path. But notice that even fixing all of it leaves the actual problem untouched.
The actual problem
DORA’s ICT risk-management framework is only ever as good as the threat input it is built on. Article 13 expects firms to gather information on threats and vulnerabilities and to feed it back into the framework. That is the hinge. And it is where most firms are quietly failing.
The typical AI risk picture inside an in-scope financial institution today is reasoned downward from the regulation: “DORA expects us to manage ICT risk, AI is ICT, therefore we need an AI risk policy.” The policy gets written. A control matrix gets populated. A box is now tickable. What is almost never present is the thing that should have come first — an assessment reasoned upward from the adversary: who would attack our AI-enabled functions, with what capability, to what end, and how would we know.
This is the work DORA’s neutrality does not prompt you to do, and that vendor content actively discourages, because “you need a better threat assessment” does not sell a managed service nearly as well as “the regulation has a gap.”
An AI threat assessment that is actually fit for feeding an ICT risk-management framework has to run on two axes at once. The first is AI as adversary capability: deepfake-enabled social engineering against your people and your authentication flows, AI-accelerated reconnaissance and exploit development against your perimeter. The second is your own AI systems as the target surface: the customer-facing agent that can be prompt-injected, the RAG pipeline that can be poisoned, the model endpoint that can be extracted or abused. Most firms have, at best, a thin treatment of the first axis and nothing serious on the second. That is the gap. It is not in the regulation. It is in the building.
What to actually do
Four moves, in rough order of leverage:
- Build a real AI threat assessment — adversary-led, two-axis, graded — and wire it explicitly into the Article 13 feedback loop. This is the one that matters. The other three are hygiene.
- Give the ICT asset register an AI-native class. Model lineage, training and fine-tuning data provenance, the orchestration layer, and vector stores as discrete, separately attackable components — not a single line item called “AI tool.”
- Add AI-specific fields to the third-party register, and pressure-test what “exit strategy” and “substitutability” genuinely mean for each foundation-model dependency before a supervisor asks you to.
- Test the degraded-mode fallback. Firms are placing AI inside critical-function paths with no exercised path for operating when the model is unavailable, untrustworthy, or compromised. That is a business-continuity finding waiting to be written by someone other than you.
The point
DORA did not fall behind. The threat assessments being fed into it did. The regulation gives you a technology-neutral frame that already reaches every AI system you run; the constraint is the intelligence discipline applied inside that frame, and that constraint sits with you, not with Brussels.
In Part 2, we turn to the sharper end of the same problem: threat-led penetration testing. TIBER-EU was rewritten in February 2025 to align with the DORA TLPT requirements — and, like DORA, it says nothing specific about AI. We will argue that the latitude to test AI properly already exists in the framework, that almost nobody is using it, and that your TLPT scope is currently drawn around the wrong thing.
