Guide

How to Use This Checklist

This checklist maps directly to the articles and technical standards of DORA (EU Regulation 2022/2554). Each item references the specific article it addresses, so you can trace every requirement back to the regulation. The checklist is organised by the five pillars of DORA, with items roughly ordered by priority within each pillar.

Go through each item and assess whether your organisation has met the requirement fully, partially, or not at all. Items marked partially or not met should be added to your remediation plan with clear ownership and deadlines. For a scored, automated version of this assessment, use the free DORA gap analysis tool, which covers 25 questions across all five pillars and gives you an instant maturity score.

The proportionality principle (Art. 4) applies throughout. Not every item applies at the same depth to every entity. Smaller and less complex entities may meet some requirements at a reduced level, particularly around the ICT risk management framework (Art. 16) and testing (Art. 25). If you are uncertain about what level of compliance is expected for your entity, consult your NCA.

Pillar 1: 7 items
Pillar 2: 9 items
Pillar 3: 7 items
Pillar 4: 7 items
Pillar 5: 9 items
Pillar 1

ICT Governance Checklist

Governance is the foundation. Without clear accountability at the management body level and a documented framework, the remaining pillars cannot function effectively. For a detailed walkthrough of each article, see our ICT risk management guide.

Pillar 1 ICT Governance & Risk Framework
Management body has formally approved the ICT risk management framework and assigned clear accountability for its implementation Art. 5(2)
ICT risk appetite has been defined by the management body and documented within the framework Art. 5(2)
Management body members receive regular ICT risk reporting (at least quarterly) and keep their ICT knowledge up to date through training Art. 5(4)
ICT risk management framework is documented, includes a digital operational resilience strategy, and has been reviewed within the last 12 months Art. 6
An independent internal audit function reviews the ICT risk management framework at least annually, with findings reported to the management body Art. 6(6)
Adequate budget and resources are allocated to ICT security and operational resilience, as approved by the management body Art. 5(2)
A dedicated ICT security function or officer has been appointed with clear reporting lines to the management body Art. 6(4)
Pillar 2

ICT Risk Management Checklist

This pillar covers the operational content of the risk framework: identifying assets and risks, implementing protective controls, detecting threats, and planning for recovery. Each item maps to a specific article within the Art. 8-14 range.

Pillar 2 ICT Risk Management
Complete, continuously maintained register of all ICT assets exists, with each asset classified by criticality and mapped to the business functions it supports Art. 8
Dependencies between ICT-supported business functions, ICT assets, and ICT third-party providers are identified and documented Art. 8(4)
ICT security policies covering access control, encryption, network segmentation, and patch management are documented, enforced, and reviewed annually Art. 9
Change management procedures exist for all ICT system changes, with risk assessment and rollback procedures for critical system changes Art. 9(4)(e)
Detection and monitoring mechanisms are in place to identify anomalous activities, including log collection, analysis, and alerting for critical systems Art. 10
Business continuity plans and ICT disaster recovery plans exist with defined RTO, RPO, and MTPD for each critical or important function Art. 11
BCP and disaster recovery plans have been tested within the last 12 months, with results documented and used to update the plans Art. 11(5)
Backup policies define scope, frequency, and retention for all critical systems, and restoration procedures have been tested successfully Art. 12
Post-incident review process is in place, with lessons learned fed back into risk assessments, controls, and training programmes Art. 13
Pillar 3

ICT Incident Management Checklist

Incident management under DORA is defined by strict classification criteria and reporting timelines. The key challenge for most entities is meeting the 4-hour initial notification deadline, which requires pre-prepared templates and a well-rehearsed escalation process.

Pillar 3 Incident Management & Reporting
Documented incident management process exists with clear roles, responsibilities, and escalation paths for ICT-related incidents Art. 17
Incident classification framework is implemented using the criteria defined in CDR 2024/1772 (clients affected, duration, data loss, geographic spread, economic impact) Art. 18
Organisation can file an initial notification with the NCA within 4 hours of classifying a major incident, and no later than 24 hours of first detection Art. 19(4)(a)
ITS 2024/2956 incident reporting templates are prepared and pre-filled for rapid submission of initial, intermediate (72h), and final (1 month) reports Art. 19
All ICT-related incidents are logged and classified, not only major incidents, to support trend analysis and regulatory enquiries Art. 17(2)
Communication plan for major incidents covers internal escalation, client notification, and external communication with regulators and the public Art. 14
Voluntary reporting of significant cyber threats to the NCA has been considered and a process defined for doing so when appropriate Art. 19(2)
Pillar 4

Digital Resilience Testing Checklist

Testing validates everything else. Without a structured testing programme, your risk management framework, BCP plans, and security controls provide only theoretical assurance. For a detailed guide to building your testing programme, see our resilience testing guide.

Pillar 4 Resilience Testing
A documented, proportionate testing programme covering all critical ICT systems and applications is in operation and reviewed annually Art. 24
Vulnerability assessments and network security reviews are conducted at least annually on all critical systems, with findings tracked to remediation Art. 25
Scenario-based testing (including ICT disruption scenarios) is conducted regularly, validating business continuity and disaster recovery plans Art. 25
Source code reviews and performance testing are conducted on critical systems where feasible and proportionate to the entity's risk profile Art. 25
Testing results feed back into the ICT risk management framework, with findings driving updates to risk assessments and control improvements Art. 24(5)
Applicability for Threat-Led Penetration Testing (TLPT) under Art. 26 has been assessed with the NCA and documented Art. 26
If designated for TLPT: qualified external testers are engaged, NCA is notified, and TLPT has been performed within the last 3 years with results shared Art. 26–27
Pillar 5

Third-Party ICT Risk Management Checklist

Third-party oversight is one of DORA's most distinctive requirements. The Register of Information, mandatory contract clauses, and concentration risk assessment go well beyond what most existing financial regulation demands. For many entities, this pillar requires the most significant operational change.

Pillar 5 Third-Party ICT Risk
Register of Information on all ICT third-party arrangements is maintained continuously in the ITS 2024/2956 format, ready for NCA submission Art. 28(3)
Pre-contract risk assessments are conducted for all ICT providers supporting critical or important functions, covering security, continuity, and exit risks Art. 28(4)
Concentration risk from ICT providers is assessed across the entity's provider base and reported to the management body at least annually Art. 28(5)
All ICT contracts for critical or important functions include the mandatory clauses required by Art. 30(2): exit rights, audit access, SLAs, security requirements, sub-contracting notification Art. 30(2)
Exit strategies are defined for all critical ICT provider arrangements, with transition plans that can be activated if the provider relationship must end Art. 28(8)
Sub-contracting chains for critical ICT services are identified and documented, with sub-contractors included in the Register of Information Art. 29
Ongoing monitoring of ICT provider performance, security incidents, and compliance with contractual obligations is in place Art. 28(2)
Audit rights over ICT providers are exercised periodically, either directly or through pooled audits or third-party certifications Art. 30(2)(e)
Where critical ICT providers have been designated as CTPPs, the entity cooperates with the Lead Overseer's information requests and oversight activities Art. 31–44
Next steps

From Checklist to Action

A checklist identifies gaps. What matters is what you do next. Here is how to turn your assessment into a structured compliance programme.

Prioritise by risk and visibility. Not all checklist items carry equal weight. Items related to incident reporting (Pillar 3) and the Register of Information (Pillar 5) are the most visible to supervisors and should be addressed first if they are not yet in place. Governance items (Pillar 1) are foundational and often the first area reviewed during a supervisory engagement.

Assign ownership. Each gap should have a named owner with a clear deadline. DORA compliance is not an IT-only initiative; it requires coordination between ICT, risk, compliance, legal, and the management body. Use a task management system to track remediation and ensure visibility across teams.

Use a scored assessment. This checklist gives you a qualitative view. For a quantitative score, take the free DORA gap analysis, which scores your maturity across all five pillars on a 1-5 scale and identifies your weakest areas. The assessment takes about 3 minutes and requires no account. For additional context on each requirement, read our detailed 2025 compliance checklist guide.

Automate where possible. DORA compliance is not a one-time exercise. The regulation requires continuous maintenance of asset registers, ongoing incident monitoring, annual testing, and continuous Register of Information updates. Manual processes do not scale. DORA GRC automates the data collection, linkage, and reporting across all five pillars so your team can focus on decisions rather than data entry.

Review annually. The ICT risk management framework, testing programme, BCP plans, and Register of Information must all be reviewed at least annually. Build a compliance calendar that schedules these reviews, aligns them with your internal audit cycle, and ensures the management body receives timely reporting on the results.

FAQ

Frequently Asked Questions

No. DORA applies a proportionality principle under Art. 4, meaning the requirements are scaled to the entity's size, risk profile, and the nature of its services. Microenterprises and smaller entities may use a simplified ICT risk management framework under Art. 16 and have reduced testing obligations. However, all in-scope entities must comply with the core requirements for incident reporting, third-party risk management, and governance accountability. The checklist above covers the full set of requirements; smaller entities should identify which items apply at a reduced level of detail.

The ICT risk management framework must be reviewed at least annually under Art. 6. Business continuity and disaster recovery plans must be tested at least annually under Art. 11(5). The testing programme must be reviewed and updated at least annually. The Register of Information must be maintained continuously. In practice, most entities conduct a formal compliance review at least annually, with more frequent reviews triggered by significant incidents, material changes to the ICT estate, or new regulatory guidance from the ESAs or NCAs.

DORA is supervised by national competent authorities who have a range of enforcement tools. Consequences can include supervisory findings requiring remediation within a specified timeline, formal orders to cease non-compliant activities, public statements identifying the entity and the breach, administrative fines, and personal liability for members of the management body who failed in their governance obligations under Art. 5. The severity depends on the nature of the non-compliance, whether it was deliberate, and whether it contributed to harm.

DORA GRC provides a purpose-built platform for managing DORA compliance across all five pillars, including a free gap analysis tool that scores your readiness. Your national competent authority publishes guidance specific to your entity type and jurisdiction. The ESAs (EBA, ESMA, EIOPA) publish the Regulatory Technical Standards and Implementing Technical Standards that provide detailed implementation guidance. For a comprehensive overview of the regulation, see our DORA compliance guide.