What is the Digital Operational Resilience Act (DORA)? Everything you need to know

Photo: Unsplash

The Digital Operational Resilience Act (DORA) is a comprehensive EU regulation aimed at financial entities and their third-party information and communications technology (ICT) providers.

As a newer and still-evolving compliance area for many organizations, affected teams are often still aligning their cybersecurity, operational resilience, and third-party oversight processes to meet DORA’s requirements.

Because DORA compliance has been mandatory since January 17, 2025, many security and compliance teams have had to implement the regulation’s requirements under tight timelines.

Related guides:

• Who needs to comply with DORA? Scope requirements and penalties explained
• DORA compliance checklist
• DORA and NIS 2: importance and key differences explained

This guide covers:

• The meaning, purpose, and scope of DORA
• The regulation’s general structure (DORA’s five pillars)
• An overview of the compliance process
• Applicable deadline and penalties
• Common challenges to achieving compliance (and how to resolve them)

GIF via GIPHY

---

Key takeaways

• DORA is an EU regulation for the financial sector focused on ICT risk and operational resilience.
• Compliance has been mandatory since January 17, 2025 for in-scope entities and certain ICT providers supporting them.
• DORA is organized around five pillars: ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk management, and (generally voluntary) information sharing.
• There’s meaningful overlap with NIS 2 and common standards like ISO 27001, SOC 2, and NIST CSF—but scope and supervision differ.
• Start with scope and a gap assessment, then implement missing controls and operationalize evidence and reporting so compliance is sustainable.

---

What is the Digital Operational Resilience Act (DORA)?

DORA is an EU framework for strengthening the operational resilience of financial entities operating in the Union—especially resilience to ICT threats, incidents, and disruptions—through more harmonized governance and oversight expectations.

At a high level, DORA was proposed in 2020, adopted in 2022, entered into force on January 16, 2023, and has applied from January 17, 2025 (after a transition period).

Like the EU’s other major regulations (for example, GDPR), DORA is mandatory for in-scope organizations. While it’s comprehensive, it provides a structured set of requirements teams can use to build an operational resilience program with clear governance, testing, and reporting.

---

DORA’s scope: who needs to comply?

DORA is primarily aimed at organizations that provide financial services—including insurance—in the EU. Examples of entities that need to comply include:

• Banks
• Investment firms
• Account information service providers
• Trade repositories
• Crypto-asset service providers
• Payment and credit institutions

DORA also applies to ICT providers serving EU financial entities, even if the provider is based outside the EU. Cloud providers, network security firms, and other ICT providers supporting EU financial entities may need to meet applicable DORA requirements.

According to PwC estimates, DORA affects over 22,000 financial entities and ICT providers. If you’re among them, you’ll need to ensure your security policies, operational processes, and vendor oversight align with the regulation’s standards.

---

DORA’s 5 key pillars

DORA’s governance structure is commonly described through five pillars:

Pillar	Objective	Example requirements
ICT risk management	Develop a robust, dedicated function for managing ICT-related risks	Using capable systems and tools to ensure secure ICT operations; implementing measures to protect ICT systems; establishing mechanisms for detecting and mitigating ICT risks
ICT-related incident management	Develop an incident management process that detects, mitigates, and communicates incidents	Classifying ICT-related incidents by impact and severity; promptly reporting major incidents to relevant authorities; standardizing incident reporting formats
Digital operational resilience testing	Design, implement, and regularly review a resilience testing program	Testing the effectiveness of ICT tools and systems; regularly assessing digital operational resilience; simulating real-life cyber threats to test resilience
ICT third-party risk management (TPRM)	Design and implement a comprehensive TPRM framework built into the overall risk management program	Identifying and mapping third-party dependencies; overseeing critical third-party providers; including security-oriented clauses in contracts with ICT providers
Information sharing	Enable transparency by sharing cyber threat intelligence in trusted communities	Generally treated as voluntary (participation in information sharing arrangements may be optional)

---

DORA vs NIS 2 (and related frameworks like SOC 2, ISO 27001, and NIST CSF)

DORA overlaps with NIS 2, an EU directive that addresses cybersecurity across many sectors. If your organization is already working toward NIS 2 compliance, you may be able to reuse parts of your program for DORA—especially around governance, incident handling, and third-party risk.

One major difference is scope: NIS 2 is not sector-specific, while DORA is focused on financial entities and certain ICT providers supporting them. Two practical points to consider:

• If measures implemented under sector-specific regulations like DORA are “at least equivalent” to those under NIS 2, the corresponding NIS 2 provisions may not apply.
• If an entity affected by NIS 2 isn’t covered by a sector-specific regulation, the relevant NIS 2 provisions continue to apply.

DORA also overlaps with common standards and regulations, including:

• SOC 2
• ISO 27001
• NIST CSF

If you already comply with one or more of the above, you may have a head start with DORA because many controls (risk management, access control, incident response, change management, vendor oversight) map well to DORA’s pillars. The key is to validate scope and ensure DORA-specific reporting, testing expectations (including TLPT where applicable), and regulator-facing deliverables are covered.

---

How to ensure DORA compliance (5 key steps)

While the exact route to compliance depends on your security posture and program maturity, many teams follow a process like this:

1. Set compliance goals: Review DORA’s Article 2 to assess the regulation’s scope and confirm applicability. Some teams comply out of necessity; others use compliance as a way to expand operations to the EU.
2. Analyze your current state: Perform a comprehensive security review of your technical, procedural, and administrative controls, including your existing third-party risk management program.
3. Identify compliance gaps and next steps: Map your current controls to requirements across the five pillars and build a phased remediation plan that limits operational disruption.
4. Implement missing controls: Prioritize controls that are foundational and easiest to operationalize first, then tackle more demanding program elements (for example, threat-led penetration testing, incident reporting centralization, and vendor criticality assessment).
5. Self-attest framework completion: After implementing controls, validate them against DORA’s requirements and prepare internal self-attestation. Also check any local regulator guidance that influences how DORA is supervised in specific Member States.

---

DORA compliance deadline and penalties

All in-scope financial entities and ICT service providers need to ensure DORA compliance as of January 17, 2025. Some baseline deliverables many programs need in place include:

• A defined ICT risk management framework
• An ongoing ICT monitoring capability
• An incident reporting process
• ICT-related business continuity and recovery plans

Non-compliance with DORA can lead to penalties determined by competent authorities. You can review Article 46 to understand which authority covers your organization (authorities vary across niches within the financial sector).

Examples of potential consequences can include:

• Cease and desist orders for non-compliant operations
• Temporary or permanent cessation of specific non-compliant practices
• Criminal penalties in severe cases (depending on facts, jurisdiction, and authority)

Because enforcement and supervision can vary by authority and context, confirm expectations with qualified counsel.

---

Common DORA compliance challenges (and how to resolve them)

While pursuing DORA compliance, organizations commonly run into obstacles like:

Poor visibility of the ICT supply chain

Large organizations often have complicated ICT supply chains, including fourth-party dependencies. This makes it harder to inventory providers, map dependencies, and prioritize risk. A practical fix is to build a living vendor inventory tied to systems and critical functions—then maintain it continuously instead of only at audit time.

Lack of sufficient security program maturity

Lower-maturity programs may face many control gaps at once. Avoid trying to “boil the ocean” by sequencing work: start with governance, scoping, and baseline controls, then add testing and reporting sophistication in phases.

Manual cybersecurity and evidence workflows

If patching, reviews, and evidence collection depend on manual, point-in-time activities (email threads, spreadsheets, and scattered documents), the compliance timeline slows down. Consolidating ownership and evidence into a consistent system reduces rework.

Inefficient incident reporting processes

DORA requires efficient incident classification and reporting. Streamline decision points (what qualifies as a major incident, who approves reporting, what data is required) and automate where possible so reporting isn’t delayed.

Limited in-house DORA expertise

Because DORA is still new for many teams, ramp-up time can be a constraint. The best mitigation is to codify requirements into checklists, owners, and repeatable workflows—and to use tooling that makes progress visible and auditable.

---

Streamline DORA compliance with SecureSlate

DORA programs can become difficult to manage when requirements, evidence, vendors, and incident workflows are scattered across tools and teams.

SecureSlate helps you operationalize DORA by centralizing the work:

• Map requirements to controls across DORA’s pillars to reduce ambiguity
• Assign owners and track remediation so gaps close on a schedule, not “when there’s time”
• Centralize evidence for audits, regulator requests, and internal reviews
• Maintain a living vendor inventory to support third-party ICT risk management

If you’re working toward DORA compliance, the goal is to build resilience you can prove—without turning reporting and evidence collection into a recurring fire drill.

Get started for free: Create your SecureSlate account

---

FAQ: DORA basics

When did DORA take effect?

DORA entered into force in January 2023, with compliance becoming mandatory on January 17, 2025.

Who does DORA apply to?

DORA applies to many EU financial entities (including insurers) and can also apply to ICT providers that support EU financial entities—even if the provider is based outside the EU.

What are DORA’s five pillars?

They are commonly described as: ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing (often treated as the voluntary pillar).

Does being ISO 27001 or SOC 2 compliant mean we’re DORA compliant?

Not automatically. These standards can provide a strong foundation, but you still need to validate DORA scope and ensure DORA-specific expectations (for example, incident reporting formats/timelines and resilience testing requirements) are met.

---

Disclaimer (legal note)

SecureSlate is not a law firm, and this article does not constitute or contain legal advice or create an attorney-client relationship. When determining your obligations and compliance with respect to relevant laws and regulations, you should consult a licensed attorney.