On this page
TL;DR
DORA (Regulation (EU) 2022/2554, in application since 17 January 2025) treats generative AI as ICT services - meaning AI vendors fall under Article 28's third-party risk regime, AI incidents fall under Article 17's reporting timeline, and AI-driven business functions sit inside the resilience testing scope. By 2026, the European Supervisory Authorities are expected to escalate enforcement on the AI-specific evidence gaps surfaced in their 2025 Joint Examination findings. Updated 2026-05-20.
What DORA is and why AI changes the calculus
DORA is the European Union's first horizontal framework for the operational and cyber resilience of the financial sector. It entered into force on 16 January 2023, applied from 17 January 2025, and is enforced jointly by the European Banking Authority (EBA), European Insurance and Occupational Pensions Authority (EIOPA), and European Securities and Markets Authority (ESMA), with national competent authorities (such as BaFin, ACPR, CSSF, and the Central Bank of Ireland) handling supervision day to day. The regulation is supplemented by a stack of regulatory technical standards (RTS) and implementing technical standards (ITS) that the European Supervisory Authorities (ESAs) finalised across 2024-2025.
DORA was drafted before generative AI achieved its current operational footprint inside financial services. It does not mention "artificial intelligence" or "large language models" in its operative text. But the regulation defines ICT services broadly enough - "digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis" - to capture every AI workload a covered entity runs, whether hosted in-house, embedded in a SaaS application, or accessed via foundation model API. The EU AI Act, which took effect 1 August 2024, then layers on top a use-case-specific regime, but the operational resilience scaffolding belongs to DORA.
For CISOs and Heads of ICT Risk inside DORA-covered entities, the practical question is no longer "does DORA apply to my AI estate?" - it does - but "where exactly does each AI workload sit in DORA's five pillars, and what evidence will the supervisor expect when they ask?" That is the question this post answers. The Areebi NIST AI RMF hub and the EU AI Act compliance guide cover the framework adjacency; this post focuses on DORA itself.
DORA's five pillars mapped to AI workloads
DORA's operative requirements organise into five pillars. Each pillar takes on additional substance once a financial entity runs AI inside or near covered functions. The mapping below is the one most large EU and UK-passported groups have settled on through 2025.
Pillar 1: ICT risk management (Articles 5-16)
Articles 5-16 require a documented ICT risk management framework owned by the management body, with strategies, policies, procedures, ICT protocols and tools to protect all information and ICT assets. When generative AI enters the estate, the supervisor expects the framework to explicitly cover model selection, prompt and output handling, retrieval augmented generation pipelines, agentic tool calls, and the human-in-the-loop checkpoints that gate consequential actions.
In practice the audit evidence financial entities now compile for AI inside Pillar 1 includes: a documented AI inventory tied to the ICT asset register; a model risk assessment per use case with criticality classification; an explicit policy on permitted providers and data classes; identity and access controls scoped to the AI layer; and audit logs that capture each AI interaction with model and policy version metadata. Without that, the supervisor's first question - "show me the rules and show me they are working" - has no answer.
Pillar 2: ICT-related incident reporting (Articles 17-23)
Article 17 obliges financial entities to detect, manage, log, classify and report major ICT-related incidents to the competent authority on a defined timeline. The Commission Delegated Regulation (EU) 2024/1772 sets the classification criteria and the Implementing Regulation (EU) 2025/302 sets the reporting templates and timelines. Initial notification is due within 4 hours of classifying an incident as major, an intermediate report within 72 hours, and a final report within one month.
For AI workloads the trigger conditions are broader than CISOs typically expect. A prompt injection that exfiltrates customer data, a retrieval pipeline that surfaces unauthorised content to a customer-facing assistant, a model outage that disables a critical function, an erroneous output that drives an automated regulatory filing, or an agentic system that executes an unauthorised action - any of these can meet the major incident threshold if the criticality, duration, and customer impact criteria are met. The Areebi audit log is designed so that the model and policy version at the time of the incident, the user identity, the data classes touched, and the response chain are reconstructable in minutes rather than days.
Pillar 3: Digital operational resilience testing (Articles 24-27)
Articles 24-27 require a programme of resilience testing proportionate to the entity's size and risk profile, including, for significant entities, advanced threat-led penetration testing (TLPT) every three years. The TIBER-EU framework underpins how TLPT is conducted, and the Joint ESA RTS published in 2024 specifies the criteria for entities in scope.
For AI workloads this pillar is where the new operational discipline of AI red teaming meets a long-standing financial regulatory scope. Threat actors targeting AI systems are explicitly named in supervisory expectations: prompt injection, jailbreak, model extraction, data poisoning, and abuse of tool integrations in agentic systems. Our AI red teaming guide walks through the technique catalogue. For DORA, the testing programme must include AI components inside the critical or important functions in scope, document the testing methodology, retain artefacts, and feed findings into the remediation plan tracked by the management body.
Pillar 4: ICT third-party risk (Articles 28-44)
Articles 28-44 codify the most prescriptive third-party regime in EU financial regulation to date. Article 28 establishes the general framework, Article 30 fixes the mandatory contractual provisions, Article 31 governs the criticality designation for ICT third-party service providers, and Articles 32-44 establish the new Oversight Framework run jointly by the ESAs over critical third-party providers (CTPPs). The Commission Implementing Regulation (EU) 2024/2956 specifies the Register of Information that every covered entity must compile.
Foundation model providers, cloud-hosted AI services, AI feature add-ons embedded in existing SaaS, and any AI vendor handling data of EU financial entities now sit firmly inside this regime. Article 30 contractual requirements include service-level descriptions, locations of data and processing, full subcontracting transparency, access and audit rights, exit strategies, and incident notification obligations. In practice, AI vendor contracts written before 2024 routinely fail Article 30 - they lack named processing locations, omit subcontracting clauses for downstream foundation model providers, and treat audit rights as discretionary. The Register of Information must be updated and submitted annually; for groups with hundreds of AI-touching vendors, this is now a recurring quarterly programme of work.
Pillar 5: Information sharing (Article 45)
Article 45 enables financial entities to participate in arrangements for sharing cyber threat information and intelligence among themselves. It is the lightest pillar by volume of text but the most operationally useful for AI defenders. AI-specific threat intelligence - prompt injection payload corpora, novel jailbreak techniques, model abuse patterns observed in the wild, malicious model artefacts uploaded to public hubs - is now exchanged through sector ISACs (FS-ISAC notably) and through the Joint Cyber Unit channels coordinated by ENISA.
For DORA purposes the operational discipline is to document participation in at least one information-sharing arrangement, capture the intelligence consumption, and demonstrate that intelligence feeds influence the security control set. The same intelligence flows that make a SOC effective against generic threats are what make an AI defence credible to supervisors.
The evidence gaps supervisors actually target
By the end of 2025 the ESAs had published several Joint Examination findings on DORA readiness, with three categories of AI-specific evidence gap dominating the supervisory feedback.
Gap 1: AI vendor coverage inside the Register of Information. Many entities compiled their first Register on a procurement-led extract, which captured contractually onboarded AI vendors but missed AI features inside non-AI vendors - meeting transcription add-ons, sales intelligence integrations, support copilots, productivity assistants - that arrived through silent updates. The ESAs are explicit that the Register must reflect the actual ICT estate, not the procurement intent. Areebi's vendor inventory and discovery telemetry are designed to reconcile the procurement-side picture with the runtime picture so the Register stays accurate between annual submissions.
Gap 2: Incident classification inconsistency for AI events. The Commission Delegated Regulation 2024/1772 classification criteria turn on criticality, duration, geographical spread, data losses, economic impact, customer impact, and reputational impact. AI incidents - a hallucinated regulatory disclosure, a leaked customer record via a customer-facing agent, an erroneous credit decision automated end-to-end - did not always trigger a major-incident classification because incident response runbooks had not been updated to include AI failure modes. Supervisors now expect runbooks to enumerate AI scenarios explicitly and exercise the classification logic in tabletop exercises.
Gap 3: TLPT scope exclusions for AI assets. Threat-led penetration testing scopes were sometimes drawn around the legacy core banking and trading systems, with AI assistants, retrieval pipelines, and embedded copilots treated as out-of-scope add-ons. The Joint ESA guidance has now clarified that any ICT asset materially contributing to a critical or important function falls inside the TLPT perimeter, including AI components. AI red teaming, including prompt injection, jailbreak, and tool-call abuse, is expected to appear in the test plan and the artefact pack.
Get your free AI Risk Score
Take our 2-minute assessment and get a personalised AI governance readiness report with specific recommendations for your organisation.
Start Free Assessment12-month DORA + AI compliance checklist
The checklist below is the one Areebi recommends to DORA-covered entities running AI in production, organised as four quarters of work across a single calendar year. Each item names the responsible function and the artefact a supervisor would expect.
| Quarter | Item | Responsible | Artefact |
|---|---|---|---|
| Q1 | Reconcile AI inventory against ICT asset register and Register of Information | ICT Risk + CISO | Updated Register of Information with AI-tagged entries |
| Q1 | Map every AI workload to one or more critical or important functions | Business owner + ICT Risk | Function-to-AI mapping table |
| Q1 | Confirm Article 30 contractual provisions in AI vendor contracts | Procurement + Legal | Contract clause matrix per AI vendor |
| Q2 | Update ICT risk management framework with AI-specific controls | Management body sponsor | Approved framework v2 with AI annex |
| Q2 | Update incident response runbooks for AI failure modes | SOC + AI governance lead | Updated runbooks plus tabletop minutes |
| Q2 | Enable per-interaction audit logging with model and policy version | CISO + Platform | Audit log sample plus retention policy |
| Q3 | Run an AI red team exercise inside resilience testing programme | CISO + Internal red team or external provider | Test plan, findings, remediation backlog |
| Q3 | Refresh DORA training for ICT and AI staff | HR + ICT Risk | Training completion by role |
| Q3 | Join or maintain participation in an information-sharing arrangement | CISO + Threat Intelligence | Membership confirmation plus intelligence consumption log |
| Q4 | Submit annual Register of Information update | ICT Risk | Submitted Register plus reconciliation evidence |
| Q4 | Run TLPT preparedness review or full TLPT if in scope | CISO + Board risk committee | TIBER-EU artefacts plus board paper |
| Q4 | Annual board review of AI risk and DORA programme | Management body | Board minutes plus signed-off risk appetite statement |
At Areebi, we built the audit log, policy engine, and vendor inventory specifically because the DORA evidence burden compounds quarter on quarter: every artefact above is easier to produce when the underlying telemetry is captured continuously by the platform rather than reconstructed from disparate logs at audit time.
Common pitfalls
Pitfall 1: Treating DORA as a cybersecurity programme rather than a resilience programme. DORA absorbs cyber security expectations but the operative concept is operational resilience - the ability to deliver critical functions through disruption, including disruption originating from AI components. CISOs who scope DORA as a NIS2 sequel routinely miss the business continuity, scenario testing, and management-body sign-off dimensions that the supervisor cares about most.
Pitfall 2: Treating foundation model providers as out-of-scope hyperscalers. A common assumption is that foundation model APIs sit downstream of a covered cloud provider and therefore inherit that vendor's DORA posture. They do not. Each AI vendor relationship is its own Article 28 relationship, and the contractual provisions in Article 30 apply directly. Subcontracting chains - foundation model provider running on hyperscaler infrastructure - must be transparent in the contract and in the Register of Information.
Pitfall 3: Letting AI feature toggles bypass change management. SaaS vendors quietly enable AI features through routine updates that do not trigger procurement workflows. Without continuous discovery, the ICT estate drifts away from the documented configuration baseline, and the next major incident reveals an AI surface area the SOC did not know it had. See our shadow AI guide for the discovery mechanics.
How Areebi reduces the DORA + AI evidence burden
Areebi is an AI control plane built on AnythingLLM, designed for the kind of audit-grade evidence DORA supervisors expect from financial entities. Three platform capabilities map directly to the DORA pillars above.
Policy engine for Pillar 1. Every AI Acceptable Use Policy clause maps to a machine-readable rule enforced at the prompt layer. The policy engine versions are git-tracked, so the supervisor can see which rule set was active at any moment in time. The policy engine documentation shows the typical mapping.
Audit log for Pillar 2 and Pillar 4. Every interaction is logged with the model identifier, policy version, user identity, data classes touched, response chain, and any tool calls invoked. For an Article 17 major incident, the reconstruction window collapses from days to minutes. For the Register of Information, the audit log generates the runtime vendor exposure picture that reconciles with procurement records. The audit log overview shows the field schema.
Vendor inventory and DLP for Pillar 4. The vendor inventory tracks every AI provider in use, including the AI features inside non-AI SaaS, with risk tiering and contract clause status. DLP rules at the prompt layer prevent specific data classes from leaving the perimeter regardless of which vendor receives them. The DLP controls overview walks through the rule schema.
The Areebi AI Governance Assessment includes a DORA readiness module that scores your current state against the 12-item checklist above and produces a prioritised remediation plan, typically completed inside 30 minutes by a CISO or ICT Risk Lead.
What to read next
To go from DORA understanding to operational programme, work through this cluster.
- EU AI Act compliance for mid-market - how the AI Act layers on top of DORA inside the EU financial sector.
- AI compliance landscape 2026 - the cross-jurisdiction view including financial-services regulation.
- NIST AI RMF implementation guide - the practical end-to-end playbook for the framework that maps cleanly onto DORA Pillar 1.
- AI red teaming guide - the technique catalogue for Pillar 3 testing.
- Model supply chain security - the technical mechanics for Pillar 4 third-party AI risk.
Frequently Asked Questions
Does DORA apply to AI workloads inside financial entities?
Yes. DORA Article 3(21) defines ICT services broadly enough to capture every AI workload a covered entity runs, whether in-house, embedded in SaaS, or accessed by foundation model API. The regulation does not name AI explicitly, but the European Supervisory Authorities have confirmed through their 2025 Joint Examination feedback that AI workloads contributing to critical or important functions sit firmly inside the DORA perimeter. Coverage applies regardless of whether the AI vendor itself is established in the EU.
Are foundation model providers ICT third-party service providers under DORA?
Yes. Any provider supplying an AI service used by a DORA-covered entity meets the Article 3(19) definition of ICT third-party service provider. That triggers the Article 28 general framework, the Article 30 mandatory contractual provisions, and inclusion in the Register of Information specified by Commission Implementing Regulation (EU) 2024/2956. Whether a provider is also designated a critical third-party service provider (CTPP) under Article 31 depends on a separate assessment by the ESAs based on substitutability, criticality, and concentration risk.
What is the incident reporting timeline for an AI-related major incident?
Article 17 of DORA requires initial notification to the competent authority within 4 hours of classifying an ICT-related incident as major, an intermediate report within 72 hours, and a final report within one month. The classification criteria are set by Commission Delegated Regulation (EU) 2024/1772 and turn on criticality of services affected, customers and counterparties impacted, data losses, duration, geographical spread, economic impact, and reputational impact. AI-specific incidents such as a customer-facing prompt injection that exfiltrates customer data, or a hallucinated regulatory disclosure published at scale, frequently meet the major threshold.
Does DORA require AI red teaming?
DORA does not name AI red teaming as a separate obligation, but Articles 24-27 require a comprehensive resilience testing programme that, for entities in scope of advanced threat-led penetration testing (TLPT) under the TIBER-EU framework, must cover every ICT asset materially contributing to critical or important functions. The Joint ESA guidance has clarified that this includes AI components, and prompt injection, jailbreak, model extraction, and agentic abuse are explicitly named as in-scope attacker techniques. Most large financial entities have added AI red teaming to their TLPT scope from the 2025-2027 cycle onwards.
How does DORA interact with the EU AI Act?
DORA governs the operational resilience and ICT third-party risk dimensions of AI in financial services. The EU AI Act, in application from 1 August 2024 with staggered obligations through 2027, governs the use-case-specific obligations - prohibited practices, high-risk AI system requirements, transparency obligations, and general-purpose AI model rules. The two regulations are designed to coexist: an AI system used by a financial entity inside a critical function must satisfy DORA's operational resilience scaffolding and the AI Act's use-case-specific obligations simultaneously. The Areebi EU AI Act compliance guide covers the AI Act half in detail.
What is the Register of Information under DORA and how does AI fit?
The Register of Information, specified by Commission Implementing Regulation (EU) 2024/2956, is a structured record of all ICT third-party service arrangements that every DORA-covered entity must compile, maintain, and submit to its competent authority annually. AI vendors, including foundation model providers, AI-feature add-ons in non-AI SaaS, and embedded AI in productivity tools, must be captured. The most common compliance failure is incomplete coverage of AI features quietly enabled inside non-AI SaaS vendors - which is why continuous discovery, not procurement-only sourcing, is now the supervisor expectation.
Related Resources
Stay ahead of AI governance
Weekly insights on enterprise AI security, compliance updates, and governance best practices.
Stay ahead of AI governance
Weekly insights on enterprise AI security, compliance updates, and best practices.
About the Author
Areebi Research
The Areebi research team combines hands-on enterprise security work with deep AI governance research. Our analysis is informed by primary sources (NIST, ISO, OECD, federal registers, IAPP) and the operational realities of CISOs running AI programs in regulated industries today.
Ready to govern your AI?
See how Areebi can help your organization adopt AI securely and compliantly.