DORA — Digital Operational Resilience Act for the Financial

Can our ICT infrastructure survive a major cyber incident without disrupting client services — and what happens to us if we cannot prove it to the regulator?

Since 17 January 2025 every EU financial entity must operate a fully documented ICT risk management framework, report major ICT-related incidents to the competent authority and run regular resilience testing — non-compliance triggers administrative penalties and remedial measures under national law, and the CISO or CTO should be leading the gap assessment now.

Short Answer

DORA establishes uniform requirements for the security of network and information systems across all financial entities in the Union [Art. 1(1)]. The Regulation mandates an ICT risk management framework approved by the management body [Art. 5(2), Art. 6], a harmonised incident reporting regime with initial notification, intermediate and final reports to the competent authority [Art. 19(4)], a digital operational resilience testing programme including threat-led penetration testing (TLPT) for significant entities [Art. 24, Art. 26], and a structured approach to ICT third-party risk with mandatory contractual clauses and a register of information on all ICT outsourcing arrangements [Art. 28, Art. 30].

Who is affected

Twenty types of financial entities are in scope, including credit institutions, payment institutions, investment firms, insurance and reinsurance undertakings, central counterparties, trading venues, central securities depositories, crypto-asset service providers, crowdfunding service providers, managers of alternative investment funds, management companies, credit rating agencies and administrators of critical benchmarks [Art. 2(1)]. Microenterprises enjoy a simplified ICT risk management framework and are exempt from TLPT [Art. 16, Recital 43]. ICT third-party service providers that are designated as critical are subject to the Lead Overseer's direct oversight powers [Art. 31, Art. 35].

Deadline

Fully applicable since 17 January 2025 [Art. 64]. Ongoing obligations include: management body review and approval of the ICT risk management framework at least once a year [Art. 6(5)]; reporting of major ICT-related incidents within the time limits set by the ESA regulatory technical standards (initial notification, intermediate report when status changes, final report after root-cause analysis) [Art. 19(4), Art. 20]; and execution of TLPT at least every three years for identified financial entities [Art. 26(1)].

Risk

Member States must lay down administrative penalties and remedial measures that are effective, proportionate and dissuasive [Art. 50(3)]. Competent authorities can order cessation of non-compliant conduct, require remedial action, impose pecuniary measures and issue public notices identifying the breaching entity [Art. 50(4)]. For critical ICT third-party service providers, the Lead Overseer may impose periodic penalty payments of up to 1% of average daily worldwide turnover per day for up to six months [Art. 35(6), Art. 35(8)]. Member States may also impose criminal penalties [Art. 52].

Proof

Legal status

• In force
• as of 2026-04-17
• Original version of 14.12.2022

Primary sources

• EUR-Lex — Full text of the DORA Regulation
• European Banking Authority (EBA) — European Banking Authority — DORA oversight
• ENISA — Publications — Technical guidance on ICT resilience

What to do now

Legal / DPO

•Verify that the management body has formally approved the ICT risk management framework including the digital operational resilience strategy, and that it reviews the framework at least once a year — the management body bears ultimate responsibility and personal liability for non-compliance [Art. 5(2), Art. 5(4)].
•Review every contractual arrangement with ICT third-party service providers supporting critical or important functions and ensure the mandatory clauses are included: service level descriptions, data location, audit and access rights, exit strategies and termination rights [Art. 28(2), Art. 30].
•Maintain a complete register of information on all contractual arrangements with ICT third-party service providers, distinguishing contracts supporting critical or important functions from others, and be prepared to submit it to the competent authority on request [Art. 28(3)].

Compliance

•Implement a major ICT-related incident reporting process aligned with ESA technical standards: initial notification, intermediate report upon status change and final report after root-cause analysis — and assign clear ownership for each reporting step [Art. 17, Art. 19(4)].
•Establish a digital operational resilience testing programme proportionate to size and risk profile, including at minimum vulnerability assessments, open-source analysis, network security assessments and scenario-based tests at least annually [Art. 24, Art. 25].
•Conduct and document an ICT concentration risk assessment across all third-party dependencies, including sub-outsourcing chains, to identify single points of failure and substitutability gaps [Art. 29].

IT / Security

•Deploy a multi-layered ICT detection framework with automated alert mechanisms and multiple control layers to identify anomalous activities and ICT-related incidents in real time [Art. 10(1), Art. 10(2)].
•Build and test ICT business continuity and disaster recovery plans that include recovery time and recovery point objectives for critical functions, with backup policies ensuring data restorability and secure resumption of operations [Art. 11, Art. 12].
•Prepare for threat-led penetration testing (TLPT) if the entity is identified by the competent authority: scope at least one critical or important function, use qualified external testers for threat intelligence, and run TLPT at least every three years [Art. 26, Art. 27].

Product / Engineering

•Embed ICT risk considerations into the change management process for all ICT systems supporting financial services — every change must be recorded, tested, approved and subject to rollback procedures [Art. 9(4)(e)].
•Ensure that ICT systems supporting client-facing financial products meet the protection and prevention requirements: access management policies, network security, encryption of data in transit and at rest, and patch management [Art. 9(3), Art. 9(4)].
•Design ICT-dependent financial products and services with consideration for service continuity expectations, so that recovery time objectives are aligned with the potential impact on market efficiency and client obligations [Art. 11(6)].

Key Terms

Digital operational resilience: The ability of a financial entity to build, assure and review its operational integrity and reliability by ensuring, directly or indirectly through the use of ICT third-party service providers, the full range of ICT-related capabilities needed to address the security of network and information systems [Art. 3(1)].
ICT risk: Any reasonably identifiable circumstance in relation to the use of network and information systems which, if materialised, may compromise the security of the network and information systems, of any technology-dependent tool or process, of operations and processes, or of the provision of services, thereby adversely affecting the integrity or availability of data, software or any other component of ICT services and infrastructures, or causing a breach of confidentiality or damage to physical ICT infrastructure [Art. 3(5)].
ICT-related incident: A single event or a series of linked events unplanned by the financial entity that compromises the security of the network and information systems, and has an adverse impact on the availability, authenticity, integrity or confidentiality of data, or on the services provided by the financial entity [Art. 3(8)].
Critical ICT third-party service provider: An ICT third-party service provider designated as critical by the ESAs through the Joint Committee, based on criteria including the systemic impact a failure or operational disruption of the provider could have on financial entities it serves [Art. 31].
Threat-led penetration testing (TLPT): A framework for mimicking the tactics, techniques and procedures of real-life threat actors, designed to provide a controlled, bespoke, intelligence-led test of the financial entity's critical live production systems, based on the TIBER-EU framework [Art. 3(17), Art. 26].
ICT third-party risk: An ICT risk that may arise for a financial entity in relation to its use of ICT services provided by ICT third-party service providers or by subcontractors of the latter, including through outsourcing arrangements [Art. 3(18)].
Lead Overseer: The European Supervisory Authority (EBA, ESMA or EIOPA) appointed to conduct the oversight of a critical ICT third-party service provider, with powers to request information, conduct investigations and on-site inspections, and impose periodic penalty payments [Art. 31(1)(b), Art. 35].
Critical or important function: A function the disruption of which would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or whose discontinued, defective or failed performance would materially impair the continuing compliance of a financial entity with its authorisation conditions and obligations [Art. 3(22)].

Frequently Asked Questions

Which entities does DORA apply to?

DORA applies to 20 types of financial entities including credit institutions, payment institutions, investment firms, insurance and reinsurance undertakings, central counterparties, trading venues, central securities depositories, crypto-asset service providers, credit rating agencies, managers of alternative investment funds, management companies and crowdfunding service providers [Art. 2(1)]. It also establishes an oversight framework for critical ICT third-party service providers [Art. 31].

How does DORA relate to NIS2?

DORA constitutes lex specialis with regard to the NIS2 Directive (Directive (EU) 2022/2555) for financial entities [Art. 1(2), Recital 16]. Financial entities in scope of DORA follow the DORA requirements rather than NIS2 for ICT risk management and incident reporting, but the two frameworks are designed to be complementary and competent authorities cooperate with NIS2 CSIRTs [Recital 18].

What must be reported as a major ICT-related incident?

An ICT-related incident is classified as major based on six criteria: number of affected clients or counterparts, duration and service downtime, geographical spread, data losses (availability, authenticity, integrity or confidentiality), criticality of affected services, and economic impact [Art. 18(1)]. The ESAs have specified materiality thresholds via regulatory technical standards [Art. 18(3)].

What is the incident reporting timeline under DORA?

Financial entities must submit an initial notification, an intermediate report when the status of the incident changes significantly or handling evolves based on new information, and a final report once root-cause analysis is completed — regardless of whether mitigation is complete [Art. 19(4)]. Exact time limits are set by the ESA regulatory technical standards [Art. 20].

What is threat-led penetration testing (TLPT) and who must perform it?

TLPT is advanced testing that simulates the tactics, techniques and procedures of real threat actors against an entity's critical live production systems. Only financial entities identified by competent authorities — typically large, systemic and ICT-mature entities — must perform TLPT at least every three years [Art. 26(1)]. Testers must be qualified and independent, and threat intelligence providers must always be external [Art. 27, Recital 61].

What contractual requirements does DORA impose on ICT outsourcing?

Contracts with ICT third-party service providers must include: full service level descriptions, data processing and storage locations, provisions on availability and integrity, access and audit rights for the financial entity and its supervisors, termination rights and adequate transition periods, and the provider's obligation to cooperate during incidents [Art. 30]. For critical or important functions, additional requirements apply including exit strategies and data portability guarantees [Art. 28(8)].

Are microenterprises subject to all DORA requirements?

No. Microenterprises benefit from a simplified ICT risk management framework [Art. 16] and are exempt from several requirements including: establishing a three-lines-of-defence model, submitting the ICT risk management framework to internal audit, conducting TLPT, and performing advanced ICT concentration risk assessments [Recital 43]. However, they must still comply with incident reporting and basic ICT risk management obligations.

Assessment Factors & Checklist

Premium

Start 7-day free trial

Questions for Your Lawyer

Premium

Start 7-day free trial

Conclusion & Summary

Premium

Start 7-day free trial

Detailed analysis with source links.

Schalten Sie die KI-Analyse frei — mit markierten Fundstellen und direkten Links zu EUR-Lex. 7 Tage kostenlos testen.

Start 7-day free trial →

Keine Kreditkarte heute. Kündigung jederzeit.