DORA Guide: how to achieve compliance?

What is DORA?

DORA (Digital Operational Resilience Act) is the European regulation that unifies digital operational resilience requirements for the financial sector. It starts from a clear observation: the continuity of financial services now depends entirely on the robustness of information systems and the management of technological dependencies.

It complements NIS2 for financial entities, but as a specialised text (lex specialis), it takes precedence for these actors, with a more detailed framework and supervision ensured by financial authorities.

Its logic is proactive: not merely reacting to incidents, but demonstrating upfront the capacity to withstand disruption, to continue operating, and to recover — including in the face of severe yet plausible scenarios.

The five pillars of DORA

DORA is structured around five complementary pillars. Covering all of them in a coherent manner constitutes the core of the compliance effort.

Who is affected?

DORA targets a very broad scope of financial entities, as well as their ICT providers. Many mid-sized players are subject to it, albeit with a proportionality principle (a simplified framework exists for certain small entities).

• Banks, investment firms, payment institutions and electronic money institutions.
• Insurance and reinsurance undertakings and intermediaries.
• Management companies, funds, crypto-asset service providers, crowdfunding service providers.
• Critical ICT providers (cloud, data centres, publishers), subject to direct European supervision.

The ICT third-party providers register, the cornerstone

One of DORA's most structuring requirements is the information register: a detailed inventory of all your ICT providers and the services they deliver, underpinning critical and important functions.

This register is not merely a formality: it enables you to identify dependencies, measure concentration risk (over-reliance on a single provider) and prepare exit strategies. It is regularly requested by supervisors.

• Inventory every provider, service and supported function.
• Identify providers supporting critical functions.
• Assess and document concentration risk.

What penalties apply in the event of non-compliance?

Sanctions fall under national financial authorities for entities, and a European supervisor for critical ICT providers. They can be significant, and management liability is engaged.

How to achieve compliance: the 7-step roadmap

Step 1 — Define the ICT Risk Governance Framework

Formalise a framework approved by the management body: roles, responsibilities, risk appetite, and digital resilience strategy. DORA places explicit accountability on management — governance cannot be delegated solely to the IT department.

This framework must be documented, reviewed periodically, and aligned with the entity's overall risk management approach.

• Appoint responsible parties and define the committee structure.
• Document your ICT risk appetite.
• Have the framework validated by the management body.

Step 2 — Map Assets and Dependencies

Systematically inventory systems, critical functions, and internal and external ICT dependencies. Precisely identify the functions whose disruption would threaten the continuity of your financial services.

This mapping feeds into the risk analysis, the third-party register, and the definition of recovery objectives.

• Identify critical and important functions.
• Map internal and external dependencies.
• Link each function to its ICT providers.

Step 3 — Implement Detection and Protection Measures

Deploy protective measures, continuous monitoring, anomaly detection, and response and recovery mechanisms, with defined recovery time and data loss objectives.

Resilience must be prepared in advance: backups, redundancies, continuity and recovery plans must be in place and tested.

• Define recovery objectives (RTO/RPO).
• Implement monitoring and anomaly detection.
• Formalise continuity and recovery plans.

Step 4 — Structure ICT Incident Management

Establish incident classification according to regulatory criteria (impact, duration, scope) and a notification chain to competent authorities that complies with the required timelines.

A major incident must be capable of being qualified rapidly and reported using the expected templates: prepare these processes in advance.

• Classify incidents according to DORA criteria.
• Prepare notification templates and escalation workflows.
• Maintain an ICT incident register.

Step 5 — Organise Resilience Testing

Plan a testing programme: vulnerability assessments, scenario-based exercises, and continuity tests. For significant entities, threat-led penetration tests (TLPT) must be conducted periodically by qualified testers.

These tests are not a one-off audit: they form part of a documented multi-year programme.

• Establish a multi-year testing programme.
• Conduct TLPTs if you are a significant entity.
• Remediate identified vulnerabilities and track actions.

Step 6 — Manage ICT Third-Party Providers

Build the information register of third-party providers, incorporate mandatory contractual clauses (audit, security, sub-contracting, exit), assess concentration risk, and plan credible exit strategies.

Cloud dependency is a central area of focus: DORA requires entities to master its implications.

• Keep the ICT third-party register up to date.
• Incorporate mandatory contractual clauses.
• Prepare exit strategies for critical functions.

Step 7 — Organise Reporting and Information Sharing

Prepare disclosures to competent authorities, keep the register up to date, and participate, where applicable, in threat intelligence sharing arrangements among financial entities.

This final pillar, often overlooked, contributes to the collective resilience of the sector.

• Strengthen reporting processes to supervisory authorities.
• Keep the register ready for communication.
• Participate in cyber threat information sharing.

Common mistakes to avoid

• Reducing DORA to an IT project: it is a governance and oversight project driven by senior management.
• Failing to establish the ICT third-party provider register, the cornerstone of the framework.
• Neglecting the mandatory contractual clauses with providers, particularly cloud providers.
• Confusing DORA and NIS2: for a financial entity, DORA takes precedence as lex specialis.
• Underestimating concentration risk and the absence of an exit strategy.
• Treating testing as a one-off audit rather than a multi-year programme.
• Failing to prepare incident notification templates and timelines.

How Data Comply One supports you

Data Comply One offers a module for managing your DORA compliance, centralised within the same platform as your other regulatory obligations.

Two options are available to you: manage your compliance yourself using the software, or outsource it to our experts — a virtual CISO — who oversee it for you directly on the platform, providing a demonstrable framework to the ACPR or the AMF.

You thus have a consolidated and living compliance framework, without depending on expertise scattered across multiple tools.

Where do you stand? ·