Reference · European Union
DORA and AI Workloads: What Regulation (EU) 2022/2554 Requires
Digital Operational Resilience Act, applied since 17 January 2025
Regulation (EU) 2022/2554, the Digital Operational Resilience Act, sets ICT risk management, incident reporting, resilience testing and third-party risk requirements for the EU financial sector. It was adopted on 14 December 2022 and has applied since 17 January 2025.DORA · Art. 64
DORA does not mention artificial intelligence. It reaches an AI workload through its definitions: the application that calls a model is an ICT asset, the model behind an API is an ICT service, and its provider is an ICT third-party service provider. From there, the inventory, change management, detection, incident and register obligations apply to AI as they apply to any other ICT.
Twenty types of financial entity are in scope
Article 2(1) lists the entities DORA applies to, from credit institutions, payment and electronic money institutions and investment firms to crypto-asset service providers, insurance and reinsurance undertakings, insurance intermediaries, credit rating agencies and crowdfunding service providers. Points (a) to (t), twenty entity types, are the financial entities; point (u) adds ICT third-party service providers.DORA · Art. 2(1), (2)
Article 2(3) excludes several categories, among them institutions for occupational retirement provision whose pension schemes together have no more than 15 members, and insurance intermediaries that are microenterprises or small or medium-sized enterprises.DORA · Art. 2(3)
DORA's definitions bring AI into scope
An ICT asset is a software or hardware asset in the network and information systems used by the financial entity. ICT services are digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis. An ICT third-party service provider is an undertaking providing ICT services.DORA · Art. 3(7), (19), (21)
Read together, a model endpoint the entity's applications call is an ICT service, each calling application is an ICT asset, and the model provider is an ICT third-party service provider. An incident involving an AI system meets the general definition of an ICT-related incident when it compromises the security of network and information systems and has an adverse impact on the availability, authenticity, integrity or confidentiality of data, or on the entity's services.DORA · Art. 3(8)
The ICT risk framework covers every AI system the entity runs
The management body defines, approves and oversees the ICT risk management arrangements and bears ultimate responsibility for ICT risk.DORA · Art. 5(2) The framework itself must be sound, comprehensive and well documented, and part of the entity's overall risk management system.DORA · Art. 6(1) Within it:
- Identification: identify, classify and document the ICT-supported business functions and the assets that support them, map the configuration and interdependencies of those assets, identify and document every process that depends on an ICT third-party service provider, and keep the inventories current, updating them at every major change.DORA · Art. 8(1), (4) to (6)
- Protection: monitor and control the security and functioning of ICT systems continuously, and maintain high standards of availability, authenticity, integrity and confidentiality of data at rest, in use and in transit.DORA · Art. 9(1), (2)
- Change management: record, test, assess, approve, implement and verify every change to ICT systems in a controlled manner.DORA · Art. 9(4)(e)
- Detection: detect anomalous activity promptly, with alert thresholds and criteria that trigger the incident response process.DORA · Art. 10(1), (2)
- Testing: entities other than microenterprises keep a digital operational resilience testing programme.DORA · Art. 24(1)
A major incident starts a four-hour reporting clock
Every ICT-related incident and significant cyber threat is recorded, and root causes are identified, documented and addressed.DORA · Art. 17(2) Incidents are classified against six criteria: the clients, counterparts and transactions affected, the duration and service downtime, the geographical spread, the data losses, the criticality of the services affected, and the economic impact.DORA · Art. 18(1)
A major incident goes to the competent authority in three stages: an initial notification, an intermediate report, and a final report once the root cause analysis is complete.DORA · Art. 19(4) Delegated Regulation (EU) 2025/301 sets the time limits: the initial notification within four hours of classifying the incident as major and no later than 24 hours after becoming aware of it, the intermediate report within 72 hours of the initial notification, and the final report no later than one month after the latest intermediate report.RTS 2025/301 · Art. 5(1) Where a major incident affects clients' financial interests, the entity also informs those clients without undue delay.DORA · Art. 19(3)
Flow
From an AI incident to the final report
- Art. 17(2)Record the incidentEvery ICT-related incident, AI included
- Art. 18(1)Classify itClients, duration, data, services affected
- 4 hoursInitial notificationFrom classification as major; at most 24 hours from awareness
- 72 hoursIntermediate reportFrom the initial notification
- 1 monthFinal reportFrom the latest intermediate report, after root cause analysis
Every model provider contract belongs in the register of information
An entity that uses ICT services stays fully responsible for its obligations under DORA and financial services law.DORA · Art. 28(1)(a) It keeps a register of information on all contractual arrangements for ICT services, marking those that support critical or important functions, reports at least yearly to its competent authority on new arrangements, and makes the full register available on request.DORA · Art. 28(3) Before signing, it assesses whether the arrangement supports a critical or important function and identifies the risks, concentration risk included.DORA · Art. 28(4)
The contract allocates rights and obligations in writing. At a minimum it describes the services and the conditions for subcontracting, names the regions or countries where services are provided and data is processed, covers data protection and the return of data on exit, commits the provider to assist in an ICT incident and to cooperate fully with the competent authorities, and sets termination rights.DORA · Art. 30(1), (2) Where the service supports a critical or important function, the contract adds full service levels with performance targets, access, inspection and audit rights, and an exit strategy with a transition period.DORA · Art. 30(3)
Control mapping
What a reviewer expects to be able to see.
| Obligation | What the system must do | Evidence a reviewer expects |
|---|---|---|
| Identification (Art. 8) | Carry every AI system and its provider dependency in the ICT asset and dependency inventories, updated on major change | Inventory entries for models, calling systems, and providers, with change history |
| Change management (Art. 9(4)(e)) | Record, test, approve and verify changes to AI systems, including a new model version or provider | Change records with approver, test result, and the configuration before and after |
| Detection (Art. 10) | Detect anomalous activity in AI systems promptly, against defined thresholds that trigger incident response | Detection rules, thresholds, and the alerts they produced |
| Incident management (Art. 17, 19) | Record every ICT-related incident involving an AI system and report major ones in the three-stage format | Incident register entries and, where major, the initial, intermediate, and final reports with timestamps |
| Register of information (Art. 28(3)) | Record each model-provider arrangement and whether it supports a critical or important function | Register rows for AI providers and the annual submission to the competent authority |
| Contractual provisions (Art. 30) | Hold contracts with AI providers that allocate rights and obligations in writing and cover the Article 30(2) points | Contracts, and a gap analysis against Article 30(2) for standard API terms |
Key dates
Timeline, drawn to scale
DORA: adoption, application and the incident reporting standard
- 14 December 2022Regulation (EU) 2022/2554 adopted.
- 27 December 2022Published in the Official Journal.
- 16 January 2023Enters into force, on the twentieth day after publication.
- 23 October 2024Commission adopts Delegated Regulation (EU) 2025/301 on the content and time limits of major incident reports.
- 17 January 2025DORA applies to financial entities (Article 64).
- 12 March 2025Delegated Regulation (EU) 2025/301 enters into force, setting the four-hour, 72-hour and one-month reporting limits.
- AnnuallyReport to the competent authority on new ICT third-party arrangements, with the full register of information available on request (Article 28(3)).
Sources cited
Common gaps
Where the AI workload most often falls outside the DORA programme.
- Model providers absent from the register. The register of information covers all contractual arrangements for ICT services.DORA · Art. 28(3) A model provider onboarded by an engineering team on standard terms is one of them.
- An inventory built from procurement records. Article 8(6) asks for inventories updated at every major change. Switching a model version or adding a provider is a change the inventory has to catch.
- Model changes outside change management. A new model version changes how an ICT system behaves. If it ships through a configuration setting nobody records, Article 9(4)(e) has no record to show.
- API terms treated as a DORA contract. Article 30(2) expects data processing locations, incident assistance and authority cooperation in writing. Standard API terms usually address none of them.
- An incident process that has never seen an AI event. Article 17(2) requires every ICT-related incident to be recorded. If leaked credentials in a prompt or an unapproved configuration change have never entered the incident register, the process has a blind spot, and a major one cannot meet a four-hour clock.
- AI governance left to engineering. Article 5(2) puts ICT risk arrangements with the management body. AI systems governed only by the team that built them sit outside the accountability DORA requires.
Related
Last reviewed October 11, 2026. This reference summarises publicly available regulatory guidance and is provided for general information. It is not legal advice. Obligations depend on an institution's charter, registration status, size, and activities. Verify against the primary sources cited above and consult counsel before relying on any summary here.