As of January 17, 2025, the Digital Operational Resilience Act (DORA) requires many financial entities (and their information and communication technology (ICT) service providers) that support EU entities to meet a baseline level of operational resilience.

If you’re new to the regulation, you can reduce the potential overwhelm caused by its requirements by using a concise compliance checklist.

Related guides:

This guide covers:

DORA applicability criteria
The regulation’s key requirements
An actionable DORA compliance checklist with the core steps to drive your program forward

When compliance requirements keep multiplying

GIF via GIPHY

Key takeaways

DORA took effect on January 17, 2025 and applies to many EU financial entities and ICT providers that serve them.
DORA is organized around five pillars, with information sharing generally treated as the voluntary pillar.
Start with scope (who/what is in-scope), then operationalize four core areas: ICT risk, incident handling/reporting, resilience testing, and third-party ICT risk.
A checklist reduces rework by turning the regulation into concrete owners, evidence, and repeatable workflows.

What is DORA (and when it took effect)?

The Digital Operational Resilience Act (DORA) is an EU regulation intended to strengthen how financial entities manage operational resilience—especially for technology-related risks.

DORA is focused on ensuring organizations can prevent, detect, respond to, and recover from ICT-related disruptions, while maintaining service continuity and limiting impact to customers and markets.

Who needs DORA compliance?

DORA is aimed at EU-based financial entities and ICT service providers that support them.

Examples include:

Entity type	Examples
Financial entities	Payment and credit institutions; electronic money institutions; investment firms; insurance companies; trade repositories
ICT service providers	Cloud providers; network security companies; IT consulting firms; managed IT service providers; help desk service providers

While in-scope financial entities are generally those operating in the EU or serving EU customers, ICT providers must comply regardless of location if they provide services to EU-based financial organizations.

The 5 key compliance requirements (DORA’s pillars)

While DORA includes many detailed requirements, most programs can be planned around its five pillars:

ICT risk management
ICT-related incident management
Digital operational resilience testing
ICT third-party risk management
Information sharing (commonly treated as the voluntary pillar)

Because the first four pillars require specific activities, a reliable checklist helps you streamline execution and stay focused on deliverables.

Your DORA compliance checklist (9 key steps)

Before you begin, determine scope and applicability. A practical starting point is to reference DORA Article 2 and validate whether your organization is impacted based on services and location.

If your organization must adhere to DORA, here are baseline steps you can follow to move toward compliance.

1) Outline management responsibilities

Start with governance. DORA Article 5 requires effective oversight of compliance procedures and processes—especially those related to ICT risk management—and assigns the management body responsibility for defining, approving, and overseeing them.

Common management-body responsibilities include:

Ultimate accountability for the entity’s ICT risk management
Establishing clear roles and responsibilities for ICT risk processes
Approving, overseeing, and periodically reviewing business continuity, incident response, and recovery plans
Allocating and reviewing the budget for operational resilience initiatives

Once management scopes obligations, translate them into policies, procedures, ownership, and review cadences.

2) Perform a gap analysis

Review DORA’s requirements and evaluate the current state of your ICT environment and security posture. Then run a gap analysis to determine what’s missing.

Focus areas often include:

Access management policies
Information security processes, roles, and responsibilities
Security vulnerabilities
Exposure to third-party risk (especially ICT dependencies)

Manual gap assessments can be time-consuming. Many teams reduce effort by using software that centralizes evidence and automates recurring reviews.

3) Develop a remediation plan

Once gaps are identified, build a plan to close them. The strategy and timeline depend on your maturity and resources, but remediation commonly concentrates on:

Threat prevention, detection, and remediation workflows
Third-party risk management (TPRM) controls and processes
Incident response, notification, and recovery procedures

If you have many action items, structure them into phases with owners, due dates, and measurable outcomes—so progress is trackable.

4) Inventory your third-party ICT providers

DORA requires financial entities to map dependencies on third-party ICT providers. This supports impact analysis and helps you anticipate and mitigate upstream incidents.

Build an inventory that includes:

All ICT providers that support in-scope services
Which systems and processes depend on each provider
Key contracts, SLAs, and points of contact

DORA also requires identifying critical ICT providers. Criticality is determined by factors outlined in Article 31, commonly including:

Impact on the quality, stability, and continuity of services
Reliance on the provider for key services
Substitutability (how easily you can replace the provider)

5) Adopt a third-party risk management framework

Inventorying vendors is only the start—you also need a framework for managing the risk they introduce.

Under DORA Article 6, your framework should formalize the strategies, tools, policies, procedures, and ICT protocols used to protect assets from ICT risks. These components should be documented and reviewed at least annually to reflect changes in your risk landscape.

Some organizations may qualify for a simplified risk management framework (see Article 16), such as:

Small and non-interconnected investment firms
Institutions exempt under Directive 2013/36/EU
Payment institutions exempt under Directive (EU) 2015/2366

6) Conduct digital operational resilience testing

DORA requires a testing program that evaluates preparedness for ICT-related incidents and identifies vulnerabilities and gaps.

Your program may include procedures such as:

Vulnerability scans
Network security assessments
Open source analyses
Security questionnaires

DORA also requires threat-led penetration testing (TLPT) at least once every three years, covering some or all critical functions (and more frequently for certain risk profiles).

7) Build an ICT business continuity policy

Even if you already have business continuity planning, DORA requires an ICT-focused business continuity policy with the relevant arrangements, procedures, plans, and mechanisms.

The goal is to maintain continuity and ensure you can respond effectively to incidents, contain impact, and execute recovery.

If you already have a strong incident response plan, you may only need to add or update DORA-specific controls. Once developed, ICT business continuity and ICT response/recovery plans should be reviewed at least annually.

Strong documentation also matters here—keep records of disruptions and remediation actions accessible and auditable.

8) Operationalize incident reporting and notifications

DORA obligates financial entities to report major ICT-related incidents to the relevant competent authority. Competent authorities vary, so refer to Article 46 to understand which authority applies to your organization.

As part of the reporting process, you typically need to produce:

An initial notification of an incident
An intermediate report when the status changes significantly
A final report after root cause analysis is completed (whether or not remediation has been implemented)

If an incident impacts a client’s financial interests, you may also have an obligation to notify the client as soon as you become aware.

Make sure these processes are embedded in your incident response plan with clear criteria, owners, and timelines.

9) Begin the attestation process

DORA isn’t a certifiable regulation in the same way as some audit standards. In practice, compliance often involves internal validation and self-attestation against the regulation’s requirements.

After implementing the relevant controls, assess in-scope systems and functions to confirm adherence. Oversight is conducted on an ongoing basis by the European Supervisory Authorities (ESAs), including:

European Banking Authority (EBA)
European Insurance and Occupational Pensions Authority (EIOPA)
European Securities and Markets Authority (ESMA)

How to meet DORA requirements more efficiently with SecureSlate

DORA compliance work can be extensive—especially when you’re coordinating security reviews, evidence collection, vendor inventories, and continuous monitoring across multiple teams.

SecureSlate helps you streamline the day-to-day execution by centralizing the work in one place. With SecureSlate, you can:

Turn requirements into actionable checklists with owners, due dates, and status tracking
Centralize evidence collection so reviews and reporting don’t turn into a scramble
Maintain a living vendor inventory and keep third-party ICT risk assessments organized
Track readiness over time so your program stays current as systems and vendors change

If you’re building a DORA-ready operational resilience program, SecureSlate can help you stay focused on execution—not spreadsheets.

Get started for free: Create your SecureSlate account

FAQ: DORA compliance

Does DORA apply only to EU-based companies?

Not necessarily. If you’re an ICT service provider supporting EU financial entities, DORA-related obligations can apply even if your company is based outside the EU.

What are DORA’s “five pillars”?

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

What should we do first for DORA?

Start by confirming applicability and scope (Article 2), then run a gap analysis and create a remediation roadmap that assigns owners and evidence expectations.

How often do we need to test?

Testing frequency depends on your risk profile and required procedures, but DORA includes TLPT requirements at least every three years for in-scope entities/functions.

Disclaimer (legal note)

SecureSlate is not a law firm, and this article does not constitute legal advice. When determining your obligations and compliance with respect to relevant laws and regulations, consult qualified counsel.

The DORA Compliance Checklist