What Is the Digital Operational Resilience Act (DORA) and Who Must Comply

Cyber threats don't stop at borders—and neither do their consequences. A single disruption at a major bank or cloud provider can cascade across the entire financial sector in hours. That's exactly the problem the Digital Operational Resilience Act (DORA) was built to solve.

For compliance officers, security leaders, and technology providers serving European Union (EU) financial entities, DORA sets enforceable operational resilience requirements. The regulation raises the bar for governance, incident reporting, resilience testing, and Information and Communication Technology (ICT) third-party oversight. Teams need a repeatable way to demonstrate readiness across those obligations—and understanding what DORA requires is the first step.

This article breaks down the regulation: what it is, who must comply, what the five pillars require, how enforcement works, and what steps organizations need to take right now.

What Is the Digital Operational Resilience Act

The Digital Operational Resilience Act (DORA) is an EU regulation—formally Regulation (EU) 2022/2554—that requires financial entities to strengthen their digital resilience against cyber-attacks and ICT disruptions. It creates a harmonized, legally binding framework across the EU financial sector, reducing fragmentation across prior national and sectoral ICT risk requirements.

DORA entered into application on January 17, 2025.

Before DORA, EU member states each had their own rules around ICT risk for financial entities. This inconsistency created gaps—and gaps create systemic risk. DORA closes those gaps by establishing a single, harmonized standard every covered entity must meet.

Why DORA Matters for Financial Sector Cybersecurity

Financial services run on technology. Trading platforms, payment rails, insurance systems, and core banking infrastructure all depend on ICT—and on the third-party vendors that support them. When that technology fails or gets compromised, the effects ripple fast—IBM's 2025 Cost of a Data Breach Report puts the average financial services breach at $5.56 million.

That interconnectedness is precisely why DORA exists. A breach at a critical cloud provider doesn't just affect one institution; it can freeze operations across dozens. DORA treats this systemic risk as a shared problem requiring a shared solution.

A few factors drove the regulation's creation:

• Growing reliance on third-party ICT providers, with financial entities increasingly outsourcing critical functions to cloud platforms and managed service providers. Verizon's 2025 DBIR found third-party involvement in breaches doubled to 30% year-over-year

• Fragmented national rules that let risk fall through jurisdictional cracks

• Systemic exposure from deeply interconnected financial systems, where one failure can destabilize many

• Management accountability—DORA holds boards and senior leadership directly responsible for ICT risk governance, not just IT departments

DORA can affect organizations outside the EU when they provide ICT services to in-scope EU financial entities. In practice, many non-EU ICT providers will encounter DORA requirements indirectly through customer due diligence, contractual provisions, and oversight expectations, while designated critical ICT third-party providers (CTPPs) may be subject to direct ESA oversight. That's a significant expansion of scope that many non-EU technology vendors are still catching up to.

Who Must Comply with EU DORA Regulation

DORA's scope extends well beyond traditional banks. It covers more than 20 types of financial entities operating in the EU—and critically, it reaches the technology providers that serve them.

Financial Entities Under DORA Scope

The regulation applies directly to:

• Credit institutions (banks)

• Investment firms

• Insurance and reinsurance undertakings

• Payment institutions

• Electronic money institutions

• Crypto-asset service providers

• Crowdfunding service providers

• Central securities depositories

• Trading venues and central counterparties

• Alternative investment fund managers and UCITS management companies

• Credit rating agencies and trade repositories

• Data reporting service providers

If an entity is regulated under EU financial services law, it almost certainly falls within DORA's scope.

ICT Third-Party Service Providers

DORA doesn't stop at the financial entities themselves. Technology vendors serving in-scope financial entities should expect to support DORA-related requirements through contract terms, security assurances, incident cooperation, and ongoing oversight by their customers. Providers designated as critical ICT third-party providers (CTPPs) may also face direct regulatory oversight.

This applies even to providers headquartered outside the EU. If you supply ICT services to EU-regulated financial institutions, DORA's requirements apply to that work.

Critical Third-Party Providers

"Critical third-party providers" (CTPPs) represent a distinct category under DORA. These are ICT service providers that EU regulators designate as systemically important to the financial sector—the ESAs have designated 19 critical ICT third-party providers whose failure or compromise could threaten financial stability broadly.

CTPPs face direct regulatory oversight from 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). Unlike other vendors managed through contractual requirements with their financial entity customers, CTPPs can be fined directly by regulators for non-compliance.

The Five Pillars of DORA Requirements

DORA organizes its requirements around five pillars. Together, they form a comprehensive approach to ICT risk that covers governance, incident response, testing, third-party oversight, and threat intelligence.

ICT Risk Management and Governance

Pillar one establishes the foundation: entities must implement robust ICT risk management frameworks that address the full lifecycle of risk—identification, protection, detection, response, and recovery.

DORA requires documented policies, defined procedures, and ongoing governance. Crucially, it places accountability at the top. Management bodies—boards and senior executives—hold direct, personal responsibility for cybersecurity risk oversight. They must ensure adequate resources, skills, and governance structures are in place.

Key requirements include ICT risk policies reviewed at least annually, defined roles and responsibilities, and a dedicated ICT risk management function within the organization.

ICT Incident Reporting and Management

When something goes wrong, DORA requires a structured, timely response. Entities must classify ICT-related incidents based on defined criteria and report major incidents to their national competent authorities within strict timeframes.

The reporting timeline follows a phased structure:

• Initial notification: according to the phased reporting timelines defined in the applicable DORA technical standards after a major ICT-related incident is classified

• Intermediate report: updating regulators on the status and impact

• Final report: documenting root cause analysis and remediation actions

This harmonized process replaces the patchwork of national reporting obligations that existed before DORA. Organizations need documented incident management processes—and the technical capability to detect, classify, and escalate incidents quickly.

Digital Operational Resilience Testing

Testing under DORA is mandatory. Entities must regularly test their ICT systems to validate that cyber resilience controls work under pressure.

Two tiers apply:

• Basic testing (all entities): vulnerability assessments, network security testing, gap analysis, and scenario-based testing at a minimum

• Advanced Threat-Led Penetration Testing (TLPT) (significant entities): intelligence-driven simulations of real cyber-attacks targeting critical functions and production systems, conducted by qualified testers at least every three years

TLPT differs from a standard penetration test. It is a controlled simulation built around actual threat intelligence, targeting the specific attack patterns most likely to be used against a given institution. Competent authorities determine which entities must undergo TLPT, and microenterprises may be subject to proportionality provisions. Results and remediation actions must be documented and reported to regulators.

ICT Third-Party Risk Management

Managing vendor risk is one of DORA's most operationally demanding pillars. Entities must maintain full oversight of every ICT service provider in their supply chain—not just critical ones.

This means:

• Due diligence before onboarding any ICT provider, including risk assessments and security reviews

• Contractual requirements mandating specific security standards, audit rights, incident notification obligations, and data portability

• Ongoing monitoring of provider performance, security posture, and compliance status

• Exit strategies and transition plans for every critical or important service, ensuring business continuity if a provider relationship ends or fails

For organizations with hundreds of vendors, this pillar creates significant operational complexity. Manual processes—spreadsheets, periodic reviews, disconnected workflows—cannot meet DORA's continuous oversight standard.

Information-Sharing Arrangements

The fifth pillar encourages—though doesn't mandate—voluntary frameworks for sharing cyber threat intelligence among financial entities. DORA establishes a framework for exchanging information about cyber threats, vulnerabilities, and attack patterns.

The rationale is straightforward: threats targeting one institution often target others with similar infrastructure. Shared intelligence strengthens collective defenses. Participation is voluntary, but DORA provides legal protections for entities that choose to share sensitive threat information with peers.

DORA Regulatory Technical Standards and Guidelines

DORA operates on a three-level legal structure, and understanding it matters for compliance planning.

• Level 1 (the regulation itself): sets the binding framework and principles

• Level 2 — Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS): provide detailed technical requirements developed by the ESAs, specifying what "robust" ICT risk management looks like in practice—including requirements for incident classification, TLPT methodology, and third-party contract provisions

• Level 3 — ESA Guidelines: offer implementation guidance and supervisory expectations

The RTS and ITS are critical reading for compliance teams. They translate DORA's high-level principles into specific, testable requirements. Organizations should monitor ongoing publications from the EBA, EIOPA, and ESMA, as technical standards continue to be finalized and updated.

DORA Enforcement Timeline and Penalties

DORA entered into force on January 16, 2023, and became fully applicable on January 17, 2025. Enforcement is active now.

National competent authorities (financial regulators in each EU member state) oversee compliance for financial entities. They can impose:

• Administrative penalties and remedial measures

• Periodic penalty payments to compel ongoing compliance

• Public disclosure of violations

Financial entities can face administrative penalties, remedial measures, periodic penalty payments, public findings, and other supervisory action under applicable enforcement regimes. Critical ICT third-party providers designated for direct oversight may also face penalties from the European Supervisory Authorities. For CTPPs under direct ESA oversight, the regulation provides for significant financial penalties for non-compliance.

Beyond fines, regulators can require entities to suspend or discontinue products, services, or activities that pose systemic risk. The reputational and operational consequences of non-compliance extend well beyond financial penalties.

How DORA Compares to SOC 2 and Other Frameworks

Organizations already maintaining SOC 2, ISO 27001, or Network and Information Security Directive 2 (NIS2) compliance often ask how DORA fits in. There is overlap, but DORA goes further in several specific areas.

DORA vs. NIS2: NIS2 applies broadly across critical infrastructure sectors with general cybersecurity obligations. DORA targets the financial sector with detailed, sector-specific ICT risk requirements. Organizations in financial services may need to comply with both—NIS2 for general cybersecurity requirements and DORA for the more detailed, sector-specific resilience obligations. DORA operates as lex specialis relative to NIS2 for the financial sector.

DORA and ISO 27001: ISO 27001 provides a strong control foundation, and many of its controls map to DORA requirements. However, DORA adds specific obligations around incident reporting timelines, TLPT requirements, and third-party contract provisions that fall outside ISO 27001's scope. Existing certification reduces the gap—but doesn't substitute for DORA compliance.

Does DORA Apply to UK Organizations

Post-Brexit, DORA does not apply directly in the UK. UK financial entities regulated solely under UK law are not subject to DORA.

Two important caveats apply, however:

1. UK-based ICT service providers serving EU financial entities are subject to DORA's requirements in the context of those services. If a UK cloud provider or software vendor counts EU banks among its customers, those contractual relationships must meet DORA standards.

2. UK financial entities operating in the EU through branches or subsidiaries may fall within DORA's scope for those operations.

The UK has its own operational resilience framework from the Financial Conduct Authority (FCA) and the Prudential Regulation Authority (PRA), which shares conceptual overlap with DORA but has different specific requirements. Organizations operating across both jurisdictions need to address both regulatory regimes—and should map the overlaps to reduce duplication of effort.

How to Achieve DORA Compliance

Manual processes and point-in-time assessments fall short of DORA's continuous requirements. The regulation demands ongoing resilience, which means readiness needs to be built into operations—not assembled before an audit.

Here's a practical framework for getting compliant and staying there.

1. Conduct a Readiness Gap Assessment

Start by mapping current ICT risk management practices against DORA's five pillars and the applicable RTS requirements. Identify gaps in governance documentation, incident response capabilities, testing programs, and third-party oversight. Prioritize remediation based on risk exposure and regulatory timeline.

The Drata Agentic Trust Management Platform helps accelerate this process by mapping existing controls—including controls built for SOC 2 or ISO 27001—to DORA requirements, surfacing overlap and gaps automatically.

2. Establish ICT Governance Frameworks

DORA requires documented policies, clear ownership, and demonstrable board-level accountability. That means policies reviewed regularly, version-controlled, and connected to specific control owners.

Build governance frameworks that address all five pillars. Assign clear roles and responsibilities. Ensure the management body has the information and mechanisms needed to exercise meaningful oversight of ICT risk—beyond a quarterly briefing.

3. Implement Continuous Control Monitoring

DORA's continuous resilience requirement makes point-in-time compliance insufficient. Controls need to be monitored, tested, and evidenced on an ongoing basis.

Automated control monitoring delivers real-time visibility into ICT risk posture. When a control drifts or fails, teams need to know immediately. Continuous evidence collection reduces the manual burden on compliance teams, replacing spreadsheet-based tracking with automated, always-current documentation.

4. Build a Third-Party Risk Management Program

DORA's third-party pillar requires organizations to maintain an up-to-date register of all ICT service providers, conduct due diligence before onboarding, and monitor providers on an ongoing basis. For organizations with large vendor ecosystems, this demands a structured program—not ad hoc reviews.

A complete Third-Party Risk Management (TPRM) program includes standardized vendor assessments, contractual templates that meet DORA's specific requirements, ongoing monitoring workflows, and documented exit strategies for critical providers. Integrated platforms that unify TPRM with compliance workflows give teams the visibility they need across the full supply chain.

5. Prepare for Operational Resilience Testing

Establish a formal testing program covering all required testing types under DORA. For most entities, this starts with vulnerability assessments, scenario-based testing, and penetration testing. For significant entities subject to TLPT requirements, begin engaging with qualified TLPT providers early—these engagements take time to scope and execute properly.

Document all test results, findings, and remediation actions. Regulators expect evidence of a mature, ongoing testing program—not a single annual test.

Turn DORA Compliance into Continuous Trust

DORA compliance is an ongoing operational state. Organizations that treat it as a one-time project find themselves rebuilding evidence, chasing gaps, and struggling through supervisory reviews. Those that build continuous readiness into their operations find the opposite: less friction, faster responses, and a security posture they can demonstrate to regulators, customers, and partners.

FAQs about DORA Cybersecurity Regulation