DORA and AI Risk: How ECB Supervisory Expectations on AI Map to ICT Risk Management and Incident Reporting

ByOfficer

Last updated: June 2026

A bank can hold a clean capital ratio, sit on more liquidity than it needs, and still be unable to open for business on a Monday morning. That gap between solvency and the ability to actually operate is where DORA AI risk reporting now lives. When a model your fraud team relied on starts approving synthetic customers, or a frontier AI tool helps an attacker turn three small flaws into one serious breach, the question your supervisor asks is not whether you were well capitalised. It is whether you classified the event correctly, reported it inside the legal window, and could show that your ICT risk management framework saw the exposure coming.

On 3 June 2026, Frank Elderson, Member of the ECB’s Executive Board and Vice-Chair of the Supervisory Board, told the Goldman Sachs European Financials Conference that more than 85% of banks under European banking supervision use artificial intelligence. He framed AI not as a narrow cybersecurity item but as a firm-wide strategic challenge for safety and soundness. For reporting teams, that speech does not create new templates. It sharpens how existing obligations under the Digital Operational Resilience Act, and the separate legal track of the EU AI Act, get supervised in practice.

This article maps the supervisory message onto the obligations that already bind. Where the regulation requires something specific, it is cited. Where a point is supervisory expectation rather than black-letter law, that distinction is flagged, because confusing the two is the fastest way to over-build or under-report.

Related reading: DORA ICT Incident Reporting

What the ECB actually said, and what it did not

The speech was titled “Strengthening operational resilience for the age of AI.” Its central claim is that the economics of cyber risk have shifted. Frontier AI models can discover vulnerabilities at a speed and scale beyond what defenders have seen, chain minor weaknesses into serious attacks, and reverse-engineer patches back into exploits. Elderson’s blunt line for boards: act early, invest decisively now, and do not wait for the next incident to reveal where your vulnerabilities lie.

He grounded this in concrete events, not abstraction. The 2023 ransomware attack on the Industrial and Commercial Bank of China’s New York operations disrupted US Treasury settlement, with the bank reportedly resorting to manual workarounds including dispatching a courier with a USB stick. The 2024 CrowdStrike incident crashed systems across multiple sectors, financial services among them. He also cited AI-generated fake customers used to obtain loans fraudulently. The supervisory point is that operational disruption can spread through shared software dependencies and common infrastructure, with a vulnerability in a single, widely used provider escalating into disruption across an entire sector, so resilience cannot be assessed bank by bank in isolation.

One detail worth holding onto: the speech makes no reference to the EU AI Act. It is an operational resilience message rooted in DORA and the ECB’s own supervisory toolkit. That matters because a reporting officer who hears “ECB and AI” and immediately reaches for AI Act conformity assessments has mixed two regimes that run on different legal bases and different timelines. The mapping between them is the useful part, and it is the part most teams get wrong.

The supervisory follow-through is a letter, not a rule

Elderson announced that the ECB will send a so-called “dear CEO letter” to all banks, asking them to take proactive measures to ensure the continued robustness and security of their systems in the face of these transformative challenges. A dear CEO letter is a supervisory communication, not a delegated act. It does not amend DORA, change a reporting threshold, or create a new return. It signals where supervisory attention is going and what management bodies will be expected to evidence at the next dialogue. Treat it as a prioritisation signal for your existing DORA programme, not as a new compliance obligation with its own deadline.

DORA is the binding framework underneath the speech

The Digital Operational Resilience Act is Regulation (EU) 2022/2554 of 14 December 2022, published in OJ L 333 on 27 December 2022. It entered into force on 16 January 2023 and has applied since 17 January 2025, with no transitional period. The ESAs were explicit on that last point: financial entities were expected to close gaps between their internal setups and DORA requirements before the application date, not after it. When the ECB speech says DORA “entered into force last year,” it is referring loosely to the start of application in January 2025.

DORA is built around five blocks. Chapter II covers the ICT risk management framework. Chapter III covers ICT-related incident classification and reporting. Chapter IV covers digital operational resilience testing, including threat-led penetration testing. Chapter V covers ICT third-party risk and the oversight of critical providers. Chapter VI covers information-sharing arrangements. Artificial intelligence does not get its own chapter. Where an AI model supports a critical or important function and forms part of the financial entity’s ICT environment, it should be captured through the same ICT asset, information asset, dependency and control mapping used for other DORA-relevant technology. That is the structural insight the speech leans on: AI risk is supervised through the ICT lens you already have, not through a parallel AI annex.

For teams that handled the build-out, this is reassuring and also a trap. Reassuring, because no new DORA template appears because a function now uses a model. A trap, because the temptation is to assume an AI use case is automatically captured by the framework you wrote in 2024. If your ICT asset inventory, your dependency mapping, and your incident classification logic were written before generative models were embedded in customer onboarding or transaction monitoring, the model may be invisible to the very controls meant to catch it.

If you are still scoping which entities and functions fall in, our guide to DORA resilience testing for smaller firms sets out the proportionality routes, including how microenterprises sit under the lighter risk-based regime rather than the full testing programme.

How DORA AI risk reporting maps to the ICT risk management framework

The ICT risk management framework obligations sit in Chapter II of DORA and are detailed in Commission Delegated Regulation (EU) 2024/1774, the RTS specifying ICT risk management tools, methods, processes and policies and the simplified framework, published in the Official Journal on 25 June 2024. The framework requires identification of ICT-supported business functions, classification of information assets and their dependencies, protection and prevention measures, detection mechanisms, and response and recovery arrangements. Annual documentation and review of that framework is required.

Where an AI model supports a critical or important function, each of those steps acquires AI-specific texture. Identification means the model and its training data pipeline appear in the asset inventory. Dependency mapping means recording that the model relies on a third-party foundation model, a cloud inference service, or an external data feed. Detection means monitoring for model behaviour that drifts or is manipulated, not only for the classic availability and integrity signals. The regulation does not name “AI” in these articles, so this is interpretation: the obligation is to manage ICT risk, and a model is ICT.

The most common error here is treating AI governance and ICT risk management as two separate workstreams owned by two separate teams. The model risk function writes one policy, the DORA programme writes another, and the dependency between them is never recorded. When an AI-driven control fails, the incident lands in a seam. The fix is unglamorous: the model inventory and the DORA information asset register need to reference each other, so that a model failure is recognisable as an ICT-related incident the moment it happens.

What the framework does not require

DORA does not require a financial entity to stop using AI, nor does it impose a model-validation standard. It is technology neutral. The regulation does not prescribe a specific tool, vendor, or architecture for managing model risk. A team that reads the ECB speech as a mandate to rip out frontier models has over-read it. The supervisory expectation is that resources and tools are commensurate with the scale of AI use, and that the management body owns the risk. That is a governance and proportionality expectation, not a prohibition.

The DORA incident reporting clock when an AI-related event occurs

The operational stakes bite hardest at this stage. DORA Article 3(8) defines an ICT-related incident as an unplanned event, or series of linked events, that compromises the security of network and information systems and adversely affects the availability, authenticity, integrity or confidentiality of data or services. Article 3(10) defines a major ICT-related incident as one with a high adverse impact on the systems that support critical or important functions. Article 18 sets the classification criteria and materiality thresholds, detailed in Commission Delegated Regulation (EU) 2024/1772, adopted 13 March 2024 and published in the Official Journal on 25 June 2024. Article 19 sets the reporting process to the competent authority.

If an AI-related event meets the major threshold, for example a manipulated model that mis-approves a large volume of fraudulent transactions, the reporting clock is the same DORA clock that applies to any major incident. The content and time limits are set by Commission Delegated Regulation (EU) 2025/301, published in the Official Journal on 20 February 2025. The deadlines are tight:

  • Initial notification: as early as possible, and in any case within four hours from the moment the incident is classified as major, and no later than 24 hours from the moment the financial entity became aware of the incident.
  • Intermediate report: at the latest within 72 hours of submitting the initial notification, even where the status or handling of the incident has not changed.
  • Final report: no later than one month after the intermediate report, or after the latest updated intermediate report where applicable.

The weekend and bank-holiday accommodation in the RTS does not apply uniformly. For initial notifications and intermediate reports, the noon-next-working-day extension does not apply to credit institutions, central counterparties, operators of trading venues, or other financial entities identified as essential or important under Article 3 of Directive (EU) 2022/2555. Competent authorities may also disapply that accommodation for other financial entities that are significant or have a systemic character, after notifying the identified entities. A large institution should therefore not assume that a Friday-night classification moves the initial or intermediate deadline to Monday. There is also a separate obligation: where a financial entity cannot submit a notification or report within the applicable time limit, it must inform the competent authority without undue delay, and in any event no later than the respective deadline for that notification or report, explaining the reasons for the delay.

Two classification traps recur with AI events. The first is the awareness and classification clock. The initial notification is normally due no later than 24 hours from awareness and within four hours from classification as major. Where the incident is not classified as major within 24 hours from awareness but is classified as major later, the RTS requires the initial notification within four hours from that later classification. Internal triage therefore needs to evidence both timestamps: awareness and major classification. The second is the linked-events point. A model that degrades over days through a series of related manipulations may be one incident, a single series of linked events, rather than a fresh incident each morning. Splitting linked events can understate impact and put the reporting on the wrong clock. Our walkthrough of DORA ICT incident reporting sets out the field-level content of each report stage.

AI as a third-party dependency: the register and the oversight framework

Most banks do not build frontier models in-house. They consume them through cloud providers and vendors, which makes AI a third-party ICT risk before it is anything else. DORA Chapter V governs this. Article 28 requires financial entities to manage ICT third-party risk and to maintain a register of information on all contractual arrangements for the use of ICT services, distinguishing those that support critical or important functions. The standard templates for that register are set out in Commission Implementing Regulation (EU) 2024/2956, the ITS on the register of information. A contracted AI inference service that underpins a critical function belongs in that register.

Above the entity level sits the pan-European oversight framework. Under Article 31, the ESAs, through the Joint Committee and on the recommendation of the Oversight Forum, annually designate critical ICT third-party service providers and appoint a Lead Overseer for each. Article 32 establishes the Oversight Forum. The framework exists precisely because the financial sector depends on a small number of large providers, the concentration risk the ECB speech flags when it warns that cloud providers, telecommunications networks and payment systems could themselves become targets. A designated critical cloud provider that also supplies AI services is overseen at the EU level, but the entity-level obligation to map and register the dependency stays with you.

The error pattern here is scope drift in the register. Teams record the cloud hosting contract but not the AI service layered on top of it, because procurement treated the model as a feature of the platform rather than a distinct ICT service supporting a function. If the model materially supports a critical or important function, the register needs to reflect that, including the provider’s identity and, where relevant, its LEI. For the mechanics of building and maintaining that register, see our guide to the DORA register of information.

Where the EU AI Act runs on a separate track

The ECB speech does not mention the EU AI Act, and the two regimes should not be merged in your control framework. The AI Act is Regulation (EU) 2024/1689 of 13 June 2024, published in OJ L 2024/1689 on 12 July 2024. It is product-safety and fundamental-rights legislation. DORA is financial-sector operational resilience legislation. They can apply to the same model at the same time, for different reasons, with different obligations and different deadlines.

Classification under the AI Act runs through Article 6. Article 6(1) captures AI systems used as safety components of products already covered by listed EU harmonisation legislation. Article 6(2), read with Annex III, captures standalone high-risk systems in defined areas. For banks, the relevant Annex III entries are point 5(b), creditworthiness assessment or credit scoring of natural persons, and point 5(c), risk assessment and pricing in life and health insurance. A credit-scoring model used to decide consumer lending sits squarely in high-risk classification. Article 6(3) allows a provider to conclude that an Annex III system is not high-risk in narrow circumstances, including where it performs only narrow procedural tasks, improves the result of a previously completed human activity, or carries out preparatory assessments without replacing human review. Article 6(4) requires that conclusion to be documented before the system is placed on the market or put into service, and the provider must register the system under Article 49(2). For an AI system referred to in Annex III, the Article 6(3) derogation is not available where the system performs profiling of natural persons; that Annex III system remains high-risk.

The application dates are staggered. Prohibited practices applied from 2 February 2025. General-purpose AI model obligations applied from 2 August 2025. The bulk of the high-risk obligations apply from 2 August 2026, with the conformity-assessment-route systems under Article 6(1) following on 2 August 2027. Serious-incident reporting under Article 73 is a separate channel from DORA reporting: providers of high-risk AI systems report serious incidents to the relevant market surveillance authority without undue delay and, in any event, not later than 15 calendar days after becoming aware, with shorter windows in specified cases. For Annex III high-risk systems placed on the market or put into service by providers subject to equivalent Union reporting obligations, Article 73(9) limits the AI Act serious-incident notification to incidents involving infringement of obligations under Union law intended to protect fundamental rights.

Here is the misclassification that costs teams the most time. Not every AI system a bank runs is high-risk under the AI Act. AML transaction monitoring and financial-crime detection tools are not listed among the Annex III high-risk use cases by default, and most fall outside that classification, though each system must still be assessed against its actual function. The high-risk shoe fits credit scoring and insurance pricing, not the AML engine simply because it uses machine learning. Reading the whole AI stack as high-risk triggers conformity assessments, fundamental-rights impact assessments under Article 27, and registration duties that the law may not actually require for that system. Our explainer on EU AI Act compliance for financial institutions works through the classification logic in detail.

What lands on the reporting desk in practice

Strip away the conference framing and three concrete questions reach the reporting function. First, is a given AI use case captured by your DORA ICT asset inventory and register of information, and if it supports a critical or important function, is it flagged as such? Second, if that use case fails or is manipulated and meets the Article 18 major threshold, does your incident classification logic recognise it as a DORA incident and start the Article 19 clock against the Delegated Regulation (EU) 2025/301 deadlines? Third, for systems that are also high-risk under AI Act Annex III, is the Article 73 serious-incident channel assessed separately from DORA, including whether Article 73(9) narrows the AI Act notification to Article 3(49)(c) fundamental-rights infringement cases?

The ECB’s own track record gives a sense of how seriously this is supervised. Its 2024 cyber resilience stress test covered 109 banks, with 28 undergoing a thorough assessment of their incident response and recovery, and almost three-quarters of the findings have since been addressed. That is not a one-off exercise. The dear CEO letter and the supervisory framing of AI as a safety-and-soundness issue point to continued scrutiny of exactly these capabilities. The 86% of chief risk officers who told the Institute of International Finance in February 2026 that cybersecurity and technology risk is a top priority for the year are responding to the same signal.

One first-person observation from sitting with these obligations: the hardest line to draw is not the DORA deadline, which is mechanical once the clock starts. It is the boundary between an AI model that is a curiosity in a sandbox and an AI model that has quietly become load-bearing for a critical function. The register and the inventory only protect you if they are updated when that boundary is crossed, and that crossing rarely comes with an announcement.

Frequently Asked Questions

Does an AI-related failure get reported under DORA or under the EU AI Act?

It can be both, through separate channels. If the event meets the DORA major-incident threshold in Article 18, it is reported to the competent authority under Article 19 against the Delegated Regulation (EU) 2025/301 deadlines. If the system is also a high-risk AI system under the AI Act, Article 73 may require a separate serious-incident report to the market surveillance authority. For Annex III high-risk systems placed on the market or put into service by providers subject to equivalent Union reporting obligations, Article 73(9) limits that AI Act serious-incident notification to Article 3(49)(c) fundamental-rights infringement cases.

What are the DORA reporting deadlines for a major ICT-related incident?

Under Commission Delegated Regulation (EU) 2025/301, the initial notification is due within four hours of classifying the incident as major and no later than 24 hours from awareness; the intermediate report within 72 hours of the initial notification; and the final report no later than one month after the intermediate report. For initial notifications and intermediate reports, the weekend and bank-holiday noon-next-working-day extension does not apply to credit institutions, central counterparties, operators of trading venues, or entities identified as essential or important under Article 3 of Directive (EU) 2022/2555.

Does the ECB speech create a new reporting obligation?

No. The 3 June 2026 speech and the announced dear CEO letter are supervisory communications. They signal supervisory priorities and expectations but do not amend DORA, change a threshold, or introduce a new return. The binding obligations remain those in DORA and its delegated regulations.

Is every AI system a bank uses high-risk under the EU AI Act?

No. High-risk classification under Annex III applies to specific use cases, including creditworthiness and credit scoring of natural persons under point 5(b) and life and health insurance risk assessment and pricing under point 5(c). AML transaction monitoring and financial-crime detection tools are not listed as Annex III high-risk by default, although each system must be assessed against its actual function. For a system referred to in Annex III, the Article 6(3) derogation is not available where the system performs profiling of natural persons.

Where should an AI service from a cloud provider be recorded?

In the DORA register of information required under Article 28, using the standard templates in Commission Implementing Regulation (EU) 2024/2956, alongside other ICT third-party arrangements, with a flag where it supports a critical or important function. If the provider is designated a critical ICT third-party service provider under Article 31, it is also subject to the ESAs’ pan-European oversight framework, but the entity-level registration duty still applies to you.

Does DORA require a specific approach to validating AI models?

DORA does not prescribe a model-validation standard or a particular tool. It is technology neutral. It requires that the ICT risk management framework under Chapter II and Commission Delegated Regulation (EU) 2024/1774 identifies, protects, detects, responds to and recovers from ICT risk, and an AI model supporting a function is ICT for those purposes. Model-validation rigour is a supervisory and governance expectation rather than a fixed DORA template.

When do the EU AI Act obligations actually apply?

Prohibited practices applied from 2 February 2025, general-purpose AI obligations from 2 August 2025, most high-risk obligations from 2 August 2026, and the Article 6(1) conformity-assessment-route high-risk systems from 2 August 2027. DORA has applied since 17 January 2025 independently of these dates.

Related Articles

Key Takeaways

  • The ECB’s 3 June 2026 speech and its announced dear CEO letter are supervisory signals, not new rules; the binding obligations are DORA and its delegated regulations.
  • DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025 with no transitional period, and treats an AI model supporting a critical or important function as an ICT asset, not a separate category.
  • If an AI-related event meets the Article 18 major threshold, the DORA reporting clock under Commission Delegated Regulation (EU) 2025/301 applies: four hours from classification, 24 hours from awareness, 72 hours for the intermediate report, one month for the final report.
  • For initial notifications and intermediate reports, the weekend and bank-holiday extension does not apply to credit institutions, central counterparties, trading venue operators, or entities identified as essential or important under Article 3 of Directive (EU) 2022/2555.
  • Contracted AI services that support critical or important functions belong in the DORA register of information under Article 28, using the standard templates in Commission Implementing Regulation (EU) 2024/2956; designated critical providers are also overseen at EU level under Article 31.
  • The EU AI Act, Regulation (EU) 2024/1689, runs on a separate legal track; credit scoring (Annex III 5(b)) and life and health insurance pricing (5(c)) are high-risk, while AML monitoring generally is not high-risk by default.
  • AI Act serious-incident reporting under Article 73 is a distinct channel from DORA incident reporting, with a 15-calendar-day default deadline, but Article 73(9) narrows the reportable AI Act serious incidents for Annex III systems where the provider is subject to equivalent Union reporting obligations.

Sources and References

Getting AI risk onto the right reporting clock

The supervisory message and the legal obligations point in the same direction, but they are not the same thing. The ECB is telling boards to treat AI as a strategic resilience risk and to invest before the next incident. DORA is telling reporting teams exactly when the clock starts and how fast the reports are due. The AI Act is telling product and compliance teams which systems carry high-risk duties and a separate incident channel. The work for a reporting officer is to make sure an AI model that has become load-bearing is visible in the inventory and the register before it fails, so that when it does fail, the four-hour clock starts on time rather than after a scramble to work out which regime even applies.

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.

Similar Posts