website.documents.printTip
The DORA Compliance Guide for European Financial Entities
Executive Summary
The Digital Operational Resilience Act (Regulation EU 2022/2554, "DORA") is the EU's harmonised rulebook for digital operational resilience in the financial sector. It entered into force on 17 January 2025 and establishes uniform requirements for ICT risk management, incident reporting, resilience testing and third-party risk across more than 22,000 financial entities and their critical ICT service providers.
Key takeaways
- DORA is the lex specialis for financial-sector cybersecurity. Where DORA and NIS2 overlap on the same entity, DORA prevails.
- Five pillars: ICT risk management, ICT-related incident management, digital operational resilience testing, ICT third-party risk and information-sharing arrangements.
- Major incident reporting follows a 4-hour internal classification, 24-hour initial notification, 72-hour intermediate report and 1-month final report.
- Significant entities are required to undergo Threat-Led Penetration Testing (TLPT) at least every three years, following the TIBER-EU framework.
- Critical ICT third-party providers can be designated by the European Supervisory Authorities and face direct EU oversight, with fines of up to 1% of worldwide daily turnover.
Who should read this
- CISOs, COOs and Heads of Resilience at banks, insurers, investment firms, crypto-asset providers and trading venues.
- Compliance officers and DPOs mapping DORA against existing NIS2, EBA, ESMA, EIOPA and national supervisory expectations.
- Procurement teams negotiating ICT contracts under the new Article 30 contractual obligations.
- ICT third-party providers concerned about Critical TPP designation and subsequent direct EU oversight.
What Is DORA?
DORA harmonises and replaces a fragmented landscape of EBA, ESMA and EIOPA guidelines on ICT risk for the EU financial sector. Before DORA, each sub-sector (banking, securities, insurance) had its own overlapping rules — with DORA, financial entities operate under a single, directly applicable regulation across all 27 Member States.
The regulation entered into force on 17 January 2025, after a two-year transition period. The European Supervisory Authorities (EBA, ESMA, EIOPA) have published detailed Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) covering each pillar in depth.
DORA explicitly recognises that resilience cannot be built around the perimeter of the financial entity alone. It pulls ICT third-party providers into scope through contractual flow-down requirements and establishes a parallel oversight regime for "critical" ICT service providers with EU-wide systemic relevance.
14 Dec 2022 — DORA published in the Official Journal · 16 Jan 2023 — DORA enters into force · 17 Jan 2025 — DORA becomes directly applicable across the EU · 2025-2026 — RTS and ITS published by ESAs · Ongoing — Critical ICT TPP designations by ESAs.
Who DORA Applies To
DORA applies to a much wider population than the original sectoral rules. Article 2(1) lists 20 categories of financial entities. Critical ICT third-party providers, designated by the ESAs, fall under direct EU supervision regardless of size.
The exact entity counts vary by source and over time. The figures above are illustrative orders of magnitude based on European supervisory reports. The total in-scope population is regularly cited at around 22,000 entities, with the largest concentrations in credit institutions and investment firms.
The Five Pillars of DORA
DORA organises its substantive obligations into five pillars. Each is the subject of one or more dedicated chapters in the regulation, plus detailed technical standards published by the European Supervisory Authorities.
Articles 5–15. A comprehensive ICT risk management framework approved and overseen by the management body, covering identification, protection, detection, response and recovery.
Articles 17–23. Detection, classification, internal escalation and external notification of ICT-related incidents using harmonised criteria and timelines.
Articles 24–27. A risk-based testing programme covering vulnerability assessments through to advanced threat-led penetration tests every three years for significant entities.
Articles 28–44. Pre-contractual due diligence, register of information, mandatory contractual provisions, monitoring and exit strategies for all ICT outsourcing.
Article 45. Voluntary participation in trusted information-sharing arrangements on cyber threats, indicators of compromise, tactics, techniques and procedures.
Pillar 1: ICT Risk Management
The risk management pillar requires financial entities to operate a documented, board-approved ICT risk management framework that covers the full lifecycle of ICT risk, from identification through to lessons learned. The management body bears the ultimate responsibility — Article 5 explicitly assigns "full and ultimate accountability" to senior management.
Board-approved ICT risk strategy with defined risk tolerance and appetite, periodic review and clear lines of responsibility.
Comprehensive inventory of all ICT assets, business processes and dependencies, classified by criticality and information sensitivity.
Information security policies, identity and access management, cryptographic controls, network segmentation and physical security.
Continuous monitoring of network and information systems, with defined alerting and triage procedures for anomalous activity.
Documented response procedures, business continuity plans, ICT response and recovery plans, with regular testing.
Backup policies aligned to recovery time and point objectives, with documented restoration procedures and integrity verification.
Post-incident reviews, threat intelligence ingestion, periodic reassessment and continuous improvement of the framework.
Article 5 makes the management body — not the CISO — accountable for approving, supervising and reviewing the ICT risk management framework. Members must have sufficient ICT knowledge to challenge proposals and oversee execution.
Pillar 2: Incident Reporting Timeline
DORA introduces harmonised incident classification criteria and a unified reporting timeline that replaces the patchwork of national and sector-specific notification obligations. The clock starts the moment an entity becomes aware of a major ICT-related incident, defined using ESA-published technical standards.
The financial entity must classify the incident against the harmonised severity criteria as soon as practicable after detection.
Notify the competent authority of a major incident with a high-level description, scope and initial impact assessment.
Provide an updated assessment with current status, impact, root cause hypothesis and the actions taken so far.
Submit a comprehensive root-cause analysis, lessons learned, remediation actions and updates to the risk management framework.
DORA harmonises reporting across banks, insurers, investment firms and trading venues into a single timeline. This is a major simplification compared with the previous patchwork of EBA, ESMA and EIOPA guidelines, but the threshold for "major" incidents is set deliberately broad.
Pillar 3: Resilience Testing
DORA requires a risk-based programme of digital operational resilience testing on at least an annual basis, covering all critical ICT systems. For entities deemed significant by the supervisor, the programme must culminate in a Threat-Led Penetration Test (TLPT) every three years, conducted in line with the TIBER-EU framework.
Automated scanning of network, host and application vulnerabilities, with remediation prioritised by exposure.
External reconnaissance of the entity's exposed attack surface, including subsidiaries and supply-chain components.
Architecture reviews, segmentation tests and configuration audits of critical network components.
Static and dynamic analysis of in-house and outsourced application code, including dependencies.
Goal-oriented manual testing of application and infrastructure security under realistic adversarial assumptions.
Triennial advanced testing for significant entities, scoped against actual threat actors targeting the financial sector.
Tabletop and live exercises covering business-disruption scenarios, third-party failures and crisis communication.
TLPT is the apex of the testing programme. It must be conducted by independent external testers, scoped against current threat intelligence, and reported to the supervisor. The TIBER-EU framework provides the operating model, governance and red-team standards.
Pillar 4: ICT Third-Party Risk Management
Article 28 onwards introduces the most demanding ICT third-party risk regime in EU financial regulation to date. Financial entities must apply a structured lifecycle to every ICT outsourcing arrangement, from pre-contractual due diligence through to documented exit strategies. Critical ICT TPPs face direct EU supervision under a parallel oversight framework.
Documented assessment of supplier security posture, financial stability, jurisdiction, sub-outsourcing and concentration risk before contract signature.
A complete, structured register of all ICT contracts in a format prescribed by the ESAs, available to supervisors on demand.
Article 30 mandates a defined list of clauses including audit rights, location of data, cooperation in incidents, exit strategies and sub-outsourcing controls.
Ongoing oversight of supplier performance, security posture and adherence to contractual SLAs, including incident notification arrangements.
Identification and limitation of single-vendor dependencies, especially for critical or important functions.
Tested and current exit plans for each supplier of a critical or important function, including data extraction and provider transition.
Article 31 introduces the Critical ICT Third-Party Provider designation. Designated providers are subject to direct oversight by the lead EU supervisor and must comply with on-site inspections, mandatory recommendations and significant fines.
Penalties & Enforcement
DORA establishes a two-track penalty regime. Financial entities are sanctioned by their national competent authorities under existing national law and the maximum amounts vary by Member State. Critical ICT TPPs face direct EU-level fines.
Personal accountability of management bodies
Article 5 places ultimate responsibility on the members of the management body. They must approve the ICT risk management framework, approve the digital operational resilience strategy, oversee implementation, and possess sufficient ICT knowledge to fulfil these duties. Failure to comply can result in personal sanctions under national law and direct enforcement action.
DORA vs NIS2 — How They Interact
DORA is the lex specialis (specialised law) for the financial sector. Where DORA and NIS2 would both apply to the same financial entity, DORA prevails. However, financial groups frequently include non-financial subsidiaries that remain under NIS2, and the two regimes overlap heavily on substance — making a unified compliance programme essential.
| Aspect | DORA | NIS2 |
|---|---|---|
| Sector focus | Financial services exclusively | 18 critical sectors including digital infrastructure |
| Legal instrument | Directly applicable Regulation | Directive (national transposition required) |
| Initial notification | Within 24 hours | Within 24 hours |
| Testing obligation | TLPT every 3 years (significant entities) | Periodic security testing (no fixed cadence) |
| Third-party regime | Detailed Article 30 contractual list | High-level supply chain security duty |
| Direct EU oversight | Yes — for Critical ICT TPPs | No (national supervisors only) |
| Penalty model | National + direct EU fines for TPPs | National authorities only |
For entities subject to both, the practical answer is to design a single ICT risk programme that satisfies the stricter of the two on each topic. DORA is more prescriptive on contracts, testing and incident classification; NIS2 has wider sectoral applicability and stricter penalties for the financial group as a whole.
Implementation Roadmap
A phased approach to DORA compliance is more sustainable than a single big-bang programme. Most in-scope entities are already two or three years into the journey. The phases below describe what should be in place today, what should be operational by end-2026, and what continuous practice looks like beyond that.
Phase 1 — Scope and gap assessment
- Confirm DORA scope across all legal entities and group subsidiaries.
- Map current ICT risk management framework against the five pillars.
- Inventory all ICT third-party arrangements and identify critical/important functions.
- Identify TLPT applicability and prepare for triennial testing.
Phase 2 — Framework and contracts
- Document the ICT risk management framework, approved by the management body.
- Renegotiate contracts with critical ICT providers to add Article 30 clauses.
- Build the register of information in the ESA-prescribed format.
- Define documented exit strategies for each critical or important supplier.
Phase 3 — Testing and incident operations
- Operationalise the harmonised incident classification and the 4/24/72h/1-month timeline.
- Stand up a continuous testing programme covering all critical systems.
- Conduct the first TLPT cycle for entities designated as significant.
- Validate concentration-risk metrics and document mitigation plans.
Phase 4 — Continuous improvement
- Annual board review of the ICT risk strategy and risk tolerance.
- Quarterly third-party performance and concentration reviews.
- Continuous threat intelligence ingestion and information sharing.
- Lessons learned from every major incident fed back into the framework.
How Orizon Supports DORA Compliance
Orizon's platform was designed around the same control catalogue DORA harmonises across the EU financial sector. Each Orizon product maps to one or more pillars and contributes structured, auditable evidence that satisfies supervisor expectations.
Next steps
- Book a DORA scoping assessment with our compliance team to validate in-scope status and current gaps.
- Request a gap analysis against the five pillars based on your existing controls and contracts.
- Start a free RECON scan to establish a baseline of your external attack surface — including critical suppliers.
Contact: [email protected] · orizon.one/solutions/nis2-compliance · EU headquarters, sovereign infrastructure.