Is Your Organisation Ready for DORA? What Financial Entities Need to Know

What Is DORA?

The EU Digital Operational Resilience Act (Regulation (EU) 2022/2554, known as DORA) establishes uniform requirements for the security of network and information systems across the EU financial sector. Its core purpose is to ensure that banks, insurers, investment firms, and other financial entities can withstand, respond to, and recover from all types of ICT-related disruptions and threats.

Before DORA, different EU member states had different rules around ICT risk in financial services — creating inconsistency, regulatory arbitrage, and gaps in oversight. DORA harmonises these requirements across all EU member states and all major financial entity types, creating a single regulatory framework for digital operational resilience in the financial sector.

DORA also, for the first time, extends direct regulatory obligations to certain ICT third-party service providers — the cloud providers, software vendors, and data centres that underpin modern financial services infrastructure.

Who Does DORA Apply To?

DORA has a broad scope. Article 2 lists over 20 categories of financial entity within scope, as well as provisions for ICT third-party service providers. At a practical level, if your organisation operates in the EU financial market or provides critical technology services to those that do, DORA almost certainly applies.

DORA does include a proportionality principle — microenterprises (fewer than 10 employees and under €2 million turnover) have simplified obligations in some areas. However, proportionality does not exempt any in-scope entity from DORA entirely. Core requirements apply to all.

The DORA Timeline

• January 2023

  DORA enters into force

  The regulation is published and enters into force, with a two-year implementation window for financial entities to build compliance programmes.

• 2023–2024

  Regulatory Technical Standards developed

  The European Supervisory Authorities (EBA, EIOPA, ESMA) develop binding Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) specifying detailed requirements for ICT risk management, incident classification, resilience testing, and third-party risk.

• 17 January 2025

  Full application — DORA is now enforced

  All DORA requirements became fully applicable. Competent authorities in each EU member state are actively supervising financial entities. Non-compliance is enforceable now.

• Ongoing

  Critical ICT TPSP designations

  The ESAs are in the process of designating critical ICT third-party service providers under Article 31. Once designated, these providers come under direct EU Oversight Framework supervision.

The Five Pillars of DORA

DORA is structured around five pillars, each addressing a distinct aspect of digital operational resilience. Together they form a comprehensive framework spanning governance, incident management, testing, supply chain risk, and information sharing.

Pillar 1: ICT Risk Management in Detail

DORA Article 5 places ultimate responsibility for ICT risk with the management body — the board. This cannot be delegated away. Board members must maintain sufficient understanding of ICT risks, approve the ICT risk management framework, endorse the digital operational resilience strategy, and regularly review ICT risk reporting.

Under Article 6, the ICT risk management framework itself must be comprehensive, well-documented, and reviewed at least annually — and after any major ICT incident. It must cover strategies, policies, procedures, IT protocols, and tools to protect all ICT assets and data.

The framework must address the full risk lifecycle: identification of ICT assets and their dependencies, protection through technical controls, detection of anomalous activity, and response and recovery capability including defined recovery time objectives (RTO) and recovery point objectives (RPO) for critical functions.

Pillar 2: ICT Incident Reporting — The Timelines That Matter

DORA establishes a strict reporting regime for major ICT-related incidents. The classification of what constitutes a "major" incident is defined through RTS, covering criteria such as the number of clients affected, transaction volumes impacted, geographic spread, and duration of the incident.

Once a major incident is classified, reporting obligations to the relevant competent authority are triggered:

• Initial notification — within 4 hours of classification as major (and no later than 24 hours from becoming aware)
• Intermediate report — within 72 hours of the initial notification
• Final report — within one month of the intermediate report, including root cause analysis and lessons learned

These timelines are tight. Financial entities that do not have mature incident detection, classification, and escalation processes will struggle to meet them. Competent authorities will be examining incident response capability closely.

Pillar 3: Digital Operational Resilience Testing

DORA requires a structured testing programme covering all ICT systems and applications supporting critical or important functions. At a minimum this includes vulnerability assessments, open-source analyses, network security assessments, gap analyses, and scenario-based testing.

For significant financial entities — typically large banks, insurers, and investment firms — DORA also mandates advanced Threat-Led Penetration Testing (TLPT) at least every three years. TLPT is based on the TIBER-EU framework: it involves real threat intelligence and simulates actual attacker tactics, techniques, and procedures against live production systems. The scope must cover at minimum the financial entity's most critical functions and supporting ICT infrastructure.

Pillar 4: ICT Third-Party Risk — The Article 30 Contract Requirements

One of DORA's most operationally demanding pillars is third-party risk management. Article 30 sets out mandatory contractual provisions that must be included in all agreements with ICT third-party service providers supporting critical or important functions. These include:

• Full descriptions of services and service levels with quantitative and qualitative performance targets
• Notice periods and reporting obligations when ICT incidents may affect the financial entity
• Rights of access, inspection, and audit for the financial entity and its competent authority
• Business continuity requirements and participation in disaster recovery testing
• Exit provisions and transition assistance to ensure operational continuity on termination
• Sub-outsourcing rules — the financial entity must approve or be notified of material sub-outsourcing arrangements
• Data location and processing country disclosure
• Cooperation with competent authorities on request

Financial entities will need to review all existing ICT contracts for critical arrangements and remediate gaps. For many organisations with legacy supplier agreements, this is a significant undertaking.

What Financial Entities Should Be Doing Right Now

Given DORA is already in force, the question is not whether to comply but how quickly gaps can be closed. A practical prioritisation for organisations behind the curve:

1. Conduct a formal gap assessment

Map your current ICT risk management, incident response, testing, and third-party risk practices against DORA's five pillars and the supporting RTS. Identify where you are compliant, partially compliant, and non-compliant. Without this baseline you cannot effectively prioritise remediation effort.

2. Confirm management body accountability

DORA's board accountability requirements are non-negotiable. Boards need to formally approve the ICT risk management framework and digital operational resilience strategy, and receive regular ICT risk reporting. If this governance structure is not yet in place, it should be the first priority — it underpins everything else.

3. Review and update your ICT incident classification and reporting process

The 4-hour initial notification requirement for major incidents is one of the most operationally challenging aspects of DORA. Review your incident detection, escalation, and classification procedures. Ensure your team knows how to apply the major incident criteria under the RTS, and that escalation paths to competent authorities are documented and tested.

4. Audit your critical ICT supplier contracts

Identify all ICT third-party arrangements supporting critical or important functions, and systematically review them against the Article 30 mandatory contractual provisions. Prioritise contracts with the highest operational risk if a provider fails or underperforms. Engage suppliers early — remediation of contract gaps requires counterparty cooperation and can take months.

5. Build your resilience testing programme

If you do not have a structured ICT testing programme in place, establish one now. Start with vulnerability assessments and network security reviews of systems supporting critical functions. For entities subject to TLPT, begin engaging with your competent authority on the TIBER-EU framework requirements and timelines.

6. Assess your concentration risk

DORA requires financial entities to monitor and manage concentration risk in their ICT third-party arrangements — particularly where critical functions depend on a single provider. Document your concentration exposures and assess what your exit strategy would be if a critical provider failed or was withdrawn from the market.

Frequently Asked Questions