DORA and AI Insurance: What Financial Firms Need

Since 17 January 2025, the Digital Operational Resilience Act has been the governing framework for ICT risk management across the European financial sector. Banks, investment firms, insurance undertakings, payment institutions, crypto-asset service providers, and a range of other financial entities are now required to operate under a documented, board-accountable ICT risk framework, to report major incidents to their supervisors, to test their operational resilience, and to manage the risks posed by third-party ICT suppliers.

What the regulation could not have anticipated in full when it was adopted in November 2022 is the speed at which AI systems would move from pilot to production inside financial services. By the time DORA came into force, a substantial number of the financial entities it covers were already operating AI-assisted credit decisioning, fraud detection, customer communication, document processing, and trading support systems. More are deploying now. The question facing risk managers and compliance officers is how DORA's obligations apply to those systems, and where the insurance instruments available in 2026 do and do not address the exposure.

This article works through the relevant DORA provisions, their specific implications for AI systems, the additional layer introduced by the EU AI Act, and the coverage gaps that remain after existing cyber and professional indemnity policies are read against AI-specific failure modes.

DORA's ICT Risk Framework and AI Systems

DORA Article 3(16) defines ICT risk as the risk of losses related to the use of network and information systems, including losses due to the improper or erroneous functioning of applications, processes, or hardware. That definition is broad enough to reach any AI system that is integrated into the operational processes of a financial entity. A credit scoring model that produces erroneous outputs, a fraud detection system that fails to flag a transaction class, a document summarisation tool that introduces errors into a compliance workflow: each of these is an ICT risk event within the DORA definition.

Article 5 of DORA places responsibility for the ICT risk management framework directly on the management body of the financial entity. Senior management cannot delegate accountability downward and treat AI risk as a technical matter for the IT department. The board or equivalent governance body must approve the ICT risk management framework and ensure that adequate resources are allocated to its implementation. This is a structural change from the pre-DORA position in many European financial institutions, where AI governance often sat at the business unit level without board-level sign-off.

Article 6 requires the ICT risk management framework to be comprehensive, documented, and reviewed at least once a year. AI systems used by financial entities fall within this framework. The annual review obligation means that a financial entity cannot onboard a new AI model, run it for eighteen months, and claim that DORA has been satisfied because the framework was documented at the point of initial rollout. The framework review must account for the current state of deployed AI, including any systems added, modified, or retired since the last review.

Protection, Detection, and Recovery Under Articles 9 to 11

Articles 9 to 11 of DORA set out the substantive technical and operational requirements for ICT systems within scope. Article 9 covers protection and prevention, including change management procedures, data quality controls, and backup procedures. For AI systems, these requirements translate directly into version control for models, data lineage documentation, and rollback procedures in case a model update introduces degraded performance or biased output. Article 10 requires financial entities to have detection mechanisms for anomalous activities in ICT systems. Model drift, a gradual degradation in AI model performance due to changes in the data distribution it encounters in production, is precisely the kind of anomalous pattern that Article 10 contemplates. Detection is not passive monitoring. The regulation requires active surveillance that can identify when a system is operating outside its intended parameters.

Article 11 requires financial entities to have documented response and recovery plans for ICT-related incidents. A failure of a critical AI system, such as a fraud detection model going offline or producing systematically incorrect outputs, is an ICT incident within the meaning of DORA. The response plan must address AI-specific failure modes, not only classical ICT events such as system outages and ransomware. A response plan written entirely around infrastructure incidents will not satisfy Article 11 when the triggering event is a model failure rather than a hardware or connectivity loss.

Incident Reporting and the AI Paper Trail

Articles 17 to 23 of DORA establish the regime for reporting ICT-related incidents to the competent authority. Major ICT incidents must be reported within specified timeframes: an initial notification can be required within four hours of classification, an intermediate report follows, and a final report closes the file. The classification criteria for what constitutes a major incident are set out in the Commission Delegated Regulation published under DORA, and include thresholds for the number of clients affected, the financial impact, and the duration of the disruption.

For AI systems, the reporting obligation creates a formal paper trail that will be reviewed by both the competent authority and, in the event of subsequent claims, by insurers. An AI incident that produces a large volume of erroneous outputs, affecting a material portion of clients or generating regulatory exposure, may cross the classification threshold and require reporting. Once reported, the incident is on record. Any insurance claim arising from the same event will be measured against the regulator's own record of the incident narrative.

This interaction between the DORA incident record and the insurance claims process has practical consequences. A financial entity that reports an AI incident to its supervisor under DORA but later files an insurance claim that contradicts the regulatory narrative is in a difficult position. The two filings should be prepared in coordination, with a single incident response team that owns both the regulatory notification and the insurance notification. Most current AI liability policies include a cooperation clause requiring the insured to notify the insurer promptly. The DORA reporting timeline and the policy cooperation clause need to run in parallel from the moment an incident is classified.

Third-Party ICT Risk: AI Providers as Regulated Counterparties

Articles 28 to 44 of DORA constitute the most operationally demanding part of the regulation for financial entities that rely on external AI providers. The third-party ICT risk management framework requires financial entities to maintain a register of all ICT third-party service providers, to assess concentration risk, to require contractual provisions covering audit rights, security requirements, and business continuity, and to conduct ongoing monitoring of providers designated as critical.

The classification of AI model providers as ICT third-party service providers is not a debatable proposition. A financial entity that accesses a large language model or a specialist credit AI via an API is consuming an ICT service from a third party. Under DORA Article 28(2), that provider must be entered in the register and subjected to the relevant third-party risk management requirements. This includes a documented assessment of the risks posed by the provider relationship, contractual clauses covering availability, security, incident notification, audit rights, and data protection, and a contingency plan for continuity if the provider becomes unavailable.

Concentration risk is a particular concern in the AI context. Several categories of financial AI are effectively dominated by a small number of foundation model providers. A financial entity that relies on a single major AI provider for critical decisioning processes across multiple business lines has a concentration exposure that must be assessed and disclosed under DORA. The concentration assessment is not merely a box-ticking exercise. It feeds directly into the business continuity planning requirement and the capital adequacy considerations of the management body.

Digital operational resilience testing under Articles 24 to 27 includes threat-led penetration testing (TLPT) for significant financial entities. AI-integrated systems are within the TLPT perimeter. The testing obligation requires financial entities to demonstrate that their systems, including AI components, can withstand adversarial conditions. For AI specifically, this means adversarial input testing alongside conventional infrastructure testing.

The Double-Obligation Layer: DORA and the EU AI Act

Financial entities using AI systems classified as high-risk under EU AI Act Annex III face obligations under both frameworks simultaneously. The EU AI Act entered full application on 2 August 2026 (subject to the proposed Digital Omnibus delay; see the note below) and imposes its own obligations on deployers of high-risk AI. Annex III includes AI systems used for credit scoring and creditworthiness assessment of individuals, which places a significant portion of AI used in retail financial services within the high-risk category.

EU AI Act Article 26 requires deployers of high-risk AI systems to conduct their own technical and organisational due diligence on the system, to ensure it is used in accordance with the provider's instructions for use, to monitor the system for unexpected performance in the context of its particular deployment, and to document that monitoring. Article 26 compliance is not satisfied by the provider's own conformity documentation. The deployer must produce its own assessment of the system as deployed in its specific context.

The overlap between Article 26 compliance documentation and DORA TPRM documentation is substantial. Both require a documented assessment of the AI system, both require records of monitoring and performance review, and both require evidence of governance accountability. A financial entity that builds the two compliance files independently is duplicating effort unnecessarily. The efficient approach is to develop the DORA TPRM file and the Article 26 compliance file as a coordinated package, with a single underlying technical assessment that serves both purposes. The documentation may need to be presented differently to a DORA supervisor and to an AI Act regulator, but the underlying technical substance can be shared.

See the companion article on EU AI Act operator obligations for 2026 at agentliability.eu for a detailed treatment of the Article 26 requirements and the deployer obligation stack.

EIOPA's AI Governance Opinion

In August 2025, the European Insurance and Occupational Pensions Authority published its opinion on AI governance, supervisory expectations, and the intersection of the EU AI Act with existing sectoral requirements. The opinion explicitly confirmed that DORA's ICT risk management obligations apply to AI systems used in insurance and pension operations, and that the management body's accountability under DORA Article 5 extends to AI-driven underwriting, claims handling, and customer-facing processes. EIOPA's opinion is non-binding, but it reflects the interpretive framework that national insurance supervisors will apply. For insurance undertakings and pension institutions within DORA's scope, the opinion provides the clearest available signal of supervisory expectations in the period before formal guidance is adopted.

Coverage Gaps: Where Existing Policies Fall Short

The insurance gap for financial entities operating AI under DORA is not simply that dedicated AI policies do not yet exist at scale. It is structural. Existing cyber policies and the ICT-related covers available to financial entities address operational resilience failures in a way that was designed around infrastructure events, not AI-specific failure modes.

A standard cyber policy for a financial entity will typically cover losses arising from a system outage, a data breach caused by an unauthorised intrusion, or a ransomware event. It will cover the costs of notification, regulatory investigation, and business interruption resulting from those events. What it will not cover, unless explicitly endorsed, is a loss arising from an AI model producing systematically incorrect outputs over a sustained period. Model hallucination, model drift, and output bias are not unauthorised intrusions. They are failures of the AI system itself, and the language of most cyber policies does not capture them as covered events.

The E&O bifurcation described in current market analyses, discussed in more detail in this site's treatment of AI exclusions in cyber and E&O policies, is directly relevant here. Professional indemnity policies for financial services firms address the negligent acts of professionals providing advice. An AI system that provides incorrect credit recommendations or erroneous risk assessments is not a professional in the legal sense. The PI policy may or may not respond, depending on whether the insured's own professional negligence is found in deploying or supervising the system. The gap between what the PI policy covers and what the AI failure actually caused is often the gap that produces uninsured loss.

The DORA incident reporting obligation makes this gap more consequential, not less. When a financial entity reports an AI incident to its supervisor, it is creating a record of a loss event. Whether that event triggers a covered claim under the cyber or PI policy depends on the wording of the specific instrument. In many cases, the regulatory notification will precede any third-party claim by months or years. The entity is carrying an unquantified liability that has been registered with its regulator but has not yet been adjudicated by a court or settled with a counterparty.

A dedicated AI agent liability policy, drafted to address the specific failure modes of AI systems in financial services, would treat the DORA incident as part of the claims development record rather than as a separate regulatory event. It would include cooperation clauses aligned to DORA notification timelines, coverage for costs incurred in responding to regulatory investigations arising from AI failures, and explicit definitions of covered AI failure modes that map onto the incident classification criteria in the DORA implementing regulation. That class of product is forming in 2026. Financial entities should be in conversation with their insurance advisers now about what their current covers actually include and exclude for AI-related losses, before a DORA-reportable event clarifies the question at cost.

For a practical overview of how the current AI insurance market is structured and which carriers are developing relevant capacity, see the coverage intelligence section of this platform.

Practical Steps for Financial Entities

The following steps reflect the intersection of DORA's existing obligations and the developing AI insurance market. They are operational, not theoretical.

Enter AI model providers in the DORA third-party register. Every AI model accessed via API by the financial entity should be treated as an ICT third-party service provider. The register entry should include the provider, the business function supported, the classification of the function as critical or important, and the contractual provisions in place. If an AI provider cannot satisfy the contractual requirements set out in DORA Article 30, that is a material third-party risk that requires escalation to the management body.

Address AI failure modes explicitly in the incident response plan. The DORA Article 11 response and recovery plan should include a specific section on AI-specific failure modes. Model hallucinations producing erroneous client-facing outputs, model drift causing degraded decisioning, and third-party AI provider outages are each plausible scenarios that require a documented response path, including the trigger for DORA incident classification and the responsibility for the regulatory notification.

Coordinate the Article 26 compliance file with the DORA TPRM documentation. For financial entities deploying high-risk AI under the EU AI Act, a single working group should own both the DORA third-party risk assessment and the Article 26 compliance documentation. The two filings share technical substance and should be developed in parallel to avoid contradictions and reduce duplication.

Audit the current insurance programme for AI-specific gaps. Risk managers should request a written analysis from their broker or in-house counsel on whether the current cyber and professional indemnity covers extend to AI-generated losses. Specifically: does the cyber policy cover losses arising from model hallucinations, model drift, or AI output bias? Does the PI policy cover third-party claims arising from AI-generated advice or decisions? Are there explicit AI exclusion clauses in either policy? The answers to those three questions define the uninsured exposure.

Review policy cooperation clauses against DORA notification timelines. AI liability policies typically require prompt notification to the insurer of any event that may give rise to a claim. DORA requires initial notification to the competent authority within four hours of major incident classification. The two obligations run simultaneously from the moment of classification. The internal incident response procedure should identify a named person responsible for insurer notification and a named person responsible for regulatory notification, and the procedure should require both notifications to be made from the same incident record.