The Digital Operational Resilience Act explained: What you need to know

Key Takeaway: DORA (Regulation (EU) 2022/2554) became fully applicable on 17 January 2025, with the first registers of information collected by the ESAs on 30 April 2025. Industry readiness lags: only 25% of financial entities feel compliant on ICT risk management, and just 8% have achieved full compliance on resilience testing and third-party risk.

The Digital Operational Resilience Act (DORA) — officially Regulation (EU) 2022/2554 — became fully applicable to EU financial entities on 17 January 2025, replacing a patchwork of national ICT rules with a single binding framework. For audit, risk, and GRC practitioners, the focus has shifted from gap analysis to operationalizing the register of information, threat-led penetration testing (TLPT), and Article 30 third-party contracts under active ESAs supervision.

What DORA standardizes across the EU

DORA is an EU regulation that sets uniform ICT risk management, incident reporting, resilience testing, and third-party oversight requirements for financial entities and their critical ICT providers. DORA ensures that all financial entities can withstand, respond to, and recover from all types of ICT-related disruptions and threats. It is enforced by the European Supervisory Authorities (ESAs) — the EBA, EIOPA, and ESMA — through binding Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS).

The DORA regulation entered into application on 17 January 2025. The ESAs collected the first registers of information from competent authorities on 30 April 2025, marking the transition from self-assessment to active supervisory scrutiny.

What is the Digital Operational Resilience Act (DORA)?

DORA is a European Union regulation that creates a binding, comprehensive ICT risk management framework for the EU financial sector. It mandates incident reporting against fixed thresholds, regular ICT testing (including advanced TLPT for significant entities), and direct oversight of critical third-party providers — replacing fragmented national rules with one harmonized regime.

DORA establishes Regulatory Technical Standards (RTS) for managing ICT risks. Financial entities must implement risk management frameworks, assess and mitigate ICT risks on an ongoing basis, and report significant ICT-related incidents using the standard templates set out in Commission Implementing Regulation (EU) 2025/302.

The regulation also mandates routine testing of ICT systems, including threat-led penetration testing for critical systems. It enforces strict supervision of critical ICT third-party service providers to ensure compliance. DORA is enforced through the European Supervisory Authorities (ESAs) — the European Banking Authority (EBA), the European Insurance and Occupational Pensions Authority (EIOPA), and the European Securities and Markets Authority (ESMA) — which develop the technical standards and guidelines that drive consistent application across EU member states.

Key DORA milestones practitioners should track

The regulatory calendar has solidified, with the core technical standards now in force:

• December 2022 — DORA (Regulation (EU) 2022/2554) adopted.
• 2 December 2024 — Implementing Regulation (EU) 2024/2956 published, setting templates for the register of information.
• 17 January 2025 — DORA enters into application across the EU.
• 20 February 2025 — Delegated Regulation (EU) 2025/301 (incident reporting content and timelines) and Implementing Regulation (EU) 2025/302 (incident reporting templates) published in the OJ.
• 24 March 2025 — Delegated Regulation (EU) 2025/532 adopted, covering ICT subcontracting of critical or important functions.
• 30 April 2025 — ESAs collect the first registers of information from competent authorities.

Why the EU needed DORA

Before DORA, ICT risk management practices varied widely across EU member states, producing a disjointed regulatory environment. Frameworks like the NIS2 Directive addressed a broader spectrum of sectors but did not specifically target the financial sector or carry the enforcement authority of regulation. This inconsistency drove the need for a unified oversight framework.

DORA aims to harmonize ICT risk management regulations that previously varied across EU member states. It requires financial entities to assess and mitigate ICT risks through formal frameworks, report incidents on fixed timelines, run advanced threat-led penetration testing on critical systems, and apply rigorous oversight to third-party ICT providers. As lex specialis for the financial sector, DORA's ICT requirements override the more general NIS2 directive for entities in scope of both, while GDPR continues to apply independently to personal data breaches.

What DORA covers

DORA covers several key areas to ensure the financial sector can manage ICT risks. Financial entities must implement ICT risk management frameworks, regularly assess and mitigate risks, and apply appropriate cybersecurity measures. Procedures must be established to identify and report major ICT-related incidents to competent authorities using standardized templates. ICT systems require regular testing — including advanced threat-led penetration testing for critical systems — to confirm they can withstand and recover from disruptions. Financial entities must also maintain oversight of third-party ICT service providers, including contractual compliance with DORA requirements. Governance measures require clear role definitions and active involvement from senior management and the board in ICT risk management.

DORA also requires information-sharing arrangements on threats and vulnerabilities among financial entities, coordinated with competent authorities. The supervisory framework includes mechanisms for enforcing adherence and addressing non-compliance. The act mandates digital operational resilience testing using scenarios to assess preparedness, with business continuity actions informed by test results.

What are the 5 pillars of DORA?

DORA is structured around five pillars that together fortify the financial sector against digital disruptions:

1. ICT risk management — financial entities establish frameworks for ongoing risk assessment and mitigation.
2. Incident reporting — procedures to identify and report significant ICT-related incidents quickly using standardized formats.
3. Digital operational resilience testing — regular testing of critical ICT systems, including threat-led penetration testing.
4. Third-party risk management — oversight ensuring ICT service providers adhere to DORA standards.
5. Information-sharing arrangements — structured exchange of intelligence on cyber threats among financial entities.

ICT risk management

ICT risk management under DORA is governed by Delegated Regulation (EU) 2024/1774, which specifies the tools, methods, processes, and policies financial entities must implement. The framework requires entities to identify ICT-supported business functions, map dependencies, classify information assets, and continuously assess threats such as cyberattacks, system failures, and supply-chain disruptions.

Risks are assessed for likelihood and severity, and mitigation includes security controls, staff training, and tested response plans. Constant monitoring and review keep controls effective. Detailed cybersecurity risk assessments underpin this work. Direct, non-delegable responsibility for the ICT risk management framework sits with the management body under Article 5 — meaning board members must maintain enough technical literacy to understand and challenge ICT risk posture, not just rubber-stamp it.

ICT-related incident management, classification, and reporting

DORA sets a prescriptive framework for managing, classifying, and reporting ICT-related incidents. Financial entities must operate a documented incident response plan covering roles, communication, containment, and recovery, supported by continuous monitoring and detection tooling.

Incidents must be classified against the criteria in Delegated Regulation (EU) 2025/301 — including clients affected, data losses, duration, geographical spread, and economic impact — and material incidents trigger a sequence of three reports: an initial notification, an intermediate report, and a final report, each with prescribed content and time limits. Reporting uses the standard templates in Implementing Regulation (EU) 2025/302. Practitioners should embed these thresholds directly into SIEM and incident-triage playbooks rather than relying on subjective severity judgments. Where personal data is in scope, parallel GDPR Article 33 reporting still applies.

Digital operational resilience testing

Digital operational resilience testing under DORA requires financial entities to test ICT systems regularly to confirm they can handle and recover from disruptions. This includes baseline vulnerability assessments, scenario-based drills, and — for significant entities — threat-led penetration testing (TLPT) at least every three years against live production systems supporting critical or important functions.

The TLPT RTS (JC 2024-29, July 2024) sets tester criteria and makes purple teaming a mandatory element of every test. Acknowledging market scarcity, the ESAs relaxed tester qualifications from strictly "threat intelligence-led red-team" experience to broader "penetration testing and red teaming" experience. Firms sharing critical ICT providers can also run pooled tests to distribute costs and reduce vendor audit fatigue. According to Deloitte's 2025 DORA Survey, only 8% of financial entities have achieved full compliance on resilience testing and third-party risk — making this the most underdeveloped pillar in practice.

Managing ICT third-party risk

Under DORA, managing ICT third-party risk centers on Article 30, which mandates specific contractual provisions for all ICT services and enhanced provisions for services supporting critical or important functions. Required terms include clear descriptions of services and data processing locations, service levels, data accessibility and recoverability, audit and access rights for the entity and competent authorities, incident reporting obligations, exit strategies, and termination rights.

The ESAs can also designate certain providers — typically large cloud, data, and software vendors with systemic exposure — as Critical ICT Third-Party Providers (CTPPs), subjecting them to direct oversight by a designated Lead Overseer. CTPPs that fail to comply face periodic penalty payments of up to 1% of average daily worldwide turnover, applied daily for up to six months. Delegated Regulation (EU) 2025/532 (adopted 24 March 2025) further specifies what entities must assess before subcontracting ICT services supporting critical functions — so fourth-party risk is now squarely in scope. Practitioners should run an Article 30 contract gap analysis and prioritize remediation for critical-function vendors first.

Information-sharing arrangements

Information-sharing arrangements under DORA encourage financial entities, regulators, and other stakeholders to establish networks for timely exchange of intelligence on significant cyber threats, vulnerabilities, and incidents. Standardized communication protocols and confidentiality safeguards underpin a trusted environment for proactive threat management.

This collective intelligence sharing helps individual entities improve their cybersecurity practices and strengthens the sector's overall ability to withstand digital disruptions. Through coordinated responses to emerging threats, the financial ecosystem moves toward higher operational resilience and consistent regulatory compliance.

Who needs to comply with DORA?

DORA applies to nearly all EU financial entities and their critical ICT providers. In scope are credit institutions (banks), insurance and reinsurance undertakings, investment firms, payment and electronic money institutions, crypto-asset service providers, crowdfunding platforms, central counterparties, trading venues, trade repositories, and other regulated financial services entities. The regulation also applies to ICT third-party service providers — including cloud, data, and IT support vendors — that serve these entities.

DORA also applies extraterritorially in two ways: non-EU financial entities providing services in the EU through a branch or subsidiary fall within scope, and non-EU ICT providers serving EU financial entities must comply with DORA's third-party provisions through contractual flow-down from their EU clients. The Deloitte 2025 DORA Survey reports that 64% of in-scope firms plan to spend €2-5M on compliance, while 17% still cannot quantify costs at all.

Common DORA implementation challenges

DORA implementation has surfaced concrete bottlenecks that GRC practitioners must work through, particularly around resourcing and the complexity of overlapping requirements. According to Deloitte's industry readiness data, updating ICT systems, hardening security, and training staff demand sustained financial and operational investment, which is especially difficult for smaller entities. Incident reporting, third-party risk management, and routine system testing must be integrated into day-to-day operations without disrupting them.

Managing third-party risks under DORA involves strict due diligence and ongoing monitoring — 17% of entities cite this as a top pain point in the Deloitte 2025 survey. For multinational organizations, aligning DORA with other regimes (U.K. CTP, NIS2, GDPR, regional cyber rules) adds further complexity. Building a culture of digital resilience also requires a mindset shift across the organization, which takes time and sustained executive sponsorship.

Board-level engagement under Article 5

DORA Article 5 places direct, non-delegable responsibility for ICT risk management on the management body. The board must define, approve, oversee, and be accountable for the ICT risk management framework — and members must maintain sufficient knowledge to understand and assess ICT risks, making ongoing technical training a regulatory requirement rather than a nice-to-have.

This is a significant shift for boards that historically delegated technology oversight. Board minutes must evidence active discussion of ICT risk appetite, third-party concentration, incident trends, and resilience testing results, because competent authorities can request this documentation during supervisory reviews. Practitioners supporting boards should build standing agenda items and a dedicated ICT risk dashboard into the existing audit and risk committee cycle.

Reporting obligations

Reporting under DORA is data-intensive and time-bound. Financial entities must capture, classify, and submit detailed incident data within the windows set by Delegated Regulation (EU) 2025/301, using the templates in Implementing Regulation (EU) 2025/302. That requires rapid detection and triage capabilities, integrated SIEM and case-management tooling, and disciplined data hygiene across security, IT, and legal teams.

Entities must also balance transparency with data protection — providing enough detail to satisfy supervisors without exposing customer or proprietary information beyond what is required. Separately, the ESAs' Joint Guidelines JC 2024-34 (March 2025) require entities to estimate and report aggregated annual costs and losses caused by major ICT-related incidents, pushing GRC teams toward FAIR-style quantitative risk methods rather than red/amber/green dashboards.

The register of information

The register of information is the operational artifact most financial entities are finding hardest to deliver. Per Deloitte's 2025 DORA Survey, 46% of financial entities cite the register as their most challenging task — primarily because it forces consolidation of fragmented vendor data across legal, procurement, IT, and business units.

The register must follow the standard templates set out in Implementing Regulation (EU) 2024/2956, and every data field must align precisely with the ESAs' schema. The first supervisory collection took place on 30 April 2025, and misaligned submissions risk rejection. Practitioners should treat the register as a continuously maintained asset, not an annual filing, and assign clear data ownership across the three lines.

Penalties for non-compliance

National competent authorities can impose administrative penalties, remedial measures, and — depending on the jurisdiction — criminal sanctions on financial entities that fail to comply with DORA. For Critical ICT Third-Party Providers (CTPPs), the regulation allows the Lead Overseer to impose periodic penalty payments of up to 1% of average daily worldwide turnover, applied daily for up to six months until compliance is achieved.

Beyond fines, entities should expect supervisory escalation as the ESAs aggregate register-of-information data at the European level to identify systemic concentration risk among CTPPs. Reputational and contractual consequences — particularly loss of business with EU financial entities — can outweigh direct financial penalties.

Automating DORA compliance

Automating compliance with DORA can materially reduce the operational burden of register maintenance, incident classification, and resilience testing documentation. By automating risk management processes, organizations can continuously monitor system activities to surface potential threats, then apply mitigation workflows when risks are detected. Automated incident reporting tools can detect anomalies, capture the data fields required by Delegated Regulation (EU) 2025/301, and pre-populate the standard templates ahead of regulator submission.

PwC research indicates that 84% of financial firms believe failure to adopt AI for DORA will have a negative impact, and 49% expect AI to reduce compliance costs by at least 10%. Optro's CrossComply can monitor service providers for DORA conformance and provide real-time performance metrics and compliance checks for third-party risk. Automation works best paired with human oversight for classification edge cases — misclassifying a major incident, or missing a reporting deadline, carries direct supervisory consequences.Optro’s CrossComply can monitor service providers to ensure compliance with DORA standards and provide real-time performance metrics and compliance checks for managing third-party risks. Automation brings consistency and efficiency to these processes and scales effectively as organizational needs grow. Despite these advantages, implementing such systems requires careful integration with existing technologies and ongoing human oversight to handle complex decision-making and manage nuanced risks that technology alone might not fully address.

What is the impact of DORA on U.K. entities?

U.K. firms that interact with EU financial entities or provide ICT services into the EU fall within scope through contractual flow-down, and U.K.-headquartered groups with EU subsidiaries must comply directly through those entities. Although DORA is an EU regulation, its reach into the U.K. financial sector is substantial.

The FCA, PRA, and Bank of England are expected to continue aligning U.K. operational resilience rules with DORA's principles. The U.K. Critical Third Party (CTP) regime already mirrors DORA's CTPP concept, applying direct oversight to systemically important ICT providers. Practitioners at multinational firms should map every EU-touching entity and ensure their global ICT risk framework satisfies the strictest applicable regime — typically DORA.

Frequently asked questions

When did DORA take effect, and what are the key milestones to track?

DORA — Regulation (EU) 2022/2554 — was adopted in December 2022 and became fully applicable on 17 January 2025. Key downstream milestones include Implementing Regulation (EU) 2024/2956 on register templates (2 December 2024), Delegated Regulation (EU) 2025/301 and Implementing Regulation (EU) 2025/302 on incident reporting (20 February 2025), Delegated Regulation (EU) 2025/532 on subcontracting (24 March 2025), and the ESAs' first collection of registers on 30 April 2025.

What are the penalties for non-compliance with DORA?

National competent authorities can impose administrative penalties, remedial measures, and — in some jurisdictions — criminal sanctions on financial entities that fail to comply. Critical ICT Third-Party Providers (CTPPs) face periodic penalty payments of up to 1% of average daily worldwide turnover, applied daily for up to six months until compliance is achieved. Supervisory escalation is increasingly likely as the ESAs aggregate register data to scrutinize systemic concentration risk.

What are the incident reporting timelines and thresholds under DORA?

Financial entities must submit three sequential reports for every major ICT-related incident: an initial notification, an intermediate report, and a final report, with content and timing set by Commission Delegated Regulation (EU) 2025/301. Reporting uses the standard templates in Implementing Regulation (EU) 2025/302. Classification thresholds are based on clients affected, data losses, duration, geographical spread, and economic impact — these criteria should be embedded directly into incident triage playbooks.

What is the DORA register of information and why is it so challenging?

The register of information is a structured inventory of all contractual arrangements with ICT third-party service providers, maintained on the standard templates in Implementing Regulation (EU) 2024/2956 and submitted to competent authorities. Deloitte's 2025 DORA Survey found 46% of financial entities cite the register as their most challenging task, primarily because it requires consolidating fragmented vendor data across legal, procurement, IT, and business teams. Misaligned submissions risk rejection, so field-level alignment with the ESAs' schema is critical.

How does threat-led penetration testing (TLPT) work, and who is in scope?

TLPT is mandatory for significant financial entities identified by competent authorities based on size, risk profile, and systemic importance, conducted at least every three years against live production systems supporting critical or important functions. The final RTS (JC 2024-29, July 2024) sets tester criteria and makes purple teaming a mandatory element. Firms sharing critical ICT providers can also run pooled tests to distribute costs and reduce vendor audit fatigue.

What are Critical ICT Third-Party Providers (CTPPs) and how does the Lead Overseer regime work?

Under DORA, the ESAs can designate certain ICT providers — typically large cloud, data, and software vendors with systemic exposure across EU finance — as Critical ICT Third-Party Providers (CTPPs), subject to direct oversight by a designated Lead Overseer. The Lead Overseer can investigate, request information, issue recommendations, and impose periodic penalty payments of up to 1% of average daily worldwide turnover. Financial entities should identify which of their critical vendors are likely CTPP candidates and confirm contracts contain the access, audit, and termination rights required by Article 30.

What contractual provisions must DORA-compliant ICT third-party agreements include?

Article 30 of DORA mandates specific contractual provisions for all ICT services, with enhanced requirements for services supporting critical or important functions. Required terms include service descriptions and data processing locations, SLAs, data accessibility and recoverability, audit and access rights for the entity and competent authorities, incident reporting obligations, exit strategies, and termination rights. Delegated Regulation (EU) 2025/532 further specifies the assessment elements for subcontracting, placing fourth-party risk firmly in scope.

About the authors

Saulo is a Partner Development Manager for EMEA at Optro, bringing over 18 years of experience in guiding organizations to implement leading GRC and Internal Audit practices. He specializes in helping businesses across various industries meet critical regulatory standards, including IFRC, SOX, and the UK Corporate Governance Code. Previously, Saulo served as the Head of Security and Information Governance at National Grid.