DORA Compliance Checklist

Pillar 1, ICT risk management (Article 6)

• Documented ICT risk-management framework approved by the management body.
• ICT risk tolerance defined and linked to business strategy.
• Inventory and classification of ICT-supported business functions and assets.
• Protection and prevention controls (access management, encryption, patching).
• Continuous monitoring and anomaly-detection mechanisms in place.
• ICT business-continuity policy and disaster-recovery plans, tested regularly.
• Backup, restoration, and recovery procedures with defined RTOs/RPOs.
• Post-incident review process feeding lessons back into the framework.
• Board-level ICT knowledge and training maintained.

Pillar 2, ICT-related incident reporting (Articles 17–23)

• Process to detect, log, and manage all ICT-related incidents.
• Classification methodology aligned to the RTS criteria (clients affected, duration, data loss, economic impact).
• Procedures to identify major incidents that trigger reporting.
• Templates and channels for initial, intermediate, and final reports to the competent authority.
• Timelines and escalation paths documented and rehearsed.
• Optional process for voluntary reporting of significant cyber threats.

The classification step is where most programmes are underprepared. Commission Delegated Regulation (EU) 2024/1772 sets a concrete methodology: an incident is major if it meets at least two of the listed materiality criteria, or a single criterion combined with an economic-impact threshold of EUR 100,000 in gross direct and indirect costs. Once classified, the clock is tight: an initial notification within four hours of classification (no later than twenty-four hours after the entity first became aware), an intermediate report within seventy-two hours, and a final report within one month. See our major-incident definition for the full criteria list, and the incident classifier to test a real scenario against these thresholds before you need it live.

Pillar 3, Digital operational resilience testing (Articles 24–27)

• Risk-based testing programme covering all ICT systems supporting critical or important functions.
• Annual testing of critical systems (vulnerability assessments, scans, scenario tests).
• Process to remediate and re-test findings.
• Threat-led penetration testing (TLPT) scheduled at least every three years (significant entities).
• Independent, qualified testers engaged where required.

Pillar 4, ICT third-party risk management (Articles 28–30)

• Register of information covering all ICT third-party arrangements maintained and reportable.
• Pre-contract due diligence and concentration-risk assessment.
• Mandatory contractual provisions (access, audit, exit strategy, sub-outsourcing, service levels).
• Ongoing monitoring of third-party performance and risk.
• Documented exit and substitutability strategies for critical/important functions.

Pillar 5, Information sharing (Article 45)

• Decision recorded on whether to participate in threat-intelligence sharing arrangements.
• If participating: arrangements protect confidentiality and comply with data-protection law.

How to use this checklist

Work through each pillar, assign an owner and evidence location to every item, and rate maturity honestly. Items you cannot evidence become your remediation backlog. For a scored view of the same ground, take the DORA Readiness Score; for the underlying obligations, see the DORA requirements. When you need external validation, a formal gap assessment turns the checklist into an auditable baseline.