DORA Implementation Guide: A Phased Roadmap to Compliance

Where to Start with DORA Implementation

The Digital Operational Resilience Act (EU 2022/2554) has applied to all in-scope financial entities since 17 January 2025. Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) now provide detailed requirements across all five DORA pillars. Entities that have not yet begun their implementation programme need to act now; those already underway need to validate their approach against the final standards.

Regardless of where you are in the process, a structured implementation roadmap prevents wasted effort, ensures nothing falls through the cracks, and gives your management body the visibility they need. The approach below is organised into five phases that can be adapted to your organisation's size, complexity, and existing maturity. For a high-level overview of what DORA requires, see our DORA compliance guide.

Phase 1: Assessment and Gap Analysis

The first phase establishes your baseline. You cannot build an effective implementation plan without understanding your current state in detail. This phase typically takes two to four weeks depending on organisational complexity.

Map current controls to DORA articles. Go through each of DORA's five pillars — ICT risk management (Art. 5-16), incident management and reporting (Art. 17-23), digital resilience testing (Art. 24-27), third-party ICT risk management (Art. 28-44), and information sharing (Art. 45) — and document where your existing practices already satisfy the requirements. Include the supporting RTS and ITS in your mapping.

Identify gaps and prioritise by risk. For each requirement where you have a gap, assess the risk level based on regulatory severity, the likelihood of supervisory scrutiny, and the potential business impact if the gap is exploited. This risk-based prioritisation will drive the sequencing of your implementation plan. Use the DORA compliance checklist as a structured reference.

Engage stakeholders early. Identify the internal functions that will be involved: ICT risk, information security, legal, procurement, internal audit, and the management body. Secure executive sponsorship and establish a governance structure for the implementation project. DORA requires management body accountability (Art. 5), so board engagement from day one is not optional.

Deliverables: Gap analysis report, risk-prioritised remediation plan, stakeholder map, project governance structure, initial budget estimate.

Phase 2: Governance and Framework Design

With your gaps identified, the second phase focuses on building the governance structures and policy framework that everything else depends on. This is the foundation that makes the subsequent implementation phases coherent rather than ad hoc.

Establish the ICT risk management framework. DORA Art. 6 requires a comprehensive ICT risk management framework that covers identification, protection, detection, response, and recovery. Design or update your framework to meet these requirements, incorporating the detailed provisions in the RTS on ICT risk management (Delegated Regulation 2024/1774). If you have an existing ISO 27001 or NIST-based framework, map it to DORA and fill the gaps rather than starting from scratch.

Define roles and responsibilities. Assign clear ownership for each DORA workstream. Designate who is responsible for maintaining the Register of Information, who manages incident classification and reporting, who oversees resilience testing, and who monitors third-party ICT risk. DORA requires a dedicated ICT risk management function (Art. 6(4)) with sufficient authority, independence, and resources.

Secure board-level accountability. Under Art. 5, the management body must define, approve, and oversee the ICT risk management framework. Establish a regular reporting cadence from the implementation project to the board, and ensure board members understand their personal responsibilities under DORA. Plan for the ongoing training requirements that Art. 5(4) mandates.

Draft core policies and procedures. Develop or update your ICT security policies, incident response procedures, business continuity policies, third-party risk management policies, and testing policies. These documents form the backbone of your compliance evidence and will be among the first things a supervisor requests.

Deliverables: Updated ICT risk management framework, RACI matrix, board reporting template, core policy suite, training plan for management body.

Phase 3: Implementation

This is the longest and most resource-intensive phase. It involves putting the framework into practice across all five DORA pillars simultaneously. Prioritise based on the risk assessment from Phase 1, but ensure all workstreams are progressing in parallel.

Build your Register of Information. The Register of Information (Art. 28(3)) is a comprehensive inventory of all ICT third-party arrangements. It must be maintained at entity, sub-consolidated, and consolidated levels. Identify all ICT service providers, classify arrangements by criticality, and populate the register following the ITS templates (ITS 2024/2956). This is often one of the most time-consuming workstreams due to the volume of arrangements and the data required for each.

Implement the incident reporting process. Design and operationalise your major ICT-related incident classification, escalation, and reporting workflow. DORA requires an initial notification within 4 hours of classification, an intermediate report within 72 hours, and a final report within one month. Build the internal processes, templates, and communication channels needed to meet these deadlines consistently. Test the workflow with tabletop exercises before going live.

Review and remediate third-party contracts. DORA Art. 30 prescribes specific contractual provisions that must be included in all ICT service agreements, with additional requirements for arrangements supporting critical or important functions. Audit your existing contracts, identify gaps, and negotiate amendments or addenda. This process takes time — budget for multiple rounds of negotiation with key providers. For guidance on specific clauses, see our third-party risk management guide.

Establish business continuity and disaster recovery. DORA Art. 11-12 require comprehensive ICT business continuity management, including impact analyses, recovery plans, and regular testing. Develop or update your BCP and DRP to address ICT-specific scenarios, including critical provider failure, ransomware, and data centre loss.

Launch the testing programme. Begin planning your digital operational resilience testing programme. Art. 24-25 require annual testing of all critical ICT systems using methods such as vulnerability assessments, network security reviews, scenario-based testing, and performance testing. If your entity is designated for TLPT (Art. 26-27), start engaging with your NCA and identifying qualified threat intelligence and red team providers.

Deliverables: Populated Register of Information, incident reporting workflow and templates, remediated third-party contracts, updated BCP/DRP, testing programme plan and initial test results.

Phase 4: Testing and Validation

Before declaring your implementation complete, this phase validates that everything works as designed. It also satisfies the testing requirements that DORA imposes as an ongoing obligation.

Execute vulnerability assessments. Conduct comprehensive vulnerability assessments across all critical ICT systems and infrastructure. Document findings, prioritise remediation by risk, and track closure. These assessments form the baseline for your ongoing annual testing cycle under Art. 25.

Run scenario-based testing. Test your incident response processes, business continuity plans, and disaster recovery procedures using realistic scenarios. Include scenarios involving critical third-party provider failure, ransomware attacks, and data integrity incidents. Document the results and feed lessons learned back into your framework and procedures.

Plan TLPT (for designated entities). If your entity has been designated for threat-led penetration testing under Art. 26, engage with your NCA to agree on scope and methodology. TLPT must follow the TIBER-EU framework and be conducted by qualified external testers. The first TLPT cycle can take 6-12 months from scoping to completion, so early planning is essential even if the test itself falls outside your initial implementation timeline.

Test the Register of Information. Validate the completeness and accuracy of your Register of Information by cross-referencing it against procurement records, invoices, and operational dependencies. Confirm that all required fields in the ITS templates are populated and that the data is current. Prepare for the first regulatory submission.

Conduct internal audit review. Engage internal audit to perform an independent assessment of your DORA compliance programme. This review should cover all five pillars and identify any remaining gaps before external supervisory scrutiny. Address findings before moving to Phase 5.

Deliverables: Vulnerability assessment reports, scenario test results and lessons learned, TLPT plan (if applicable), validated Register of Information, internal audit report and remediation tracker.

Phase 5: Ongoing Compliance

DORA compliance is not a one-time project. Once your initial implementation is complete, you transition to a continuous compliance model that maintains, monitors, and improves your operational resilience posture over time.

Annual Register of Information submission. Maintain and update your Register of Information on an ongoing basis and submit it to your NCA as required. Any new ICT arrangements, changes to existing arrangements, or terminations must be reflected promptly. The register is a living document, not an annual exercise.

Continuous monitoring and risk assessment. ICT risk management is an ongoing cycle. Monitor your threat landscape, update risk assessments when conditions change, track emerging vulnerabilities, and ensure your controls remain effective. DORA Art. 8-10 require continuous identification and classification of ICT assets, risk assessment, and monitoring.

Regulatory updates and guidance. The DORA regulatory landscape continues to evolve. ESAs issue guidance, NCAs publish supervisory expectations, and technical standards may be updated. Build a process for monitoring regulatory developments and assessing their impact on your compliance programme.

Board reporting. Provide regular reports to the management body on the state of ICT risk, incident trends, testing results, third-party risk, and overall DORA compliance. Art. 5 requires that the management body stays actively informed and exercises ongoing oversight. Use a standardised reporting format that evolves with your programme maturity.

Audit preparation. Maintain your compliance evidence in a state of continuous readiness. Supervisory examinations can occur at any time, and the ability to produce documentation, test results, and risk assessments quickly demonstrates programme maturity. A well-organised GRC platform is the most efficient way to manage this.

Key 2025–2026 DORA Milestones

The following dates mark the most important regulatory milestones that should anchor your implementation planning and ongoing compliance calendar.

How DORA GRC Supports Each Phase

DORA GRC is built around the five-pillar structure of the regulation, which means the platform maps directly to the implementation phases described above. Rather than assembling spreadsheets and point solutions, you get a single environment that grows with your programme.

Frequently Asked Questions

Related Guides