DORA — Digital Operational Resilience Act

EU Regulation 2022/2554 establishing harmonised obligations for digital operational resilience in the financial sector. In force 16 January 2023; applicable 17 January 2025. As a Regulation, it applies directly and uniformly across all Member States — no national transposition required.

Scope

All financial institutions in the EU: banks, investment firms, credit institutions, insurance/reinsurance undertakings, central counterparties, trading venues, payment institutions, e-money institutions, AIFM/UCITS managers, crypto-asset service providers, etc. (Art. 2(1) lists exhaustively; Art. 2(3) exceptions).
Critical extension: ICT third-party service providers do not need to be EU-based to come under DORA. Any third party providing ICT services to a European financial entity is in scope.

The five pillars

ICT Risk Management — robust governance and control frameworks (Art. 5–16). Management bodies accountable.
ICT-Related Incident Management, Classification and Reporting — structured detection, classification, reporting of ICT incidents to competent authorities (Art. 17–23).
Digital Operational Resilience Testing — regular testing including third-party penetration testing and threat-led penetration testing (TLPT) for designated entities (Art. 24–27).
Managing of ICT Third-Party Risk — due diligence, contractual provisions (Art. 30 mandatory clauses), ICT concentration risk (Art. 28–44).
Information Sharing — voluntary sharing of cyber-threat intelligence among financial entities (Art. 45).

ESAs and policy products

The European Supervisory Authorities (EBA, EIOPA, ESMA) plus ECB and ENISA are mandated to develop 13 policy products in two batches:

First batch: RTS on ICT risk management framework; RTS on ICT incident classification; ITS for register of information; RTS on policy on ICT services performed by ICT third-party providers.
Second batch: RTS/ITS on incident reporting content/timelines/templates; GL on aggregated costs/losses from major incidents; RTS on subcontracting critical functions; RTS on oversight harmonisation; GL on oversight cooperation between ESAs and competent authorities; RTS on threat-led penetration testing (TLPT).

Connection to AI-driven process automation

For financial-sector entities deploying AI in process automation (credit scoring, fraud detection, claims handling, KYC, regulatory reporting):

ICT risk management (pillar 1) must explicitly address AI-system risks — model drift, training data integrity, adversarial inputs.
Incident reporting (pillar 2) captures AI failures alongside infrastructure incidents — note the 4-hour major incident notification requirement is tighter than NIS2's 24-hour.
Resilience testing (pillar 3) likely extends to AI components; TLPT scenarios may include adversarial ML.
Third-party risk (pillar 4) is the central pressure point — most AI components are third-party (model providers, embedding services, agentic frameworks). DORA mandates contractual clauses (Art. 30), exit strategies, ICT concentration-risk management.

Status (per BCC26 Jan 2026)

DORA has completed its first year of full implementation. Supervisors began first review cycles in early 2026; focus pivoting from implementing policies to demonstrating true operational resilience — effective controls, clear lines of ownership, ability to react quickly under pressure.

Connection to NIS2 and AI Act

DORA × NIS2: financial entities under DORA are typically also under NIS2 (banking is a NIS2 essential sector). DORA acts as lex specialis for the financial sector — its specific provisions take precedence over NIS2's general ones, but NIS2's broader governance and supply-chain requirements may still apply.
DORA × AI Act: where AI systems are used in financial decisioning (high-risk under AIA Annex III), DORA stacks operational-resilience obligations on top of AI Act compliance duties. A single AI failure may trigger reporting under both.

Risk for process-automation in financial services

Failure mode	Triggers under DORA
AI model produces incorrect credit decisions at scale	ICT incident (major) → 4-hour reporting; potential incident classification under RTS criteria
Third-party LLM provider experiences outage	Concentration-risk question; exit strategy invocation
Adversarial input causes fraud-detection bypass	Incident + resilience-testing follow-up
AI vendor breaches contract	Third-party contractual provisions (Art. 30) — exit + transition

concepts/nis2 · concepts/eu-ai-act · concepts/ict-third-party-risk · concepts/gdpr-article-22 · concepts/agentic-bpm