DORA Compliance in the EU: Practical Implementation Guide for Financial Entities

The Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, has applied since 17 January 2025. It sets uniform requirements for how financial entities in the EU manage ICT risk, report major ICT-related incidents, test their resilience and control their dependence on ICT third-party service providers. This guide focuses on implementation: what DORA requires in practice, which technical standards fill in the detail, and how to organise the work. It is a general overview, not legal advice.

1. Who DORA applies to

Article 2 of DORA lists the financial entities in scope. They include credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers and issuers of asset-referenced tokens, central securities depositories, central counterparties, trading venues, managers of alternative investment funds, UCITS management companies, insurance and reinsurance undertakings, insurance intermediaries within scope, institutions for occupational retirement provision, credit rating agencies, administrators of critical benchmarks, crowdfunding service providers and others. Article 2 also brings ICT third-party service providers within the oversight framework.

DORA is applied in line with the principle of proportionality. Entities implement the requirements taking into account their size, overall risk profile and the nature, scale and complexity of their services, activities and operations. Certain entities, such as some microenterprises and the entities listed in Article 16, may apply a simplified ICT risk-management framework, and Article 2 contains specific exclusions. Because scope and the available simplifications depend on the entity's licence, size and activities, the exact position must be checked against Article 2, Article 16 and the relevant technical standards rather than assumed.

2. Management body responsibility and governance

Under Article 5, the management body defines, approves, oversees and is responsible for the implementation of all arrangements related to the ICT risk-management framework. It bears ultimate responsibility for managing ICT risk. In practice this means the board approves the digital operational resilience strategy and key policies, allocates budget, sets roles and responsibilities for ICT functions, approves the policy on ICT third-party arrangements and is informed of major incidents and significant changes to third-party arrangements. Members of the management body are expected to keep sufficient knowledge and skills to understand and assess ICT risk, including through regular training. Boards should be able to show evidence of these decisions, not only that a policy exists.

3. ICT risk-management framework

Articles 6 to 14 of DORA, supplemented by Delegated Regulation (EU) 2024/1774, require a sound, comprehensive and well-documented ICT risk-management framework. Its main components are:

• Identification: identify, classify and document ICT-supported business functions, information assets and ICT assets, their roles and dependencies, and the related risks.
• Protection and prevention: policies and controls for security, access management, network security, encryption, change management and patching, designed to ensure resilience, continuity and availability.
• Detection: mechanisms to promptly detect anomalous activities, including network performance issues and ICT-related incidents, with defined alert thresholds.
• Response and recovery: an ICT business continuity policy and response and recovery plans, tested regularly.
• Backup and restoration: backup policies and procedures, restoration and recovery methods, and, where required, redundant ICT capacities.
• Learning and evolving: post-incident reviews, lessons learned from testing and incidents, and ICT security awareness programmes.
• Communication: crisis communication plans for internal and external stakeholders.

The framework must be documented and reviewed at least once a year, or periodically for microenterprises, as well as after major ICT-related incidents and following supervisory instructions or conclusions from testing or audit. Delegated Regulation 2024/1774 sets out the detailed content of policies and procedures, and a separate simplified framework for entities eligible under Article 16.

4. Major ICT-related incident classification and reporting

DORA requires entities to have an ICT-related incident management process to detect, manage, record and notify incidents (Article 17). Incidents are classified under Article 18 using the criteria and materiality thresholds in Delegated Regulation (EU) 2024/1772. Those criteria include clients, financial counterparts and transactions affected, reputational impact, duration and service downtime, geographical spread, data losses, criticality of the services affected and economic impact. Major incidents must be reported to the competent authority under Article 19.

Delegated Regulation (EU) 2025/301 sets the reporting time limits:

• Initial notification: as early as possible, within 4 hours from classification of the incident as major, and no later than 24 hours from the moment the entity became aware of the incident.
• Intermediate report: no later than 72 hours from the submission of the initial notification, and updated where the status changes significantly.
• Final report: no later than 1 month from the submission of the intermediate report or the latest updated intermediate report.

Implementing Regulation (EU) 2025/302 sets the standard forms, templates and procedures for these reports, and for voluntary notification of significant cyber threats. National competent authorities may specify submission channels, so entities should confirm the local procedure in advance. A practical playbook should state who classifies, who approves submission, and how the clock is tracked from awareness and from classification.

5. Digital operational resilience testing

Articles 24 to 27 require a sound and comprehensive digital operational resilience testing programme, applied proportionately. It may include vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing. ICT systems and applications supporting critical or important functions must be tested at least yearly.

Advanced testing by means of threat-led penetration testing (TLPT) is not required of every entity. Under Article 26, financial entities identified by competent authorities according to the criteria in DORA and the regulatory technical standards may be required to carry out TLPT at least every 3 years. Delegated Regulation (EU) 2025/1190 specifies the criteria for identifying such entities, the requirements for testers, the scope, the testing methodology and the approach for each phase. Entities should check whether they meet those criteria or have been notified by their authority rather than assume TLPT applies or does not apply.

6. ICT third-party risk

Under Article 28, financial entities that use ICT third-party service providers remain at all times fully responsible for compliance with their obligations under DORA and applicable financial services law. Using a cloud or other provider does not transfer that responsibility. Key requirements include:

• Strategy and policy: a strategy on ICT third-party risk and, for entities other than those excluded, a policy on the use of ICT services supporting critical or important functions, the content of which is specified in Delegated Regulation (EU) 2024/1773.
• Pre-contract assessment: before entering an arrangement, assess whether it covers a critical or important function, conduct due diligence on the provider, identify and assess risks, including ICT concentration risk under Article 29, and assess conflicts of interest.
• Contract content: Article 30 lists mandatory contractual provisions, including a description of services, locations where services are provided and data processed, data protection and access provisions, service levels, assistance in incidents, cooperation with authorities and termination rights. For ICT services supporting critical or important functions, additional terms are required, including full service level descriptions, notice periods and reporting obligations, business contingency plans, participation in TLPT where relevant, unrestricted access, inspection and audit rights, and exit strategies with an adequate transition period.
• Subcontracting: Delegated Regulation (EU) 2025/532 specifies what entities must assess when ICT services supporting critical or important functions are subcontracted, including the subcontracting chain, conditions for subcontracting and the handling of material changes, which the provider must notify in advance.
• Exit: documented exit strategies for ICT services supporting critical or important functions, tested where appropriate, so that the entity can exit without disruption to its business or to its clients.

7. Register of information

Article 28(3) requires financial entities to maintain and update, at entity level and at sub-consolidated and consolidated levels, a register of information on all contractual arrangements on the use of ICT services provided by ICT third-party service providers. The register must distinguish arrangements covering critical or important functions. Implementing Regulation (EU) 2024/2956 sets the standard templates. Competent authorities may request the full register, and entities must report at least yearly on new arrangements, the categories of providers, the type of arrangements and the services and functions provided.

In practice the register is a data-governance exercise. It requires consistent identifiers for providers and contracts, accurate links between contracts, ICT services and business functions, information on subcontractors in the chain, and an owner responsible for keeping it current. Groups need to align entity-level and group-level data.

8. Practical implementation workstreams

• Scope and entity inventory: confirm which group entities are in scope, under which category, and whether simplified requirements apply.
• Critical or important functions: identify the functions whose disruption would materially impair performance, compliance or continuity.
• ICT asset and service mapping: map ICT assets, services and dependencies to those functions.
• Governance and policies: approve strategy, policies and roles at management body level.
• Incident classification and reporting playbook: embed 2024/1772 criteria, 2025/301 timelines and 2025/302 templates.
• Testing plan: a proportionate annual programme, with TLPT readiness where relevant.
• Vendor contract remediation: gap-analyse contracts against Article 30 and renegotiate.
• Register of information: populate templates and set update procedures.
• Board reporting and training: regular reporting and ICT risk training for the management body.
• Evidence and remediation log: record decisions, findings, owners and deadlines.

9. A 90-day readiness plan (illustrative)

The following is an implementation example only. DORA has applied since 17 January 2025 and does not set a 90-day deadline; entities that have gaps should remediate them as soon as possible and follow any supervisory expectations.

• Days 1-30: confirm scope and proportionality, identify critical or important functions, collect the vendor and contract inventory, appoint owners and report the gap analysis to the management body.
• Days 31-60: update ICT risk and third-party policies, finalise the incident classification and reporting playbook, start contract remediation for critical or important functions and populate the register of information.
• Days 61-90: run a tabletop incident exercise, approve the testing programme, review exit strategies, obtain board approval of updated documents and set an evidence-based remediation log for remaining items.

10. Common implementation mistakes

• Treating DORA as an IT-only project rather than a governance, legal and business-continuity obligation.
• Assuming outsourcing to a cloud provider transfers responsibility.
• An incomplete vendor inventory that misses intra-group or embedded ICT services.
• Generic contracts that lack Article 30 provisions.
• Missing or inconsistent data in the register of information.
• Over-classifying or under-classifying incidents because thresholds are not embedded in procedures.
• Assuming TLPT applies to every entity, or ignoring a notification that it does.
• No evidence of board oversight, approvals and training.

11. Interaction with MiCA and CASPs

Crypto-asset service providers authorised under MiCA are financial entities within DORA scope, so their ICT risk, incident reporting, testing and third-party arrangements must meet DORA alongside MiCA authorisation requirements. For a crypto-exchange perspective, see our article on running an EU crypto exchange under MiCA and DORA and our MiCA service.

12. How we can help

Our team advises on DORA implementation, including gap analyses, policies, incident playbooks, contract remediation and the register of information, and on wider banking and finance regulatory matters.

13. Disclaimer

This article is a general overview for information only. In addition to DORA and its technical standards, sector-specific rules, guidelines of the European Supervisory Authorities, national competent-authority procedures and the specific facts of each entity must be checked. Nothing in this article guarantees a regulatory outcome. Specific legal advice should be obtained before relying on any conclusion.