A mid-sized asset manager relies on a single cloud provider for portfolio data without documenting its subcontractor chain. When the provider fails, reporting is down for 48 hours. The supervisor asks for the third-party register, the exit strategy and the resilience testing protocol. Taking DORA seriously only when the supervisor calls means being structurally too late.
The Digital Operational Resilience Act (DORA) is the central EU regulation on digital operational stability in the financial sector. It consolidates requirements on ICT risk management, incident reporting, resilience testing, third-party management and information sharing into a single framework, replacing a large share of the previously fragmented national supervisory communications.
Who is affected?
DORA has an unusually broad set of addressees. It covers 21 categories of financial entities and for the first time also ICT third-party service providers directly:
- Financial entities — banks, insurers, reinsurers, investment firms, payment and e-money institutions, crypto asset service providers, central counterparties, trading venues, data reporting service providers, alternative investment fund managers, UCITS management companies, insurance intermediaries and others.
- ICT third-party service providers — all providers of digital services to financial entities, from cloud platforms and software providers to managed security services.
- Critical ICT third-party providers (CTPPs) — providers designated by the ESAs as posing a concentration risk for the financial sector. They are subject to direct European oversight with annual supervisory plans and sanctioning powers.
Proportionality (Art. 4) allows simplified requirements for microenterprises and small investment firms. The core obligations on incident reporting and the third-party register apply universally.
What does the law require?
DORA is structured around five pillars. Each pillar contains detailed requirements that are further specified through delegated acts (RTS/ITS):
- ICT risk management (Chapter II, Art. 5–16) — documented framework, reviewed annually, approved by the management body. Inventory of all ICT assets, continuous risk assessment, protection and detection measures, backup and recovery strategies.
- ICT incidents (Chapter III, Art. 17–23) — classification system, obligation to report major incidents against fixed thresholds, initial, intermediate and final reports to the supervisor. Cyberattacks are in scope.
- Resilience testing (Chapter IV, Art. 24–27) — risk-based testing programme, at least annually; for significant entities, extended Threat-Led Penetration Tests (TLPT) every three years under the TIBER-EU methodology.
- ICT third-party risk (Chapter V, Art. 28–44) — contract register with mandatory fields, concentration risk analysis, contractual minimum clauses (audit rights, subcontractor control, exit strategy), direct oversight framework for critical third-party providers.
- Information sharing (Chapter VI, Art. 45) — voluntary exchange of cyber threat intelligence between financial entities.
In practice
Have the contract register complete before the audit starts. The most common gap after DORA took effect: the register was compiled from old outsourcing lists without consistently maintaining the DORA mandatory fields (function, data category, subcontractor, country of processing, materiality rating). The supervisor can request the register at any time.
Operationalise the thresholds for incident classification. The delegated regulation defines hard criteria (customers affected, duration, geographic reach, data loss, economic impact, reputation). Without these thresholds wired into the incident response process, the initial 4-hour deadline and the follow-up reporting dates are at risk.
Test exit strategies, do more than document them. DORA requires a documented exit strategy including a transition period for every material ICT function. A strategy that has never been tested does not hold up in a crisis. Tabletop exercises with the provider are the most practical form of validation.
Mapping to ISO 27001
DORA overlaps structurally with ISO 27001 and ISO 22301. Anyone running a certified ISMS and BCMS already covers a large share of DORA requirements technically — the DORA-specific documentation structure and reporting obligations still need to be met separately.
Directly relevant controls:
- A.5.7 — Threat intelligence: basis for information sharing under Art. 45 DORA.
- A.5.19 — Information security in supplier relationships: bridge to DORA Chapter V.
- A.5.20 — Addressing information security within supplier agreements: contractual minimum content.
- A.5.21 — Managing information security in the ICT supply chain: subcontractor transparency.
- A.5.22 — Monitoring, review and change management of supplier services: ongoing oversight of third-party providers.
- A.5.23 — Information security for use of cloud services: cloud-specific DORA expectations.
- A.5.24 — Information security incident management planning and preparation: prerequisite for DORA reporting duties.
- A.5.25 — Assessment and decision on information security events: classification against DORA thresholds.
- A.5.29 — Information security during disruption: operational resilience in a crisis.
- A.5.30 — ICT readiness for business continuity: central bridge to the resilience duty in Chapter II.
- A.8.6 — Capacity management: foundation for stable ICT services.
- A.8.8 — Management of technical vulnerabilities: prerequisite for threat-led tests.
- A.8.14 — Redundancy of information processing facilities: technical resilience.
- A.8.15 — Logging: evidence for incident reports.
- A.8.16 — Monitoring activities: detection of anomalous ICT events.
Typical audit findings
- Third-party register incomplete — subcontractors are missing, materiality rating was never systematically assigned, concentration risk has not been analysed.
- Incident classification not operationalised — the incident response process does not know the DORA thresholds, the initial 4-hour report is only a theoretical capability.
- Resilience testing programme too narrow — testing focuses on penetration tests of individual applications, without the breadth DORA requires (scenario analyses, open source component tests, performance tests).
- Exit strategies are mere boilerplate — no migration estimate, no transition period, no tested data portability.
- Management body not actively involved — the ICT risk framework was formally approved, but the annual review is cosmetic.
- TLPT preparation started too late — choosing threat intelligence and red team providers, scope definition and TIBER-EU-compliant execution take more lead time than is often planned.
Sources
- Regulation (EU) 2022/2554 (EUR-Lex) — official EU version in all languages
- DORA page of the EBA — technical standards and guidelines
- DORA page of EIOPA — insurance-specific detail
- DORA page of ESMA — capital markets guidance
- BaFin articles on DORA — national supervisory practice and reporting channels