An actionable DORA compliance checklist for financial entities

Photo: Unsplash

As of January 17, 2025, financial entities—and information and communication technology (ICT) service providers that support them—must meet requirements under the Digital Operational Resilience Act (DORA), formally Regulation (EU) 2022/2554.

If you are new to DORA, the fastest way to reduce overwhelm is a concise DORA compliance checklist that turns legal text into owned deliverables, evidence, and review cadences.

This guide covers:

DORA applicability for financial entities and ICT providers
The regulation’s five pillars (and which are mandatory)
An actionable 9-step checklist financial entities can execute
How to streamline security reviews, evidence, and vendor inventory work

When compliance requirements keep multiplying

GIF via GIPHY

Related guides:

Key takeaways

DORA applies from January 17, 2025 to many EU financial entities and ICT providers serving them—including vendors outside the EU when they support EU financial organizations.
Programs are commonly built around five pillars; information sharing is typically voluntary, while the other four require concrete controls and evidence.
This 9-step DORA compliance checklist moves from governance (Article 5) through gap analysis, remediation, ICT vendor inventory, TPRM, resilience testing, continuity, incident reporting, and self-attestation.
Major ICT incident reporting has strict timelines: initial notification (as soon as four hours after classification, and no later than 24 hours from detection), intermediate update (within 72 hours), and final report (within one month of resolution).
TLPT (threat-led penetration testing) is required at least every three years for in-scope functions—plan testing and evidence early, not at year-end.

What is DORA (and when it took effect)?

DORA is an EU regulation designed to strengthen how financial entities manage operational resilience—especially technology-related risks.

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

Milestone	Date
DORA entered into force	January 16, 2023
Application / compliance deadline	January 17, 2025

Who needs DORA compliance?

DORA targets EU-based financial entities and ICT service providers that support them.

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 (MSPs); help desk and other critical technology providers

Financial entities are generally in scope when operating in the EU or serving EU customers. ICT providers may need to comply regardless of headquarters if they provide services to EU-based financial organizations—often through contractual obligations and critical provider oversight.

For the full entity list and exemptions, see Who needs to comply with DORA?.

5 key compliance requirements of DORA

DORA includes many detailed obligations, but most programs plan around five pillars:

Pillar	Mandatory?	What it requires (high level)
1. ICT risk management	Yes	Governance, policies, asset protection, identification and control of ICT risk
2. ICT-related incident management	Yes	Detection, classification, reporting, and learning from major incidents
3. Digital operational resilience testing	Yes	Testing program including TLPT on a defined cadence
4. ICT third-party risk management	Yes	Vendor inventory, criticality, contracts, monitoring, and concentration risk
5. Information sharing	Voluntary	Participation in trusted threat/intelligence sharing where appropriate

Because the first four pillars require specific, auditable actions, a DORA compliance checklist helps teams stay focused on deliverables—not re-reading the regulation every sprint.

A 9-step DORA compliance checklist

Before you begin, confirm scope under DORA Article 2 based on your services, authorization, and location.

If DORA applies, use these nine steps as your baseline program spine.

Step 1: Outline management’s responsibilities

DORA Article 5 requires effective governance of ICT risk management processes. The management body (board or equivalent) must define, approve, and oversee them.

Board-level responsibilities commonly include:

Ultimate accountability for 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 budget for digital operational resilience

Deliverable: documented governance charter, RACI for ICT risk, and annual review cadence signed off by management.

Step 2: Perform a gap analysis

Review DORA’s requirements against your current ICT environment and security posture.

Focus areas often include:

Access management policies and reviews
Information security roles and responsibilities
Vulnerabilities and exposure management
Third-party ICT dependencies and contractual controls

Manual gap analysis is labor-intensive. Many teams centralize evidence and automate recurring control checks to keep the gap assessment current.

Deliverable: gap register mapped to DORA articles/pillars with severity and owners.

Step 3: Develop a remediation plan

Translate gaps into a phased plan. Remediation usually concentrates on:

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

Structure large backlogs into phases with owners, due dates, and KPIs so progress is measurable—not aspirational.

Deliverable: remediation roadmap linked to gap register and budget.

Step 4: Inventory your third-party ICT providers

Financial entities must map dependencies on third-party ICT providers to understand upstream incident impact.

Your inventory should include:

All ICT providers supporting in-scope services
Systems and processes directly impacted by each provider
Contracts, SLAs, data flows, and escalation contacts

Identify critical ICT providers using factors in Article 31, including:

Impact on quality, stability, and continuity of financial services
Reliance on the provider for key services
Substitutability (how feasible replacement is)

Deliverable: ICT third-party register with criticality tier and dependency mapping.

Step 5: Adopt a third-party risk management framework

Inventory alone is insufficient—you need a formal TPRM framework under DORA’s third-party requirements (Articles 28–30 in the ICT third-party pillar).

Your framework should document:

Strategies, tools, policies, procedures, and ICT protocols that protect assets from ICT risk
Annual review (minimum) to reflect changes in services, vendors, and threat landscape

Some organizations may qualify for a simplified ICT risk management framework under 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

Deliverable: TPRM policy, assessment playbooks by tier, and contract security clauses for ICT providers.

Step 6: Conduct digital operational resilience testing

DORA requires a testing program that evaluates preparedness and surfaces vulnerabilities.

Your program may include:

Vulnerability scans
Network security assessments
Open-source dependency analysis
Physical security reviews (where relevant)
Security questionnaires for critical dependencies

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.

Deliverable: annual testing calendar, TLPT schedule, and retained test reports.

Step 7: Build an ICT business continuity policy

Even with an existing business continuity plan, DORA expects an ICT-focused business continuity policy covering arrangements, procedures, plans, and mechanisms for ICT disruptions.

Goals include:

Maintaining operational continuity during ICT incidents
Executing containment and recovery effectively

If incident response is mature, you may only need DORA-specific updates. ICT business continuity and ICT response/recovery plans should be reviewed at least annually.

Maintain documentation of disruptions and remediation actions for oversight and lessons learned.

Deliverable: ICT BCP, response/recovery runbooks, and annual review records.

Step 8: Define an incident response plan (with reporting timelines)

Financial entities must report major ICT-related incidents to the competent authority designated for their entity type—see Article 46 to confirm yours.

Embed these reporting obligations in your incident response plan:

Report	Timing (regulatory expectation)
Initial notification	Within four hours of classifying the incident as major—and no later than 24 hours from detection
Intermediate report	Within 72 hours of the initial notification when status changes materially
Final report	Within one month of incident resolution, after root cause analysis (whether or not remediation is complete)

If an incident affects a client’s financial interests, notify the client as soon as you become aware.

Deliverable: incident classification criteria, playbooks, communication templates, and tabletop exercises that rehearse ESA reporting paths.

Step 9: Begin the attestation process

DORA is not a certifiable standard like ISO 27001 in the traditional sense. Compliance commonly involves internal assessment and self-attestation signed by senior management after controls operate as designed.

Ongoing oversight is conducted by European Supervisory Authorities (ESAs), including:

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

Plan continuous monitoring after attestation—vendor changes, new systems, and regulatory updates will move your posture over time.

Deliverable: self-attestation package, evidence index, and continuous monitoring program.

How to meet DORA requirements more effortlessly

DORA programs are cross-functional. Without workflow discipline, teams often struggle in three areas:

Process	Common failure mode	What “good” looks like
Security reviews	Annual scramble	Scheduled control tests with owners and exceptions tracked
Evidence collection	Screenshots in shared drives	Centralized, dated, mapped to controls
Vendor inventory	Stale spreadsheet after procurement changes	Living register tied to criticality and contracts

A capable compliance automation platform reduces repetitive work—especially when you already run SOC 2, ISO 27001, or GDPR programs whose controls overlap DORA pillars.

Get—and stay—DORA compliant with SecureSlate

DORA spans ICT risk, incidents, resilience testing, third-party oversight, and governance. SecureSlate helps financial entities and ICT-dependent teams operationalize the checklist—not just document it.

As your DORA compliance partner, SecureSlate helps you:

Break requirements into actionable steps with owners, due dates, and status tracking
Map DORA themes to controls and reuse evidence across SOC 2, ISO 27001, GDPR, and NIS 2 where controls overlap
Automate evidence collection through 200+ integrations (validate your stack in a pilot)
Maintain a living ICT vendor inventory with tiering, assessments, and monitoring triggers
Centralize policies and templates for ICT risk, third-party risk, business continuity, and incident response
Support continuous monitoring so control drift is visible between oversight reviews—not only at attestation time

DORA compliance is not a one-time project. SecureSlate is built for ongoing readiness: evidence stays current, vendors stay classified, and leadership gets a defensible view of progress.

Get started for free

FAQ: DORA compliance checklist

Is there an official DORA certification?

Not in the same way as ISO 27001. Organizations typically demonstrate readiness through control operation, evidence, oversight interaction, and self-attestation—confirm approach with counsel and your competent authority.

What is the first step on the DORA checklist?

Confirm applicability under Article 2, then establish management governance (Article 5) before large-scale remediation.

How often must we run TLPT?

At least every three years for in-scope critical functions, and potentially more often depending on risk profile and supervisory expectations.

Do non-EU cloud providers need DORA compliance?

If you provide ICT services to EU financial entities—especially as a critical provider—you may face contractual and oversight obligations even outside the EU.

Can we reuse SOC 2 or ISO 27001 work for DORA?

Often, yes—for policies, risk management, access control, and vendor processes. Gap analysis should still map DORA-specific incident reporting, TLPT, and ICT third-party rules.

What is the difference between DORA and NIS 2?

DORA is financial-sector focused. NIS 2 applies more broadly to essential and important entities across many sectors. Some organizations may need both.

Disclaimer (legal note)

SecureSlate is not a law firm, and this article does not constitute legal advice or create an attorney-client relationship. DORA obligations depend on entity type, Member State implementation, and supervisory guidance. Incident reporting timelines and simplified-framework eligibility should be confirmed with qualified counsel and your competent authority.