DORA Deep Dive

What is DORA?

DORA is the Digital Operational Resilience Act, Regulation (EU) 2022/2554. It is the EU's operational resilience rulebook for the financial sector. As a regulation it has direct effect across all Member States, with no national transposition required.

The premise is straightforward: financial firms run on technology, and a serious technology failure today is a financial event. DORA forces every financial entity, and the critical IT providers serving them, to manage IT risk the same way they manage credit risk or market risk.

Who is in scope

DORA reaches far further than most operational regulations. In scope:

• Credit institutions, payment institutions, e-money institutions, investment firms
• Insurance and reinsurance undertakings, insurance intermediaries above thresholds
• Central counterparties, trading venues, central securities depositories
• Crypto-asset service providers under MiCA
• Crowdfunding service providers, securitisation repositories, credit rating agencies
• Administrators of critical benchmarks (e.g. EURIBOR)

And critically: DORA also reaches the critical IT third-party providers serving financial firms. The European Supervisory Authorities (EBA, ESMA, EIOPA) can formally designate providers as "critical" under Article 31, putting them under direct EU oversight. Expect Microsoft Azure, AWS, Google Cloud, SAP, and similar to land in that designation.

The five pillars

1. ICT risk management (Articles 5 to 16)

A documented framework covering identification, protection, detection, response, recovery, learning, and communication. Board-approved. Reviewed at least annually. The management body is liable for ICT risk decisions and cannot delegate that liability.

2. Incident management, classification, reporting (Articles 17 to 23)

The strictest reporting cascade in EU financial regulation. Major ICT-related incidents trigger:

• Initial notification within a few hours of awareness
• Intermediate report within days
• Final report within one month covering root cause, impact, lessons learned

3. Digital operational resilience testing (Articles 24 to 27)

Two layers. All firms perform basic testing (vulnerability scans, penetration tests, source code reviews where appropriate). The largest and most systemic firms perform Threat-Led Penetration Testing (TLPT) at least every three years on critical functions, modelled on TIBER-EU.

4. ICT third-party risk management (Articles 28 to 44)

This is the pillar that creates the most work for IT vendors:

• Maintain a register of all ICT third-party contracts
• Classify each contract by criticality
• Negotiate mandatory clauses (access, audit, security, sub-outsourcing, exit, data location)
• Conduct due diligence before contracting
• Monitor performance, manage concentration risk, plan and test exit strategies

5. Information and intelligence sharing (Article 45)

Permissive rather than mandatory. Financial entities may share cyber-threat information within trusted communities, with appropriate safeguards. The intent is collective sector defence.

The third-party register, in detail

The DORA register is one of the most consequential operational deliverables in the whole regulation. The ITS on the register of information sets out what goes in:

• Provider details including LEI (Legal Entity Identifier)
• Contract details and criticality classification
• Which functions of the financial entity the contract supports
• Data categories processed, processing locations, EU-vs-non-EU data flows
• Sub-outsourcing chain
• Concentration metrics and exit arrangements

The register is submitted at least annually to the competent authority (in Germany: BaFin). The aggregated EU register is how the European Supervisory Authorities identify critical providers.

What DORA means for AI vendors specifically

If you build AI for European financial firms, three things change:

• Your contracts must include DORA clauses. These are mandatory for the customer, not optional
• Audit rights become real. Financial customers can audit you, on-site, with their auditors and competent authorities in the room
• Exit strategies must be contractual, costed, and tested. Lock-in business models do not survive DORA

Timeline

• 16 January 2023: DORA entered into force
• 17 January 2025: DORA became applicable across the EU
• 2024 to 2025: Level 2 RTS and ITS published, translating the principles into operational detail
• 2026 onwards: Supervisory regime intensifies. Critical ICT third-party providers begin to be formally designated

Fines and supervisory teeth

• Administrative fines for financial entities are set by national law and can be substantial
• For critical ICT third-party providers, the regulation enables periodic penalty payments up to 1% of the provider's average daily worldwide turnover
• Supervisors can require corrective actions, restrict activities, and ultimately order termination of contracts

Who enforces it

• The European Supervisory Authorities (EBA, ESMA, EIOPA) coordinate at EU level
• Critical ICT third-party providers are designated by the ESAs and overseen by Lead Overseers
• National competent authorities supervise financial entities directly
• In Germany, BaFin and the Deutsche Bundesbank share supervisory responsibility for banks. See the BaFin lesson for how supervision works in practice

How DORA interacts with the other frameworks

• NIS2: financial entities are absorbed into DORA as lex specialis. NIS2 still reaches the ecosystem (data centres, telcos, ICT service managers) directly
• EU AI Act: DORA covers the ICT environment around an AI. The AI Act covers the AI system as a product. Both apply to a high-risk AI in a financial firm
• MaRisk and BAIT: substantial overlap. MaRisk-compliant firms have a head start, but DORA is tighter. Both apply in parallel
• ISO 42001: no direct overlap, but useful as an AI management system layer inside a DORA-governed environment

What to do next

• If you are a financial entity: confirm your DORA register is complete, criticality classifications are defensible, and contractual amendments with ICT providers are signed
• If you are an IT or AI vendor selling into financial firms: draft a standard DORA addendum you can offer customers, rather than renegotiating clause-by-clause
• Review your incident detection capability against the DORA reporting timeline. Hours matter, not days
• Test your exit strategy. A plan that has never been tested is a plan that does not exist
• Use the classifier tool to map your system across DORA and the other six frameworks