DORA and AI: Operational Resilience Obligations for AI Systems in Financial Services

DORA — the Digital Operational Resilience Act — has applied to financial entities across the EU since January 2025. Its ICT risk management framework, resilience testing requirements, incident reporting obligations, and third-party risk management provisions are now live obligations for banks, insurers, investment firms, and a wide range of other financial entities.

What is less well understood is how DORA applies to AI systems specifically. AI is not mentioned explicitly in the regulation, but AI systems are ICT systems — and DORA's obligations apply to ICT systems without exception. This note maps DORA's key obligations to the specific operational risks that AI systems introduce.

Why AI systems are a DORA concern

AI systems introduce operational risks that are qualitatively different from those of conventional software. They can fail in ways that are difficult to predict, detect, or explain. Their behaviour can change over time as underlying data distributions shift. They can be manipulated through adversarial inputs. Their outputs can be biased in ways that are not immediately visible. And they often depend on third-party models, APIs, or data feeds that introduce supply chain risk.

DORA's ICT risk management framework was designed with these kinds of risks in mind — even if AI is not named explicitly. The regulation requires financial entities to identify, classify, and manage ICT risks; to test their resilience; to detect and report incidents; and to manage third-party dependencies. All of these obligations apply directly to AI systems.

Mapping DORA obligations to AI-specific risks

The table below maps DORA's core obligations to the AI-specific operational risks they address. This is not an exhaustive mapping — it is intended to illustrate the practical implications for organisations deploying AI in financial services.

The incident reporting challenge

DORA's incident reporting requirements are among the most operationally demanding aspects of the regulation. Financial entities must classify ICT-related incidents, report major incidents to their competent authority within defined timeframes, and submit detailed follow-up reports.

For AI systems, the incident classification challenge is particularly acute. AI failures are often gradual rather than sudden — a model that begins producing biased outputs, or whose performance degrades over time as data distributions shift, may not trigger the kind of clear-cut incident detection that conventional ICT failures do. Organisations need monitoring capabilities that can detect these gradual failures and processes that can determine whether they constitute reportable incidents under DORA.

The EBA's guidelines on ICT and security risk management provide additional context here. They require financial entities to have processes for detecting anomalous behaviour in ICT systems — which, applied to AI, means monitoring for unexpected model outputs, significant performance changes, and unusual input patterns that may indicate adversarial manipulation.

Third-party AI risk: the hidden exposure

Many financial institutions are deploying AI through third-party providers — foundation model APIs, AI-powered analytics platforms, and vendor-supplied decision support tools. DORA's third-party risk management requirements apply to these arrangements, but the practical implications are more complex than for conventional ICT outsourcing.

Third-party AI providers may not be able to provide the level of transparency that DORA requires. Foundation model providers, in particular, may be unwilling or unable to disclose training data, model architecture, or performance characteristics in the detail that a rigorous third-party risk assessment would require. Financial entities need to assess whether their third-party AI arrangements are compatible with DORA's requirements — and, where they are not, whether alternative arrangements are available.

The concentration risk dimension is also significant. If a large proportion of the financial sector is using the same foundation models or AI infrastructure providers, a failure or security incident at one of those providers could have systemic implications. DORA's concentration risk provisions are directly relevant here.

What a DORA-compliant AI operating model looks like

Organisations that have built DORA compliance programs need to audit those programs for AI coverage. The key questions are: Are AI systems included in the ICT asset inventory? Does the risk management framework address AI-specific risks? Are monitoring capabilities sufficient to detect AI-specific incidents? Does resilience testing include AI-specific scenarios? Are third-party AI arrangements subject to appropriate due diligence?

For most organisations, the answer to at least some of these questions will be no — not because of negligence, but because DORA compliance programs were typically designed before AI deployment became widespread. Closing these gaps requires both technical work (monitoring, testing) and governance work (risk classification, third-party assessment, incident management processes).

The intersection of DORA and the EU AI Act creates additional complexity. High-risk AI systems deployed in financial services may be subject to both regimes simultaneously — with overlapping but not identical requirements for risk management, documentation, and incident reporting. Organisations that design their AI governance programs to satisfy both regimes simultaneously will be better positioned than those that treat them as separate compliance exercises.