DORA Compliance Checklist: Structured Implementation Across All 5 Pillars

A complete checklist covers all five DORA pillars: a documented ICT risk management framework, a working ICT incident reporting process, completed resilience testing, a current third-party register with compliant contract clauses, and participation in industry-wide cyber threat information sharing. A checklist limited to technical IT security alone doesn't fully cover the supervisory requirements.

A reliable self-assessment checks not just whether an item is formally done, but whether the underlying evidence actually exists and is current; an item marked "complete" without an up-to-date log effectively counts as open under review. An external second opinion tends to surface gaps more reliably than self-assessment alone, particularly for items that feel routine internally.

Commonly underestimated items are the ICT third-party information register, since it requires ongoing maintenance rather than a one-time setup, and renegotiating existing provider contracts to add required clauses. Participation in cyber threat information sharing is also frequently forgotten, since unlike the other pillars it requires external engagement rather than internal process change.

A checklist gives a binary yes/no read per requirement and is good for a quick overview. A gap analysis goes deeper: it also assesses the quality and effectiveness of what's in place, not just whether it formally exists, and prioritizes gaps by risk relevance. A checklist is enough for an initial status check; actual implementation planning needs a gap analysis.

An annual review is a sensible minimum cadence, but should be supplemented with event-driven updates: new regulatory technical standards, material changes to the IT landscape, or after any major ICT incident. A checklist that hasn't been revised since its initial creation rarely still reflects the current regulatory state.

Each item marked complete should have a concrete artifact behind it, such as a test log, a signed contract addendum, or a version history of a policy document, rather than just an internal note. That evidence should be stored centrally and be findable, since a review rarely leaves time to search across scattered filing systems afterward.