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 DORA works for AI products
The Digital Operational Resilience Act (DORA) 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 when did it come into force?
The Digital Operational Resilience Act is an EU regulation establishing a unified framework for ICT risk management, incident reporting, resilience testing, and third-party oversight across the EU financial sector. It has applied since 17 January 2025. Unlike most EU digital regulations, DORA does not phase in — all obligations applied simultaneously from that date. Financial entities that were not compliant on 17 January 2025 are already in breach.
Who does DORA apply to?
DORA applies to financial entities — banks, investment firms, insurance companies, payment institutions, electronic money institutions, crypto-asset service providers, pension funds, credit rating agencies, and others — and to the ICT third-party providers that supply them. The second category is where most AI companies find themselves unexpectedly in scope. If your AI product is used by a financial entity as part of its regulated service delivery, DORA reaches you through your client’s third-party oversight obligations regardless of whether you are a financial entity yourself.
Does DORA apply to AI companies that are not financial entities?
Yes, indirectly — and this is the provision most AI companies miss. DORA requires financial entities to identify, assess, and manage the risks posed by their ICT third-party providers, including AI vendors. That obligation flows through contractual requirements — financial entity clients must include specific DORA provisions in their ICT third-party contracts covering audit rights, security standards, incident notification, and exit strategies. An AI company supplying a bank, insurer, or investment firm without DORA-compliant contracts creates a regulatory problem for its client and a commercial risk for itself at every contract renewal.
Does DORA apply to non-EU AI companies supplying EU financial entities?
Yes. DORA’s third-party risk framework applies extraterritorially. A UK, US, Canadian, Swiss, or Indian 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 cannot demonstrate DORA-aligned security posture are increasingly filtered out of regulated sector procurement.
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 systemic importance to the EU 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 without having anticipated it. Concentration risk is one of the primary designation criteria.
What DORA contract provisions must AI suppliers include?
DORA Article 30 specifies mandatory contractual provisions for ICT third-party contracts with financial entities. These include a clear description of services, service level requirements covering availability and quality, data location and processing provisions, security requirements including incident notification timelines, audit and access rights for the financial entity and its regulators, and exit provisions supporting migration away from the service. Pre-2025 contracts that do not include these provisions are non-compliant.
Financial entities reviewing their supplier agreements are identifying and renegotiating them. AI suppliers that delay are creating pressure on their client relationships.
What are DORA’s incident reporting requirements for AI systems?
DORA requires financial entities to classify ICT-related incidents against defined criteria and report major incidents to their competent authority. The timeline is tight — initial notification within four hours of classification as a major incident, an intermediate report within 72 hours, and a 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 contractual timeframes — which must reflect DORA’s reporting deadlines — to allow the client to meet its own regulatory obligations.
How does DORA interact with the EU AI Act for financial sector AI?
Both regulations frequently apply to the same AI system simultaneously. The EU AI Act governs the system itself — risk classification, technical documentation, transparency, and human oversight. DORA governs its operational resilience — ICT risk management, incident response, and third-party oversight within the financial sector context. They overlap in technical robustness and post-market monitoring but impose distinct obligations.
A credit scoring AI used by a bank must satisfy EU AI Act high-risk obligations, DORA ICT risk management requirements, and GDPR Article 22 automated decision-making rules simultaneously. Assessing them separately produces gaps. Assessing them together produces a defensible position.
How does DORA interact with NIS2?
NIS2 applies broadly to essential and important entities across critical sectors including financial services. DORA is lex specialis for financial entities — where both apply to the same obligation, DORA takes precedence and satisfying DORA’s requirements is considered to satisfy the equivalent NIS2 obligation. In practice, financial entities that comply with DORA’s ICT risk management and incident reporting framework satisfy their NIS2 obligations in those areas. AI companies supplying financial entities should treat DORA as the primary framework, with NIS2 applying to their own organisation where they qualify as an essential or important entity in their own right.
What is DORA’s resilience testing requirement for AI systems?
DORA requires financial entities to test their ICT systems regularly — basic testing annually and threat-led penetration testing every three years for significant entities. AI systems must be included in these testing programmes. For AI systems that are potential vectors for adversarial attack — model poisoning, prompt injection, adversarial inputs — adversarial testing is directly relevant and increasingly expected by regulators. AI suppliers whose systems are subject to DORA testing must cooperate with the financial entity’s testing programme and provide the access and information required to conduct it.
What is DORA’s exit strategy requirement and why does it affect AI suppliers?
DORA requires financial entities to maintain documented exit plans for every critical ICT third-party relationship — including the ability to migrate away from an AI system if the relationship ends. AI suppliers that create technical or contractual lock-in — through proprietary data formats, opaque model dependencies, or punitive transfer costs — create compliance problems for their financial entity clients.
Clients subject to DORA are required to assess exit feasibility and may terminate relationships with suppliers that cannot support it. Data portability, transition assistance, and continuity of service during migration are not commercial favours — they are DORA requirements flowing through the client relationship.
What are the penalties for DORA non-compliance?
Penalties are set at member state level. Competent authorities have the power to impose fines, require remediation, restrict or suspend activities, and — for critical ICT third-party providers under direct oversight — issue binding recommendations and require follow-up measures. The commercial consequence of DORA non-compliance for AI suppliers is often more immediately damaging than any direct regulatory fine — financial entity clients that identify DORA non-compliance in their supply chain are required to act on it, which means contract termination or suspension of the relationship until remediation is complete.
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 through their third-party oversight obligations.
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 and the internal notification process that allows your clients to meet DORA’s four-hour major incident reporting timeline.
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.