DORA, Regulation (EU) 2022/2554, is the EU's binding rulebook for ICT risk at banks and other financial entities, applying since 17 January 2025. Its five pillars are ICT risk management under a framework the management body owns (Articles 5–16), classification and reporting of major ICT incidents (Articles 17–23), resilience testing including threat-led penetration testing every three years (Articles 24–27), ICT third-party risk with a register of information, mandatory contract terms, concentration assessments and exit plans plus EU oversight of critical providers (Articles 28–44), and voluntary information sharing (Article 45). It never names AI, but an AI system is an ICT asset and a hosted model, LLM API or AI platform is an ICT service under Article 3, so every AI vendor sits inside the third-party regime: the bank stays fully responsible, records the contract and its subcontracting chain in the register, includes the Article 30 terms, assesses concentration and holds a tested exit plan for services supporting critical or important functions.
TRACKED DOCUMENTS: DORA (Regulation (EU) 2022/2554) · ESA Statement on ICT risks from frontier AI models (JC 2026 25)
Instrument
Regulation (EU) 2022/2554, 14 December 2022; directly applicable, no transposition
Applies since
17 January 2025 (Article 64)
Who
20 categories of financial entity (Article 2(1)) incl. credit institutions, plus ICT third-party providers
Supervised by
The bank's competent authority (ECB for significant banks); ESAs oversee critical providers
AI
Not named; AI systems are ICT assets and AI vendors are ICT third-party providers (Article 3)
What is DORA and who does it apply to?
DORA, the Digital Operational Resilience Act, is Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector. It was published in the Official Journal on 27 December 2022, entered into force on the twentieth day after publication and, under Article 64, has applied since 17 January 2025. As a regulation it is directly applicable in every Member State without national transposition. Before it, ICT and outsourcing risk at EU banks was governed by guidelines (the EBA's outsourcing and ICT risk guidelines) and national rules; DORA replaced that patchwork with one binding rulebook and, for the first time, gave EU authorities direct oversight of the technology providers the sector depends on.
Article 2(1) lists the entities in scope: credit institutions are point (a), followed by payment and e-money institutions, investment firms, crypto-asset service providers, central securities depositories, trading venues, insurers and reinsurers, pension funds, credit rating agencies, crowdfunding providers and others, with point (u) bringing ICT third-party service providers into scope. Article 4 applies proportionality: the rules are implemented “taking into account their size and overall risk profile, and the nature, scale and complexity of their services, activities and operations”, and Article 16 gives the smallest entities a simplified ICT risk framework. Every EU bank is covered, whether it builds its AI in-house or buys it. The article-by-article status, penalties and change log are on our DORA document page; this guide explains the structure and what it asks for.
What are the five pillars of DORA?
The Regulation's operative chapters map onto five pillars: ICT risk management (Chapter II, Articles 5–16), ICT-related incident management, classification and reporting (Chapter III, Articles 17–23), digital operational resilience testing (Chapter IV, Articles 24–27), managing ICT third-party risk including the oversight framework for critical providers (Chapter V, Articles 28–44), and information-sharing arrangements (Chapter VI, Article 45). Chapter VII (Articles 46–56) gives competent authorities their powers and penalties, and Chapter IX (Articles 58–64) holds the review clause, transitional provisions and the application date.
| Pillar | Articles | Core obligations | Where AI falls |
|---|---|---|---|
| 1. ICT risk management | Arts 5–16 | Management body owns ICT risk (Art 5); Framework reviewed yearly (Art 6); Identify, protect, detect, respond, recover, learn (Arts 8–14); Simplified framework for small entities (Art 16) | AI systems and their data are ICT assets inside the framework |
| 2. ICT incident reporting | Arts 17–23 | Incident management process (Art 17); Classification and materiality (Art 18); Initial, intermediate, final reports (Art 19); Harmonised templates (Art 20) | A model outage or poisoned-data event can be a major ICT incident |
| 3. Resilience testing | Arts 24–27 | Testing programme for all entities (Art 24); Tools, systems and scenario tests (Art 25); Threat-led penetration testing every 3 years (Art 26); Tester requirements (Art 27) | AI services supporting critical functions are in TLPT scope |
| 4. ICT third-party risk | Arts 28–44 | Fully responsible when outsourcing (Art 28(1)); Register of information (Art 28(3)); Concentration risk and exit plans (Arts 29, 28(8)); Mandatory contract terms (Art 30); Oversight of critical providers (Arts 31–44) | LLM and model vendors are ICT third-party providers |
| 5. Information sharing | Art 45 | Voluntary exchange of cyber-threat intelligence; Within trusted communities; Notify the competent authority of participation | Frontier-AI threat intelligence (ESAs, July 2026) |
What are the key DORA dates?
Two dates after application matter for third-party risk. The first annual collection of registers of information ran in spring 2025: under the ESAs' decision of 15 November 2024, competent authorities had to forward the registers they received from financial entities to the ESAs by 30 April 2025, with each national authority setting its own earlier deadline for banks. The ESAs used those registers to apply the Article 31 criticality criteria and on 18 November 2025 published the first list of 19 critical ICT third-party providers (CTPPs), among them Amazon Web Services EMEA, Google Cloud EMEA, Microsoft Ireland Operations, IBM, Oracle Nederland and SAP; no stand-alone AI model developer was designated, but the hyperscalers through which most banks consume AI were. Each CTPP has a Lead Overseer among the EBA, EIOPA and ESMA, and oversight activity, including the joint examination teams set up under the 2025 RTS, is under way in 2026. The list is updated yearly under Article 31(9).
What does DORA require, article by article?
The table lists the obligations that examiners test first, with the article that creates each and the AI angle. The wording is paraphrased from the Regulation; quotations are the Regulation's own.
| Article | Obligation | Who | AI angle |
|---|---|---|---|
| Art 5(1)–(2) | The management body “shall define, approve, oversee and be responsible for the implementation” of the ICT risk management framework and “bear the ultimate responsibility for managing the financial entity's ICT risk”; it approves the ICT third-party policy and keeps its own ICT knowledge up to date (Art 5(4)). | All entities | Board accountability for AI as an ICT risk, not only as a model risk. |
| Art 6 | A “sound, comprehensive and well-documented ICT risk management framework”, reviewed at least once a year and after major incidents (Art 6(5)), with ICT risk assigned to a control function with appropriate independence (Art 6(4)) and a digital operational resilience strategy (Art 6(8)) including a multi-vendor strategy where appropriate (Art 6(9)). | All but Art 16 entities | Multi-vendor strategy applies to model and cloud concentration. |
| Arts 8–14 | Identify all ICT-supported business functions, assets and dependencies (Art 8); protect and prevent (Art 9); detect anomalous activity (Art 10); respond and recover with business continuity and ICT response and recovery plans (Art 11); back up and restore (Art 12); learn and evolve, including post-incident reviews and training (Art 13); communicate (Art 14). | All entities (Art 16 for the smallest) | AI models, training data, prompts and vendor APIs are assets to identify under Art 8; model-failure scenarios belong in Art 11 plans. |
| Arts 17–18 | An ICT-related incident management process to detect, manage and notify incidents (Art 17); classification by clients and counterparts affected, duration, geographical spread, data losses, criticality of services and economic impact (Art 18), with thresholds in RTS 2024/1772. | All entities | An AI-service outage or data-integrity failure is classified like any other ICT incident. |
| Art 19 | Report major ICT-related incidents to the competent authority with an initial notification, an intermediate report and a final report (Art 19(4)), time limits set by RTS 2025/301; voluntary notification of significant cyber threats (Art 19(2)); inform affected clients without undue delay (Art 19(3)). | All entities | Reporting clock runs regardless of whether the failed component is an AI model. |
| Arts 24–25 | A digital operational resilience testing programme, proportionate and risk-based, run by independent parties, covering all ICT systems supporting critical or important functions with tests at least yearly (Art 24(6)); tools and methods including vulnerability assessments, scenario-based tests and penetration testing (Art 25). | All but Art 16 entities | AI services in the critical perimeter must be tested, including adversarial scenarios. |
| Art 26 | Entities identified by their authority carry out advanced threat-led penetration testing at least every three years, on live production systems supporting critical or important functions, including those provided by ICT third-party providers (Art 26(1)–(3)); criteria in RTS 2025/1190. | Identified entities | Vendor-hosted AI inside a critical function is inside the TLPT scope, so the vendor must cooperate. |
| Art 28(1)–(2) | ICT third-party risk is managed as an integral part of ICT risk; entities “shall, at all times, remain fully responsible” for compliance when using ICT services (Art 28(1)(a)); a strategy on ICT third-party risk, including a policy on services supporting critical or important functions, reviewed regularly (Art 28(2)), content in RTS 2024/1773. | All but Art 16 and microenterprises | An LLM provider or model vendor is an ICT third-party service provider. |
| Art 28(3) | Maintain and update a register of information on all contractual arrangements for ICT services at entity, sub-consolidated and consolidated level, distinguishing services supporting critical or important functions; report it at least yearly to the competent authority; inform the authority of planned arrangements for critical functions (template in ITS 2024/2956). | All entities | Every AI contract, with its subcontractor chain, goes in the register. |
| Art 28(4)–(7) | Before contracting: assess whether the service supports a critical or important function, assess conditions and risks including concentration risk, perform due diligence, identify conflicts of interest; contract only with providers that meet appropriate information security standards; weigh subcontracting risk; termination rights for breaches, changed circumstances, weaknesses in ICT risk management or supervisory inability (Art 28(7)). | All but Art 16 and microenterprises | Due diligence on a model provider includes its own resilience and the cloud it runs on. |
| Art 28(8) | Exit strategies for ICT services supporting critical or important functions, with transition plans tested and reviewed, so the entity can exit without disruption, limitation of compliance or detriment to continuity. | All but Art 16 and microenterprises | How the bank would move or replace a model, its prompts, fine-tuning data and outputs. |
| Art 29 | Preliminary assessment of ICT concentration risk: contracting with a provider that is not easily substitutable, or multiple arrangements with the same or closely connected providers; benefits and costs of alternatives; subcontracting chains, including in third countries. | All but Art 16 and microenterprises | Several AI tools on one hyperscaler are one dependency. |
| Art 30 | Mandatory contract terms: full description of services and whether subcontracting is permitted, locations of data processing and storage, data availability, integrity and confidentiality, access, recovery and return of data on insolvency or termination, service levels, incident assistance, cooperation with authorities, termination rights and notice periods (Art 30(2)); for critical or important functions also full service level descriptions, notice and reporting duties, business contingency plans, participation in TLPT, unrestricted access, inspection and audit rights, exit strategies (Art 30(3)). | All entities | AI vendor contracts need data-location, data-return and audit clauses that standard LLM terms often lack. |
| Arts 31–35 | The ESAs designate critical ICT third-party providers on the Art 31(2) criteria (systemic impact, number of G-SIIs or O-SIIs relying on them, reliance for critical or important functions, substitutability); appoint a Lead Overseer with powers to request information, investigate, inspect and issue recommendations (Art 35(1)); periodic penalty payments of up to 1 % of average daily worldwide turnover for up to six months for non-compliance (Art 35(6)–(8)). | Critical providers; ESAs | First list (18 Nov 2025) includes the cloud platforms carrying most bank AI; banks keep their own Art 28–30 duties regardless. |
| Art 45 | Financial entities may exchange cyber-threat information and intelligence within trusted communities, under arrangements that protect the sensitive nature of the information; participation is notified to the competent authority. | Voluntary | Frontier-AI-enabled threats are the ESAs' current focus for this pillar. |
| Art 50 | Member States lay down “effective, proportionate and dissuasive” administrative penalties and remedial measures for financial entities; competent authorities get powers to order cessation, require measures and issue public notices. | Member States; competent authorities | Fine levels for banks are national; the register and contracts are testable directly. |
How do AI vendors and LLM providers fall under DORA's ICT third-party rules?
DORA never uses the words “artificial intelligence”. It does not need to. Article 3(21) defines ICT services as “digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis”, and Article 3(19) defines an ICT third-party service provider as “an undertaking providing ICT services”. A hosted large language model consumed through an API, a vendor fraud model scored in the vendor's cloud, a document-processing platform, a conversational assistant run by a software firm, and the cloud infrastructure beneath an in-house model are all ICT services under that definition, and the firms providing them are ICT third-party service providers. The consequence is mechanical: each arrangement goes in the Article 28(3) register of information, each is assessed under Article 28(4) for whether it supports a critical or important function, each contract must carry the Article 30 terms, and each critical one needs an Article 28(8) exit plan and an Article 29 concentration assessment.
Three features of AI procurement collide with those rules. First, subcontracting chains: an AI application vendor typically runs on a foundation-model provider which runs on a hyperscaler, and RTS 2025/532 requires the bank to determine and assess that chain for services supporting critical or important functions, including the location of each link. Second, data: Article 30(2)(b)–(d) requires the contract to state where data is processed and stored and to guarantee access, recovery and return of personal and non-personal data on termination or insolvency, terms that off-the-shelf LLM agreements rarely provide and that matter for prompts, fine-tuning sets and outputs. Third, concentration: the ESAs' first CTPP list is dominated by cloud platforms, and a bank whose fraud model, assistant and analytics all run on one of them has, for Article 29 purposes, a single dependency. The ECB's Guide on outsourcing cloud services (16 July 2025) explains how the ECB expects the banks it supervises to apply these provisions to cloud, and the EBA's remote-onboarding guidelines apply the same ICT-risk discipline to identity-verification vendors.
The supervisors have begun to say so explicitly. The ESAs' joint statement of 31 July 2026 on ICT risks from frontier AI models, JC 2026 25, tells financial entities to adjust their DORA ICT risk-management processes around prevention, detection and management of AI-accelerated cyber threats, proportionately under Article 4, and reports on ongoing and planned DORA oversight activities for critical providers to address the risk; it also says management bodies must own the response. ECB Supervisory Board Vice-Chair Frank Elderson's 3 June 2026 speech called frontier AI “a structural shift in the economics of cyber risk” and noted that 85 % of significant banks use AI. The Basel Committee's December 2025 third-party risk principles and its June 2026 ICT risk range-of-practices report set the same expectations globally. DORA sits beside the EU AI Act, not inside it: the AI Act classifies what the system does and, for high-risk uses such as credit scoring of natural persons, imposes its own obligations from 2 December 2027; DORA governs whether the bank can keep operating, detect failures and exit when the system or its provider fails, and it has applied since January 2025.
Which RTS and ITS complete DORA?
DORA delegates its technical detail to regulatory technical standards (RTS), implementing technical standards (ITS) and delegated acts drafted by the ESAs and adopted by the European Commission. The table lists the acts on the Commission's register for Regulation (EU) 2022/2554, with the article that empowers each and the date of the Commission's adopting act; publication in the Official Journal followed in each case.
| Act | Legal basis | Subject | Adopted | Why it matters for AI |
|---|---|---|---|---|
| Delegated Regulation (EU) 2024/1774 (RTS) | Arts 15(4), 16(3) | ICT risk management tools, methods, processes and policies, and the simplified framework | 13 Mar 2024 | Sets what the ICT risk framework must contain; AI platforms are assets within it |
| Delegated Regulation (EU) 2024/1772 (RTS) | Art 18(3) | Criteria for classifying ICT-related incidents and cyber threats, materiality thresholds for major incidents | 13 Mar 2024 | Decides when an AI-service failure is a reportable major incident |
| Delegated Regulation (EU) 2024/1773 (RTS) | Art 28(10) | Content of the policy on contractual arrangements for ICT services supporting critical or important functions | 13 Mar 2024 | The policy under which AI vendors supporting critical functions are contracted |
| Delegated Regulation (EU) 2024/1502 | Art 31(6) | Criteria for designating ICT third-party providers as critical | 22 Feb 2024 | Why hyperscalers hosting AI were on the first CTPP list |
| Delegated Regulation (EU) 2024/1505 | Art 43(2) | Oversight fees charged by the Lead Overseer to critical providers | 22 Feb 2024 | — |
| Implementing Regulation (EU) 2024/2956 (ITS) | Art 28(9) | Standard templates for the register of information | 29 Nov 2024 | The template every AI contract must be recorded in, with subcontractor chains |
| Delegated Regulation (EU) 2025/301 (RTS) | Art 20(3) | Content and time limits of the initial notification, intermediate and final reports on major incidents; voluntary cyber-threat notification | 23 Oct 2024 | Clock for reporting an AI-related major incident |
| Implementing Regulation (EU) 2025/302 (ITS) | Art 20(4) | Standard forms, templates and procedures for incident reports and threat notifications | 23 Oct 2024 | — |
| Delegated Regulation (EU) 2025/295 (RTS) | Art 41(2) | Harmonised conditions for the conduct of oversight activities | 24 Oct 2024 | How Lead Overseers examine critical AI/cloud providers |
| Delegated Regulation (EU) 2025/420 (RTS) | Art 41(2) | Composition, designation and tasks of joint examination teams | 16 Dec 2024 | — |
| Delegated Regulation (EU) 2025/1190 (RTS) | Art 26(11) | Threat-led penetration testing: which entities, internal testers, scope, methodology, cooperation and mutual recognition | 13 Feb 2025 | AI services in the live production perimeter are in scope of TLPT |
| Delegated Regulation (EU) 2025/532 (RTS) | Art 30(5) | Elements to determine and assess when subcontracting ICT services supporting critical or important functions | 24 Mar 2025 | Governs the chain vendor → model provider → cloud behind an AI service |
What should a bank do about DORA and its AI estate?
- Inventory every AI model, API, platform and embedded vendor AI feature, including shadow tools, and decide for each whether it supports a critical or important function (Article 3(22)); that decision drives the register, contract, exit and testing obligations.
- Record each AI arrangement in the Article 28(3) register with its full subcontracting chain, using the ITS 2024/2956 templates, and check the Article 30 clauses, in particular data location, return of data on exit, incident assistance, TLPT participation and audit rights.
- Run the Article 29 concentration assessment across the whole portfolio, counting AI tools that share a hyperscaler as one dependency, and document the alternatives considered.
- Write and test an Article 28(8) exit plan for any AI service in a critical function: how the model, prompts, fine-tuning data and outputs would be moved or replaced, and how long the business could run without it.
- Add AI-specific failure modes (model outage, poisoned or drifted data, vendor-side compromise, prompt-injection exfiltration) to incident classification under Article 18 and the Article 19 reporting workflow, with the RTS 2024/1772 thresholds.
- Put AI services in the critical perimeter into the Article 24 testing programme and, where the bank is identified for TLPT, into the Article 26 scope; make sure vendor contracts allow it.
- Do not treat a provider's CTPP designation as relief: Lead Overseer oversight does not replace the bank's own Article 28–30 duties, and the ESAs said so when publishing the list.
- Map DORA evidence onto the AI Act and model-risk files: the same vendor, data and exit records serve the AI Act's high-risk obligations and the model-risk expectations covered in our SR 11-7 guide and BCBS 239 guide.
What are the five pillars of DORA?
ICT risk management (Articles 5–16), ICT-related incident management, classification and reporting (Articles 17–23), digital operational resilience testing (Articles 24–27), managing ICT third-party risk including the oversight framework for critical providers (Articles 28–44), and information-sharing arrangements (Article 45).
When did DORA start to apply?
On 17 January 2025, under Article 64. The Regulation was adopted on 14 December 2022, published in the Official Journal on 27 December 2022 and entered into force twenty days later; it is directly applicable in all Member States without transposition.
Does DORA apply to AI systems and AI vendors?
Yes, by definition rather than by name. AI systems are ICT assets within the Article 5–16 framework, and an AI model, LLM API or AI platform bought from a vendor is an ICT service provided by an ICT third-party service provider under Article 3, so the Article 28–30 register, due diligence, contract, concentration and exit obligations apply. AI-specific duties come from the EU AI Act, which sits alongside DORA.
What is the DORA register of information?
Under Article 28(3), a record of all contractual arrangements for ICT services provided by third parties, kept at entity, sub-consolidated and consolidated level, distinguishing services that support critical or important functions, reported to the competent authority at least yearly in the templates of Implementing Regulation (EU) 2024/2956. Competent authorities forwarded the first registers to the ESAs by 30 April 2025.
Which providers are critical ICT third-party providers under DORA?
On 18 November 2025 the ESAs designated the first 19 CTPPs, including Accenture, Amazon Web Services EMEA, Bloomberg, Capgemini, Deutsche Telekom, Equinix, FIS, Google Cloud EMEA, IBM, Kyndryl, LSEG, Microsoft Ireland Operations, NTT DATA, Oracle Nederland, Orange, SAP and Tata Consultancy Services. No stand-alone AI model developer was designated; the list is updated yearly under Article 31(9).
What must a DORA-compliant ICT contract contain?
Article 30(2) requires a full description of the services, data processing and storage locations, data availability, integrity and confidentiality provisions, access, recovery and return of data on termination or insolvency, service levels, incident assistance, cooperation with authorities, and termination rights with notice periods. For services supporting critical or important functions Article 30(3) adds service-level descriptions with targets, notice and reporting duties, contingency plans, TLPT participation, unrestricted access, inspection and audit rights, and exit arrangements.
What are the penalties under DORA?
For financial entities, Article 50 leaves it to Member States to set effective, proportionate and dissuasive administrative penalties and remedial measures; the Regulation fixes no amounts for banks. For critical ICT third-party providers, a Lead Overseer can impose periodic penalty payments of up to 1 % of average daily worldwide turnover for up to six months under Article 35(6)–(8).
How does DORA differ from the EU AI Act for banks?
DORA governs the resilience, incident and vendor risk of all ICT, including AI, and has applied since January 2025. The AI Act governs AI systems by risk class, with high-risk obligations for creditworthiness assessment and credit scoring of natural persons applying from 2 December 2027 after the Digital Omnibus deferral. A bank using a third-party AI model needs both: an AI Act classification and a DORA register entry, contract and exit plan.
- Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA) — European Parliament and Council (EUR-Lex), Dec 27, 2022 (eur-lex.europa.eu) · our page on DORA (Regulation (EU) 2022/2554)
- List of implementing and delegated acts for Regulation (EU) 2022/2554 — European Commission, DG FISMA, Jun 1, 2025 (finance.ec.europa.eu)
- The ESAs announce timeline to collect information for the designation of critical ICT third-party service providers — EBA, EIOPA and ESMA, Nov 15, 2024 (eba.europa.eu)
- The European Supervisory Authorities designate critical ICT third-party providers under DORA — EBA, EIOPA and ESMA, Nov 18, 2025 (eba.europa.eu)
- ESA Statement: Toward a consistent and risk-based approach for ICT risks from frontier AI models (JC 2026 25) — EBA, EIOPA and ESMA, Jul 31, 2026 (eba.europa.eu) · our page on ESA Statement on ICT risks from frontier AI models (JC 2026 25)
- ECB Guide on outsourcing cloud services to cloud service providers — ECB Banking Supervision, Jul 16, 2025 (bankingsupervision.europa.eu) · our page on ECB Guide on outsourcing cloud services
- Strengthening operational resilience for the age of AI (speech by Frank Elderson) — ECB Banking Supervision, Jun 3, 2026 (bankingsupervision.europa.eu) · our page on Elderson speech: 'Strengthening operational resilience for the age of AI' (June 2026)
- Principles for the sound management of third-party risk — Basel Committee on Banking Supervision, Dec 10, 2025 (bis.org) · our page on BCBS Third-Party Risk Principles (Dec 2025)
- Information and communication technology risk management: range of practices — Basel Committee on Banking Supervision, Jun 2, 2026 (bis.org) · our page on BCBS ICT Risk Management Report (June 2026)
- Regulation (EU) 2024/1689 (EU AI Act) — European Parliament and Council (EUR-Lex), Jul 12, 2024 (eur-lex.europa.eu) · our page on Regulation (EU) 2024/1689
When this rule moves, the next morning's brief says so
when one of these regulators moves, the next morning's brief says so · six sourced stories · 7 am ET · free
plus every tracker, bank and agent page update, the morning after · leave any morning