DORA Compliance for AI Products and ICT Systems
DORA applies to your AI system if it touches financial services. Most fintech teams haven’t mapped it.
How GDPR works for AI products
The Digital Operational Resilience Act has applied since 17 January 2025. It covers every financial entity operating in the EU — banks, investment firms, insurance companies, payment institutions, crypto-asset service providers, and more — and critically, every ICT third-party provider that supplies technology services to them.
If your AI system is used by a financial entity, integrated into financial infrastructure, or sold to regulated financial services firms, DORA reaches you — regardless of whether you are a financial entity yourself.
DORA’s core demand is operational resilience: the ability of financial entities and their technology suppliers to withstand, respond to, and recover from ICT-related disruptions. For AI systems this creates specific obligations around risk management, incident classification and reporting, resilience testing, and third-party oversight that sit alongside and frequently interact with EU AI Act and GDPR requirements.
DORA Compliance Assessment for Your AI System
Fixed price · Named lawyer · AI and fintech specific · Delivered in 5 working days
How DORA works for AI products
DORA organises its requirements across five areas. Each creates specific obligations for AI systems used in or supplied to the financial sector.
ICT risk management
A documented framework for identifying, classifying, and managing ICT risks across the organisation. For AI systems this means mapping every AI product as a named ICT asset with a specific risk profile — covering availability, integrity, confidentiality, and authenticity — and documenting the controls in place for each.
ICT incident reporting
Classification and mandatory reporting of ICT-related incidents to competent authorities within defined timelines. AI system failures, anomalous outputs, significant model degradation, and availability disruptions must be assessed against DORA’s major incident thresholds and reported where those thresholds are met.
Digital operational resilience testing
Regular testing of ICT systems to verify they can withstand operational disruption. AI systems must be included in the financial entity’s resilience testing programme — basic testing annually, threat-led penetration testing every three years for significant entities. Where AI systems are potential vectors for adversarial attack, adversarial testing is directly relevant.
ICT third-party risk management
Oversight of every ICT third-party provider — including contractual requirements, performance monitoring, and documented exit strategies. AI suppliers to financial entities must satisfy DORA’s mandatory contractual provisions. Financial entities must actively oversee their AI suppliers. Neither party can treat this as a passive relationship.
Information sharing
Voluntary sharing of cyber threat intelligence among financial entities to strengthen collective resilience. Where AI systems are targeted in cyber incidents — model poisoning, adversarial inputs, infrastructure attacks — the intelligence arising from those incidents is within the scope of DORA’s information-sharing framework.
Who DORA applies to
DORA applies directly to financial entities and to the ICT third-party providers that serve them. AI companies frequently find themselves in scope as ICT third-party providers without having identified themselves as such.
| Entity type | In scope of DORA? | Key obligation |
|---|---|---|
| EU bank or credit institution | Yes — directly | Full DORA compliance including ICT risk management, incident reporting, testing |
| EU investment firm | Yes — directly | Full DORA compliance |
| EU insurance or reinsurance undertaking | Yes — directly | Full DORA compliance |
| EU payment institution | Yes — directly | Full DORA compliance |
| EU crypto-asset service provider | Yes — directly | Full DORA compliance |
| AI company supplying systems to EU financial entities | Yes — as ICT third-party provider | Contractual DORA requirements, cooperation with oversight, information provision |
| Critical ICT third-party provider (designated by ESAs) | Yes — direct oversight | Oversight framework including threat-led penetration testing, information requests, inspections |
| Non-EU AI company supplying EU financial entities | Yes — extraterritorial | Same ICT third-party requirements as EU-established suppliers |
| AI company with no financial sector clients | No | Not in scope — but document this determination |
| SaaS provider used by financial entities for non-critical functions |
ICT third-party risk: the obligation AI suppliers miss
DORA’s ICT third-party risk management framework is the provision most AI companies overlook. Financial entities must identify, assess, and manage the risks posed by their ICT third-party providers. That creates direct contractual and operational obligations for every AI supplier to a financial entity — regardless of whether the AI company is itself regulated.
Three things AI suppliers to financial services consistently misunderstand:
DORA requires financial entities to include specific provisions in their contracts with ICT third-party providers — covering accessibility, availability, integrity, security, and the right to audit. If you supply AI to a financial entity and your contract does not include these provisions, your client is non-compliant and the relationship is under pressure at every regulatory review.
Critical ICT third-party providers — those designated by the European Supervisory Authorities as systemically important — face direct DORA oversight including threat-led penetration testing, information requests, and on-site inspections. AI companies that become critical suppliers to the financial sector may find themselves directly supervised.
Exit strategies are mandatory. Financial entities must maintain documented exit plans for every critical ICT third-party relationship — including the ability to migrate away from an AI system if necessary. AI suppliers that create lock-in without supporting exit planning create compliance problems for their clients and commercial risk for themselves.
What DORA compliance requires for AI products
These are the DORA requirements that apply most directly to AI products used in or supplied to the financial services sector.
Business continuity and exit support — documented arrangements supporting your financial entity clients’ exit planning — data portability, transition assistance, and continuity of service during migration — satisfying DORA’s exit strategy requirements
ICT asset classification — your AI system must be identified and classified as an ICT asset within the financial entity’s ICT risk management framework, with a specific risk profile covering availability, integrity, confidentiality, and authenticity
ICT risk assessment — a documented assessment of the risks your AI system poses to the financial entity’s operational resilience — including model failure, adversarial manipulation, data poisoning, and dependency on upstream AI infrastructure
Incident classification framework — a defined framework for classifying AI system incidents — model degradation, anomalous outputs, availability failures, security breaches — against DORA’s major incident thresholds and reporting timelines
Resilience testing inclusion — your AI system must be included in the financial entity’s digital operational resilience testing programme, including basic testing annually and threat-led penetration testing for significant entities every three years
Contractual DORA compliance — contracts with financial entity clients must include DORA-mandated provisions covering service levels, security standards, audit rights, incident notification, and exit support — non-compliant contracts expose your clients to regulatory findings
Sub-ICT-provider chain mapping — identification and documentation of every upstream ICT provider your AI system depends on — cloud infrastructure, model APIs, data providers — with concentration risk assessment where multiple dependencies converge on the same provider
Concentration risk assessment — assessment of whether your AI system creates undue concentration risk for your financial entity clients — particularly where the same AI infrastructure is used across multiple regulated entities simultaneously
One engagement. Every DORA obligation mapped for your AI system.
A lawyer-built assessment of your AI system’s DORA obligations — ICT asset classification, incident reporting framework, resilience testing inclusion, contractual compliance review, sub-provider chain mapping, and a documented compliance record your financial entity clients and their regulators can rely on.
Frequently Asked Questions About DORA Compliance
What is DORA and who does it apply to?
The Digital Operational Resilience Act is an EU regulation that applies to financial entities and their ICT third-party providers from 17 January 2025. Financial entities in scope include banks, investment firms, insurance companies, payment institutions, electronic money institutions, crypto-asset service providers, and others. ICT third-party providers — including AI companies supplying technology services to financial entities — face direct DORA obligations through their contractual relationships with regulated clients, regardless of whether they are financial entities themselves.
Does DORA apply to AI companies that are not financial entities?
Yes, if they supply AI systems to financial entities. DORA’s ICT third-party risk management framework creates direct obligations for AI suppliers through their contracts with regulated clients. Financial entities must include specific DORA provisions in their ICT third-party contracts — covering audit rights, security standards, incident notification, and exit strategies. AI companies supplying financial services firms that do not satisfy these requirements create compliance problems for their clients and commercial risk for themselves.
What is the difference between DORA and the EU AI Act for financial sector AI?
DORA governs the operational resilience of ICT systems used by financial entities — availability, continuity, incident response, and third-party risk. The EU AI Act governs the AI system itself — risk classification, prohibited practices, technical documentation, and conformity assessment. For AI systems used in financial services, both apply simultaneously. A credit scoring AI used by a bank must satisfy EU AI Act high-risk obligations and DORA ICT risk management requirements — and GDPR automated decision-making obligations. A cross-framework assessment maps all three against the same product.
What is a critical ICT third-party provider under DORA?
Critical ICT third-party providers are designated by the European Supervisory Authorities — EBA, ESMA, and EIOPA — based on their systemic importance to the financial sector. Designation triggers direct DORA oversight including threat-led penetration testing, information requests, and on-site inspections by a Lead Overseer. AI companies that become systemically important suppliers to financial services — through wide adoption across multiple regulated entities — may find themselves designated and directly supervised. Concentration risk analysis is one of the factors the ESAs consider in designation decisions.
What DORA provisions must be included in contracts with financial entity clients?
DORA Article 30 specifies mandatory contractual provisions for ICT third-party contracts with financial entities. These include: a clear description of the services provided, service level requirements including availability and quality standards, provisions on data location and processing, security requirements including incident notification obligations, audit and access rights for the financial entity and its regulators, and exit provisions supporting the financial entity’s ability to migrate away from the service. Contracts that do not include these provisions expose the financial entity to regulatory findings at their next supervisory review.
What are DORA’s incident reporting requirements for AI systems?
DORA requires financial entities to classify ICT-related incidents against defined criteria covering client impact, duration, geographic spread, data loss, and criticality of affected services. Major incidents must be reported to the competent authority within defined timelines — initial notification within four hours of classification, intermediate report within 72 hours, and final report within one month.
For AI systems, incidents include model failures, significant output degradation, availability disruptions, and security breaches affecting the AI infrastructure. AI suppliers must notify their financial entity clients of incidents affecting the service within the timeframes established in their contracts.
Does DORA apply to non-EU AI companies supplying EU financial entities?
Yes. DORA’s ICT third-party framework applies extraterritorially — a non-EU AI company supplying services to EU financial entities is subject to the same contractual requirements as an EU-established supplier. The financial entity’s DORA obligations extend to their entire ICT supply chain regardless of where suppliers are established. Non-EU AI companies that do not satisfy DORA contractual requirements create regulatory exposure for their EU financial entity clients.
How does DORA interact with NIS2 for AI systems in critical infrastructure?
NIS2 applies to essential and important entities across critical infrastructure sectors — energy, transport, banking, financial market infrastructure, health, digital infrastructure, and others. Where an AI system is used by or within a NIS2-regulated entity, NIS2 cybersecurity obligations apply alongside DORA for financial sector entities. The two regimes overlap significantly in security requirements and incident reporting — a cross-framework assessment identifies where compliance with one contributes to the other and where distinct obligations apply.
A cross-framework assessment maps where compliance with one regime contributes to compliance with the other, and where they impose distinct and non-overlapping obligations.
What are the penalties for DORA non-compliance?
Penalties under DORA are set at member state level — the regulation requires competent authorities to have the power to impose administrative sanctions but does not set EU-wide fine maxima. In practice, competent authorities can impose fines, require remediation, restrict or suspend activities, and — for critical ICT third-party providers under direct oversight — issue recommendations and require follow-up measures. The commercial consequence of DORA non-compliance for AI suppliers — loss of financial sector clients who cannot contract with non-compliant ICT providers — is often more immediately damaging than a regulatory fine.
How do I start DORA compliance for my AI system?
Four steps in order. First, determine whether your AI system is used by or supplied to EU financial entities — if yes, DORA applies. Second, assess whether your existing contracts with financial entity clients include the mandatory DORA provisions — most pre-2025 contracts do not. Third, establish your incident classification framework for AI-specific incidents and the notification process for your clients. Fourth, map your upstream ICT dependencies — cloud providers, model APIs, data services — and assess concentration risk. A lawyer-built assessment covers all four steps and delivers a documented compliance position specific to your system and your financial sector relationships.