Key takeaways

Understand the core concepts and terminology behind Who needs to comply with DORA? All your questions answered.
Learn practical steps to apply the guidance and stay audit-ready.
See where SecureSlate can help centralize evidence, ownership, and ongoing compliance workflows.

The Digital Operational Resilience Act (DORA) was developed to protect the financial sector, which is particularly vulnerable to cyberattacks.

According to the IMF’s 2024 Global Financial Stability Report, the number of cyberattacks has progressively increased since 2004, and nearly 20% of these attempts target financial institutions. DORA is a regulatory measure in the European Union (EU) intended to improve the cybersecurity and operational resilience of organizations across the financial ecosystem.

While DORA is most relevant to institutions offering financial services in the EU, many critical third-party technology organizations can also fall within its scope.

Related guides:

In this guide, you’ll get clear answers to:

Who needs to comply with DORA—and by when
The potential consequences of non-compliance
How to achieve DORA compliance in practice

When “resilience” becomes a deadline

GIF via GIPHY

DORA at a glance

DORA is an EU regulation designed to strengthen the financial sector—which includes financial entities and their critical third-party information and communications technology (ICT) service providers—and help them manage, respond to, and recover from cyber and operational risks.

It establishes a structured risk management framework drawing from widely used security programs (for example, ISO 27001- and NIST-aligned practices). In practice, DORA pushes organizations to formalize and demonstrate well-defined expectations for:

Incident management, reporting, and classification
Digital operational resilience testing
Information-sharing arrangements
Managing third-party risk

Before DORA, EU jurisdictions applied disparate—and sometimes generic—rules that could create gaps and conflicts. DORA aims to simplify that landscape by introducing a more harmonized set of requirements for ICT risk management across the EU’s financial ecosystem.

Who must comply with DORA?

DORA’s scope is designed with the stability and resilience of the EU’s financial supply chain in mind.

Threat actors often compromise an organization by exploiting cybersecurity weaknesses and technology dependencies in its third-party network. DORA addresses that risk by requiring in-scope entities—and certain critical third parties—to follow a comprehensive ICT risk framework.

As of January 2025, Article 2 of the DORA regulation specifies 21 categories of in-scope entities:

Credit institutions
Payment institutions, including those exempted under the Directive (EU) 2015/2366
Account information service providers
Electronic money institutions
Investment firms
Crypto-asset service providers
Central securities depositories
Central counterparties
Trading venues
Trade repositories
Alternative investment fund managers
Management companies
Data reporting service providers
Insurance and reinsurance undertakings
Insurance intermediaries, reinsurance intermediaries, and ancillary insurance intermediaries
Institutions for occupational retirement provision
Credit rating agencies
Administrators of critical benchmarks
Crowdfunding service providers
Securitization repositories
ICT third-party service providers

What “financial entity” means in practice

DORA directly applies to entities providing financial services in the EU in any capacity. This can include (depending on your authorization/registration and activities) financial institutions, investment funds, pension funds, insurance entities, and other regulated organizations in the financial services ecosystem.

What counts as an ICT third-party service provider (ICT TPSP)

ICT third-party service providers can include:

Software vendors
Cloud service providers
Data analytics firms
Managed service providers (MSPs)
Cybersecurity providers and other technology providers supporting core business services

DORA’s oversight model distinguishes between third parties generally and those designated as critical. If you provide ICT services to EU financial entities—especially in ways that are operationally significant—you may fall into the oversight scope described in DORA (see Article 31 for the oversight framework details).

In practice, an ICT TPSP may need to support oversight requirements such as:

Cooperating with financial entities on regular resilience testing
Notifying financial entities about ICT-related incidents and disruptions
Maintaining business continuity and operational resilience plans
Complying with EU privacy and confidentiality requirements as applicable

Who is exempt from DORA?

DORA excludes certain entities due to factors like smaller size, limited ICT risk exposure, or non-critical operations.

Per Article 2, exemptions include:

Managers of alternative investment funds referred to in Article 3(2) of Directive 2011/61/EU
Small insurance and reinsurance undertakings referred to in Article 4 of Directive 2009/138/EC
Institutions for occupational retirement provision operating pension schemes that have fewer than 15 members
Natural or legal persons according to MiFID II, according to Articles 2 and 3 of Directive 2014/65/EU
Insurance intermediaries, reinsurance intermediaries, and ancillary insurance intermediaries that are microenterprises or small- or medium-sized enterprises
Post office giro institutions as mentioned in Article 2(5) of Directive 2013/36/EU

Member States may also exclude certain entities from DORA’s scope, provided they notify the Commission and make the decision publicly known.

Even if your organization is exempt, adopting DORA-aligned practices can still be valuable if you’re looking to:

Enhance your security posture
Strengthen third-party risk management
Improve operational continuity
Win deals by demonstrating security and resilience maturity

What's the deadline for DORA compliance?

DORA came into effect on January 16, 2023, but the deadline for compliance was set to January 17, 2025.

The compliance deadline also marks the commencement of oversight activities carried out by the European Supervisory Authorities (ESAs) in close coordination with competent authorities defined under Article 46.

Operationally, the oversight process includes:

Competent authorities designating ICT TPSPs as critical or non-critical, depending on the services and technical support they provide to in-scope financial entities
ESAs maintaining a register of critical ICT TPSPs (with a stated deadline in the regulation process for April 30, 2025), then beginning supervision processes for those critical providers

What are the consequences of non-compliance with DORA?

Because DORA is a mandatory regulation, non-compliance can have significant consequences—financial, operational, and reputational—for in-scope financial entities and critical ICT providers.

Member States can specify administrative penalties or remedial measures for breaches in their jurisdiction.

Potential outcomes can include:

Monetary penalties (defined/implemented through Member State regimes)
Public reprimands from competent authorities
Operational restrictions and business limitations
Legal action against senior executives in certain cases (jurisdiction-dependent)

4 steps to DORA compliance

If you’re building toward DORA compliance, these four steps are a practical sequence to turn requirements into an operating program.

Step 1: Understand the framework’s pillars

DORA is commonly organized into five foundational pillars:

ICT risk management
ICT third-party risk management
Digital operational resilience testing
Management, reporting, and classification of ICT-related incidents
Information sharing (optional, but often part of a mature program)

Work with IT, security, risk, and compliance stakeholders to define the policies, processes, and systems you need to meet these requirements. A structured checklist can help ensure you don’t miss cross-functional dependencies.

Step 2: Perform a gap analysis

Review current ICT risk management practices through security reviews, risk assessments, and IT infrastructure audits. Document gaps in a way that translates directly into remediation work.

Step 3: Implement missing controls (and assign owners)

Translate gaps into an implementation plan that defines:

Owners and responsibilities
Timeline and milestones
KPIs for progress tracking

Set a regular reporting cadence so you can measure movement and avoid “audit-time scrambling.”

Step 4: Perform a self-attestation (and plan ongoing monitoring)

There is not (yet) a single official third-party-supported certification process for DORA. To demonstrate compliance, many organizations rely on a documented self-attestation validated and signed by an executive or compliance leader.

Plan for ongoing monitoring so the program stays current as systems, vendors, and threat conditions change.

Get DORA-ready faster with SecureSlate

DORA often forces organizations to move quickly: define scope, map requirements, close control gaps, and continuously produce evidence.

SecureSlate helps teams centralize and operationalize that work so DORA readiness doesn’t live in spreadsheets and ad-hoc folders. With SecureSlate, you can:

Map requirements to controls and track implementation status
Assign owners and due dates for remediation work
Centralize evidence so artifacts are audit-ready and reusable
Monitor control health over time to reduce drift and surprises

If you’re working toward DORA, the goal is to make resilience measurable and repeatable—so oversight readiness is a steady-state capability, not a one-time project.

Get started for free: Create your SecureSlate account

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, consult a licensed attorney.

Who needs to comply with DORA? All your questions answered