DORA Compliance for AI Systems: Rules, Deadlines, Checklist

The Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, entered into force on 16 January 2023 and has applied since 17 January 2025 across the European Union. It governs the operational resilience of 20 types of financial entities (banks, insurers, investment firms, payment service providers, crypto-asset service providers, and the rest), along with the ICT third-party service providers that supply them.

DORA does not mention artificial intelligence by name. It does not need to. Every AI system used by a financial entity, whether a fraud-detection model, a customer-service chatbot, an underwriting agent, or a multi-agent workflow that touches customer data, is ICT under DORA's definition. That makes the full set of DORA compliance requirements (ICT risk management, incident reporting, resilience testing, and third-party risk) applicable to AI from the moment those systems go into production.

The sections below cover what DORA requires, how each requirement maps to AI systems specifically, the 4-hour major incident notification rule with regulatory citations, the threat-led penetration testing (TLPT) regime as it applies to AI, and the contractual obligations for AI vendors, including what the first critical-provider designations in November 2025 mean for the AI supply chain. The article ends with a DORA compliance checklist for security and platform teams running AI in scope.

What is DORA?

DORA is the EU's comprehensive ICT operational resilience regulation for the financial sector. It sets binding rules for ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing among financial entities, with enforcement applicable since 17 January 2025. AI systems used by in-scope entities are ICT systems and fall under DORA's full framework by default.

The regulation is structured around five operational pillars, supported by a series of Commission Delegated Regulations and Implementing Regulations that specify the technical detail.

When DORA applies to AI systems

DORA applies to AI systems whenever the entity operating or relying on the AI is in scope of the regulation, or when the AI vendor itself is designated as a critical ICT third-party service provider.

In-scope financial entities include credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, central counterparties, trade repositories, alternative investment fund managers, UCITS management companies, insurance and reinsurance undertakings, insurance intermediaries, institutions for occupational retirement provision, credit rating agencies, administrators of critical benchmarks, crowdfunding service providers, securitisation repositories, and central securities depositories, among others. The full list is in DORA Article 2.

ICT systems in scope. DORA defines ICT broadly. Any "network and information system" used by a financial entity to provide its services is ICT under the regulation. AI models running in production, agentic systems that take consequential actions, retrieval-augmented chatbots, and machine-learning components inside larger applications all qualify.

Third-party AI vendors. AI vendors that provide services to financial entities are ICT third-party service providers under DORA. If a provider is designated as critical under DORA Article 31, it becomes subject to direct oversight by the European Supervisory Authorities. The first designation round in November 2025 named 19 providers, dominated by the cloud platforms most production AI runs on.

Geographic reach. DORA applies to financial entities operating in the EU, regardless of where the AI vendor is headquartered. A US-based AI vendor selling to EU banks must support its customers' DORA obligations under the contracts.

The 5 DORA pillars applied to AI systems

DORA's substantive requirements sit across five operational pillars. Each applies to AI systems with specific implications.

Pillar 1: ICT risk management for AI systems

DORA Articles 5 to 15 require financial entities to maintain a comprehensive ICT risk management framework approved by the management body. The technical detail is in Commission Delegated Regulation (EU) 2024/1774.

Applied to AI systems, the framework must cover:

• Inventory of AI assets. Every AI model, every agent, every MCP server, every retrieval index in production. The inventory must be maintained at the level required for the identification and business-impact work under Article 8.
• Risk assessment. AI-specific risks (prompt injection, data poisoning, hallucination, agent autonomy, supply chain) are ICT risks under DORA. They must be identified, classified, and assessed in the same framework as other ICT risks.
• Protection and prevention measures. The technical and organizational controls deployed against AI risks (input filtering, runtime guardrails, identity-bound tool scope) are ICT protection measures under Article 9.
• Detection. Continuous monitoring of AI systems for anomalous behavior, with detection criteria approved at the management body level.
• Response and recovery. Documented procedures for AI failures (model degradation, agent misbehavior, exfiltration via tool calls) integrated with the entity's broader incident response.

Pillar 2: ICT-related incident reporting for AI failures

DORA Articles 17 to 23 require financial entities to manage and report ICT-related incidents. Major incidents must be reported to the competent authority on a strict timeline. The classification criteria are in Commission Delegated Regulation (EU) 2024/1772, and the reporting timelines and templates are in Commission Delegated Regulation (EU) 2025/301 and Commission Implementing Regulation (EU) 2025/302.

Major AI incidents that trigger DORA reporting include:

• An AI agent that takes unauthorized action affecting customers or markets
• A model failure that produces incorrect outputs at scale (mass mispricing, mis-categorization, mis-classification)
• A successful prompt injection or jailbreak that leads to data exfiltration
• An AI vendor outage that materially affects the financial entity's services

The classification thresholds in Regulation 2024/1772 are based on the impact on customers, services, financial losses, and reputational impact, not on the type of system. AI failures that meet the thresholds are reportable on the same timeline as any other major ICT incident.

Pillar 3: Digital operational resilience testing for AI

DORA Articles 24 to 27 require a comprehensive testing programme. For the entities that meet the criteria, this includes threat-led penetration testing under Article 26, with detailed requirements in Commission Delegated Regulation (EU) 2025/1190, applicable since July 2025.

Applied to AI:

• Standard testing (vulnerability assessments, scenario-based tests, performance and end-to-end tests) must include the AI components in production. AI red teaming, prompt injection scenario tests, and adversarial robustness testing are within scope.
• TLPT is the most demanding DORA penetration testing requirement. Where applicable, it must include AI systems that are part of the entity's critical or important functions. We cover TLPT specifically in a later section.

Pillar 4: ICT third-party risk management for AI vendors

DORA Articles 28 to 44 are the longest section and the one most directly relevant for AI vendors. The register of information template is specified in Commission Implementing Regulation (EU) 2024/2956, and the subcontracting requirements are in Commission Delegated Regulation (EU) 2025/532.

Applied to AI vendors:

• Pre-contract due diligence. Before contracting with an AI vendor, the entity must assess whether the vendor supports a function critical or important to the entity, evaluate the vendor's information security and resilience, and identify any concentration risk.
• Contractual provisions are mandated by DORA Article 30. Contracts must cover description of services, data location, processing standards, performance levels, audit rights, security incident notification, exit strategies, and (under Article 30(3)) additional provisions for services supporting critical or important functions.
• Register of information. Every contract for ICT services, including AI services, must be entered into the register of information per Implementing Regulation 2024/2956. Registers are collected by the competent authorities annually; the first collection ran in spring 2025.
• Concentration risk and exit planning. Entities must avoid undue concentration on any single AI vendor and must maintain documented exit strategies that are tested.
• Subcontracting controls. AI vendors that themselves rely on subcontractors (foundation-model providers, hosting providers, MCP server operators) must provide visibility under Regulation 2025/532.

Pillar 5: Information sharing

DORA Article 45 enables and encourages financial entities to share cyber threat information among themselves through trusted communities. For AI specifically, this includes sharing emerging attack patterns: new prompt injection techniques, observed agent compromise patterns, and supply-chain incidents involving AI vendors or MCP servers.

Information-sharing arrangements must comply with data protection law and competition law. They are voluntary but encouraged and increasingly expected as part of a mature operational resilience program.

DORA incident reporting timelines for AI failures

DORA Article 19, supplemented by Commission Delegated Regulation (EU) 2025/301, specifies a three-stage reporting structure for major ICT-related incidents.

Stage 1: Initial notification, within 4 hours of classifying the incident as major, and no later than 24 hours after the entity becomes aware of the incident. The initial notification contains the basic facts: detection time, classification time, a description of the incident, the systems affected, the current status, and the preliminary assessment of impact.

Stage 2: Intermediate report, within 72 hours of the initial notification, even if the status has not changed, with an updated intermediate report submitted without undue delay once regular activities are recovered. The intermediate report extends the picture: current status, scope and scale of impact, containment actions taken, effects on clients, and an estimated timeline to resolution.

Stage 3: Final report, no later than one month after the intermediate report (or the latest updated intermediate report). The final report is the comprehensive post-incident document: complete timeline, root cause analysis, full impact assessment, remediation measures, and prevention actions to reduce recurrence likelihood.

For an AI incident, the practical implication is that classification must happen quickly. A jailbroken agent that exfiltrates customer data through tool calls is a major incident the moment the impact is understood, and the 24-hour backstop means the clock is effectively running from awareness, not from classification. Entities running AI in scope of DORA need detection and triage processes that compress the time from incident occurrence to classification, and an audit trail of every agent decision and tool call that can populate the report contents within the window.

DORA threat-led penetration testing (TLPT) for AI

Commission Delegated Regulation (EU) 2025/1190, in application since July 2025, specifies which financial entities must conduct TLPT and the methodology they must follow. TLPT goes beyond traditional penetration testing: it uses threat intelligence to simulate sophisticated, real-world attacker techniques against the entity's actual production systems, with senior management aware of the test but operational teams not.

Applied to AI:

• AI systems are in scope when they support critical or important functions. A trading-decision model, a customer-onboarding AI, or an agentic system that handles transactions is squarely in TLPT scope.
• Adversarial AI techniques are part of the test. TLPT against AI systems includes prompt injection (direct and indirect), jailbreaking, model evasion, training-data and retrieval-data poisoning, and supply-chain attacks against AI vendors and MCP servers.
• Output is a formal report. The TLPT report goes to the competent authority and informs the next round of risk assessment and control updates.
• Frequency is at least every three years for entities subject to the requirement, with more frequent testing recommended for systems undergoing significant change.

The TIBER-EU framework was the precursor to DORA's TLPT regime, and the methodology is similar. Financial entities running AI in production should expect their AI red teams (in-house or contracted) to participate in TLPT engagements, and continuous AI red teaming between TLPT cycles is what keeps the three-year exercise from being the only adversarial pressure the AI estate ever sees.

Third-party AI vendor risk under DORA

The third-party risk regime under DORA Articles 28 to 44 is the section AI vendors should read most carefully. Three concrete obligations affect every AI vendor selling into EU financial services:

1. Mandatory contractual provisions. DORA Article 30 lists the provisions that must appear in every ICT services contract, with additional provisions required for services supporting critical or important functions. AI vendors should expect their financial-entity customers to push for: explicit data location and processing terms, security incident notification timelines aligned to DORA Article 19, audit rights including on-site audits, performance and service-level commitments, exit assistance for the duration of the transition period, and the right to terminate for non-compliance.

2. Register of information disclosure. Every contract must be entered into the financial entity's register of information per Commission Implementing Regulation (EU) 2024/2956. The register is shared with regulators. AI vendors should expect their customers to ask for the data needed to populate the register, including subcontractor disclosures.

3. Subcontracting visibility. Regulation (EU) 2025/532 requires visibility into where ICT vendors rely on subcontractors (foundation-model providers, hosting providers, MCP server operators) and assurance that those subcontractors meet equivalent obligations. Financial entities can refuse a vendor that cannot demonstrate adequate subcontractor controls.

Critical third-party designation is now real. On 18 November 2025, the European Supervisory Authorities (EBA, ESMA, and EIOPA jointly) designated the first 19 critical ICT third-party service providers under Article 31, based on systemic impact, the importance of the entities relying on them, sector concentration, and substitutability. The first list is dominated by the cloud and platform providers (AWS, Microsoft, Google Cloud, Oracle, SAP, and others) that most production AI runs on. No AI model vendor was designated in the first round, but the hosting layer beneath nearly every AI deployment now sits under direct ESA oversight, and the list is updated annually. Designated providers face a Lead Overseer with the power to request information, conduct investigations and inspections, issue recommendations, and impose periodic penalty payments for non-cooperation.

DORA compliance checklist for AI systems

A working DORA compliance checklist for security and platform teams running AI in scope. Each item maps to one of the five pillars.

ICT risk management for AI

• AI asset inventory maintained and reviewed at management-body level
• AI-specific risks (prompt injection, poisoning, agent autonomy, supply chain) identified and classified within the broader ICT risk framework
• Protection measures in place (runtime guardrails, input filtering, identity-bound tool scope, audit) documented and approved
• Detection capability for AI anomalies (model drift, agent misbehavior, exfiltration patterns)
• Response and recovery procedures for AI failures integrated with the entity's incident response

Incident reporting for AI

• Detection and triage processes that can classify AI incidents within hours, not days
• Reporting templates aligned to Regulation (EU) 2025/301 and Implementing Regulation (EU) 2025/302
• Internal escalation that meets the 4-hour initial notification window and the 24-hour awareness backstop
• Post-incident review feeding back into the risk framework

Resilience testing for AI

• AI components included in vulnerability assessments and scenario-based tests
• AI red teaming as part of the standard testing programme
• TLPT scope includes AI systems supporting critical or important functions (where TLPT is applicable)
• Test results recorded and remediation tracked

Third-party AI vendor risk

• Pre-contract due diligence performed for every AI vendor
• Contracts contain DORA Article 30 mandatory provisions
• Register of information populated and maintained for every AI services contract
• Subcontractor disclosures collected per Regulation 2025/532
• Concentration risk assessed and exit strategies documented and tested

Information sharing

• Engagement with relevant cyber threat information-sharing communities, where applicable
• Internal arrangements for sharing AI threat intelligence among security, platform, and risk teams

DORA AI FAQ

Does DORA apply to AI systems? Yes, by default. DORA does not mention AI explicitly, but every AI system used by an in-scope financial entity is ICT under DORA's definition. The full set of DORA compliance requirements (ICT risk management, incident reporting, resilience testing, and third-party risk) applies.

When did DORA take effect? DORA entered into force on 16 January 2023 and has applied since 17 January 2025. Enforcement is active, the TLPT technical standards have applied since July 2025, and the first critical third-party providers were designated in November 2025.

Which financial entities are in scope? DORA covers 20 types of financial entities listed in Article 2, including credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, insurance and reinsurance undertakings, central counterparties, and trade repositories, among others. The regulation also covers ICT third-party service providers, with critical providers subject to direct supervisory oversight.

What are the DORA major incident reporting deadlines? A three-stage timeline under Article 19 and Delegated Regulation (EU) 2025/301: initial notification within 4 hours of classifying an incident as major and no later than 24 hours after becoming aware of it, intermediate report within 72 hours of the initial notification, and final report no later than one month after the intermediate (or latest updated intermediate) report.

Do AI vendors need to comply with DORA? AI vendors that supply services to in-scope financial entities are ICT third-party service providers under DORA. They must support their customers' DORA obligations through contractual provisions, security incident notification, audit rights, exit assistance, and subcontractor disclosures. Vendors designated as critical providers under Article 31 are subject to direct supervisory oversight by the European Supervisory Authorities; the first 19 designations were published in November 2025.

What is TLPT and does it apply to AI? Threat-led penetration testing is DORA's most demanding testing regime, set out in Article 26 and detailed in Commission Delegated Regulation (EU) 2025/1190. It uses threat intelligence to simulate real-world attacker techniques against production systems, at least every three years for entities in scope. AI systems supporting critical or important functions are within TLPT scope. AI red teaming, prompt injection testing, and adversarial robustness testing are all expected components of a TLPT engagement that includes AI.

How does DORA relate to the EU AI Act? The two regulations are complementary. The EU AI Act sets the substantive requirements for high-risk AI systems (risk management, data governance, transparency, human oversight, accuracy, robustness, cybersecurity). DORA sets the operational resilience framework for ICT systems in financial services. An AI system used by a bank may be subject to both: the EU AI Act for the AI-specific obligations and DORA for the operational resilience and third-party risk obligations. The two frameworks do not duplicate; they layer.

Does DORA require a specific AI security tool? No. DORA is technology-neutral. It requires the financial entity to identify ICT risks (including AI-specific risks), implement appropriate protection measures, monitor and detect anomalies, and respond and recover. The choice of tools (input filtering, runtime guardrails, agent identity, audit) is up to the entity, as long as the framework is comprehensive and the controls are documented and approved at the management-body level. For the operational defender's framework that covers DORA's technical-control expectations, see our agentic AI security guide.

What are the penalties for DORA non-compliance? For financial entities, DORA leaves administrative penalties to national competent authorities; they can include financial sanctions, public reprimands, withdrawal of authorization, and personal liability for members of the management body in severe cases. For designated critical ICT third-party providers, the Lead Overseer can impose periodic penalty payments of up to 1 percent of the provider's average daily worldwide turnover for non-cooperation, applied daily for up to six months.