The Digital Operational Resilience Act (Regulation (EU) 2022/2554) has applied to EU financial entities since 17 January 2025. The ESAs’ first annual incident report counted 3,383 major ICT-related incidents in 2025, and the first 19 critical ICT third-party providers were designated on 18 November 2025. This article maps DORA requirements to recommended audit tests, evidence, and warning signs, illustrated through a hypothetical AI fraud-service outage.
DORA in one paragraph
DORA Regulation (EU) 2022/2554 is the EU’s framework for ICT risk in the financial sector. It has applied directly across the EU since 17 January 2025 to the Article 2 financial entities (banks, payment and e-money institutions, investment firms, insurers, crypto-asset service providers, market infrastructures, and others), reaching their ICT providers through contracts and, for designated providers, through direct EU-level oversight. Its five pillars are ICT risk management; incident management, classification, and reporting; resilience testing; third-party risk; and information sharing.
The central question
Can the firm keep processing payments safely when its AI fraud service fails and can it prove that fallback works?
The argument for year two
In 2026, the question is whether the controls work. That is this article’s argument, not a claim about supervisory behavior. DORA’s first year produced the paperwork layer: frameworks, registers, remediated contracts, and playbooks. Its second year produces something new for auditors: a baseline. Financial entities reported 3,383 major ICT-related incidents in 2025, according to the European Supervisory Authorities’ (ESAs) first annual report under Article 22(2), published 3 June 2026. The ESAs designated the first 19 critical ICT third-party providers (CTPPs) under Article 31(1)(a) on 18 November 2025, with the list published under Article 31(9), drawn from the registers firms themselves filed.
Neither figure alone proves a supervisory shift. Together they provide auditors a testable surface: incident data for checking classification and reporting discipline, and a designation list for checking registers and contracts. The ESAs caution against reading incident volume as a weakness, and that caution points to the right standard: assess incident patterns alongside detection, containment, recovery, and remediation.
The five pillars in brief
ICT risk management (Arts. 5–6, a management-body-owned framework reviewed at least annually, or periodically for microenterprises, and after major incidents); incident management, classification, and reporting (Arts. 17–20); resilience testing (Arts. 24–27, including TLPT for identified entities); third-party risk (Arts. 28–31); and information sharing (Art. 45 voluntary to join, with participant obligations including notifying authorities when joining or leaving and sharing safeguards).
The audit overlay: requirement → test → evidence → warning sign
The graphic maps DORA requirements to recommended audit tests, evidence, and warning signs. These procedures are practical suggestions, not additional legal requirements. Participation in Article 45 information-sharing arrangements is voluntary; if a firm chooses to participate, it must meet the applicable notification and safeguarding obligations.
The AI twist: three thresholds, not one status
The sentence to get right: an AI service can already fall within DORA’s ICT third-party requirements. First assess scope (Article 2) and whether the service supports a critical or important function, then place the arrangement:
Threshold 1: ordinary ICT-service requirements. Any ICT third-party arrangement: due diligence and risk assessment, a register entry (Article 28), and a contract with the Article 30(2) baseline terms for services and data locations, security requirements, incident-assistance duties, cooperation with authorities, termination rights and notice periods, and security-awareness and training participation.
Threshold 2: enhanced requirements for services supporting critical or important functions. Article 30(3) adds extensive audit, inspection, and access rights for the firm and its competent authority; participation in the firm’s testing, including TLPT; business-continuity testing; a documented exit strategy with a transition period; and conditions and visibility for sub-outsourcing.
Threshold 3: designation as a critical provider. The ESAs designate providers as critical under Article 31(1)(a); the list is published and updated under Article 31(9). The November 2025 list of 19 is historical; it does not by itself establish today’s provider count. Designation brings direct EU-level oversight by a lead overseer, a status the provider holds, not something the firm negotiates.
Nothing in DORA says “AI.” An AI fraud-scoring service in a payments flow needs no AI-specific rule: if it supports a critical function, Threshold 2 already applies, with controls proportionate to the function’s criticality and the dependency’s risk. The worked example tests exactly that.
Worked example: the fraud-model outage
Hypothetical exercise, constructed to illustrate the method.
Meridian Payments, a fictional payment institution, relies on an AI vendor’s fraud-scoring API to clear card transactions. On a Saturday peak, the API returns errors, then stale scores, leaving the fraud-scoring service fully or partially unavailable for a measured 3.5 hours. Meridian’s playbook switches to a rules-based fallback and queues borderline transactions for manual review. Payments keep flowing. Here is how an auditor tests whether that story is resilience or luck.
Classification with actual thresholds. A degraded control at peak warrants assessment; it does not by itself establish a major incident. Meridian’s worksheet does the assessment: the gateway is met (a critical function, payments, is affected), and three RTS 2024/1772 Article 9 thresholds are met transactions (affected transactions exceeded 10% of the daily average number for the affected service); downtime (the service was fully or partially unavailable for a measured 3.5 hours, above the 2-hour threshold for critical-function services); geographical spread (impact in two Member States). Two qualifications matter. The counted transactions were those delayed or otherwise impaired, held in the manual-review queue with clearance times above baseline. Transactions successfully rerouted and cleared normally are not counted as impaired; successful rerouting alone does not establish impairment. And the 3.5 hours is the measured period of full or partial unavailability, the threshold input, not the vendor’s overall disruption window, which may be longer or shorter. Gateway plus thresholds met: the incident is classified as major, and the worksheet shows its working. Had the outage lasted minutes with negligible transaction impact, the same worksheet could have concluded “not major” the method, not the outcome, is the point.
The clock with its starting points. The initial notification is due as early as possible, within four hours of classifying the incident as major, and generally no later than 24 hours after the firm becomes aware of it; where classification as major happens later, the rule for later classification applies, and the initial notification is due within four hours of that classification. The intermediate report is due within 72 hours of the initial notification, even if nothing has changed. Updated intermediate reports must follow without undue delay, including when regular activities have recovered. The final report is due within one month of the intermediate report or of the latest updated intermediate report. The auditor’s test is mechanical: demand the awareness, classification, and submission timestamps, and check each interval against its own starting point. Where the incident affects clients’ financial interests, the firm must also inform those clients without undue delay.
The fallback evidence. The activation log and queue data establish activation and throughput, not safety by themselves. Safety evidence adds fraud losses versus baseline, false approvals, reconciliation errors, manual-review capacity against queue depth, and the false-decline rate versus baseline. A vendor SLA promising uptime is none of these.
The verdict pattern. These records allow the auditor to assess whether the fallback met defined operational and risk tolerances. A firm that produces only a vendor incident report and a framework document has not provided that basis.
Checklist: ten DORA audit points
Scope confirmed: the entity’s Article 2 scope established; critical and important functions identified and documented
Framework owned: ICT risk management framework approved by the management body and reviewed after the last major incident (Arts. 5–6)
Classification mapped: incident classification criteria mapped to Article 18 and RTS 2024/1772, with reclassification when facts change
Clock owned: reporting playbook names a clock owner; awareness time and classification time are captured as separate timestamps
Last clock reconstructed: the last major incident’s initial, intermediate, and final reports filed with each interval checked against its own starting point
Testing covers the critical: all systems supporting critical or important functions tested in the last year (Art. 24(6)); TLPT status confirmed where the entity is identified (Art. 26)
Register complete: the register of information covers all ICT arrangements, including subcontractors effectively underpinning critical or important services as specified in the register standards (Art. 28(3))
Contracts checked: top providers’ contracts verified for Article 30(2) and, where applicable, Article 30(3) provisions; exit strategies exercised, not just written
Concentration assessed: concentration risk assessed across providers, including shared infrastructure beneath separately procured tools
Information sharing recorded accurately: notifications to authorities and safeguards tested where applicable; nonparticipation never scored as a finding (Art. 45)
What to do next
This week: Map every AI service in production to the functions it supports, and check register entries and Threshold 2 contracts for critical-function services.
This month: Reconstruct the reporting clock for your last major incident from raw timestamps, and run a fallback drill on your most critical AI-dependent flow: kill the service in staging, activate the fallback, and measure whether processing stays safe.
This quarter: Verify Article 30(3) provisions in the contracts of three providers supporting critical or important functions, and exercise one exit strategy on paper with the team that would actually execute it.
Ongoing: Track the ESAs’ annual incident report and the current CTPP list publication under Article 31(9) , the 11/ 2025 list does not establish today’s count.
What DORA doesn’t do
Three limits. First, proportionality: microenterprises carry lighter requirements in several articles, and TLPT applies only to identified entities: demanding it of everyone misreads the law. Second, no AI-specific chapter: the AI argument rests on existing ICT third-party requirements, not rules yet to be written. Third, coverage edges: DORA binds in-scope entities directly; non-EU providers are reached via contracts and, if designated, direct oversight, not by DORA alone.
Sources
Regulation (EU) 2022/2554 (DORA) — EUR-Lex: https://eur-lex.europa.eu/eli/reg/2022/2554 — Articles 2 (scope), 5–6 (ICT risk management framework), 17–20 (incident management, classification, and reporting), 22(2) (ESAs annual incident report), 24–27 (resilience testing, including TLPT), 28 (third-party risk and register of information), 30 (key contractual provisions: baseline terms in 30(2), enhanced terms for critical or important functions in 30(3)), 31 (designation of critical providers in 31(1)(a); publication and updating of the list in 31(9)), 45 (voluntary information sharing, with participant obligations)
Commission Delegated Regulation (EU) 2025/301, Article 5 (incident-reporting timelines: initial notification within four hours of classification and generally no later than 24 hours after awareness, with a rule for later classification; intermediate report within 72 hours of the initial notification; final report within one month of the intermediate or latest updated intermediate report)
Commission Delegated Regulation (EU) 2024/1772 (classification criteria; Article 9 materiality thresholds, including 10% of daily average transactions, 2-hour downtime for services supporting critical or important functions, and impact in two or more Member States)
European Supervisory Authorities (EBA, EIOPA, ESMA), first annual report on major ICT-related incidents under DORA, 3 June 2026 (Article 22(2)) — 3,383 major incidents reported in 2025
European Supervisory Authorities, first list of critical ICT third-party providers, 18 November 2025 (designation under Article 31(1)(a); publication under Article 31(9)) — 19 providers designated