DORA readiness checklist for financial entities

DORA is prescriptive in a way most financial-sector cyber regulation is not. It names the artefacts you must hold, the contract terms you must have, and the clocks you must meet. That makes it unusually checklist-able — which is the useful way to approach it.

1. Governance

• Management body has approved the ICT risk management framework and can evidence its involvement.
• Named accountability for ICT risk, with reporting into the management body.
• Evidence of management-level training on ICT risk.
• Digital operational resilience strategy documented.

2. ICT risk management framework

• Documented framework, reviewed at least annually and after major incidents.
• Inventory of ICT assets and their business functions, with criticality mapped.
• Identification of critical or important functions — this classification drives obligations throughout, so getting it wrong propagates everywhere.
• Protection and prevention controls: access, encryption, network segmentation, change management.
• Detection capability with defined alert thresholds.
• Response and recovery plans with defined objectives, tested.
• Backup policy and restoration procedures, with restoration tested.
• Learning process feeding post-incident findings back into the framework.

3. Incident management and reporting

• Classification methodology aligned to the regulatory criteria for major incidents.
• Reporting timelines built into the process — initial, intermediate and final reports each have their own deadline, and the first is short.
• Regulator reporting route established, with credentials in place before you need them.
• Client notification procedure where an incident affects them.
• Register of all incidents, including those assessed as not major, with the reasoning.

4. Resilience testing

• Testing programme covering vulnerability assessment, scenario testing and, where required, advanced threat-led penetration testing.
• Independence of testers evidenced.
• Findings tracked to closure with dates.
• Testing scope covering ICT systems supporting critical or important functions.

5. Third-party risk — the register

The requirement that most often causes late scrambling:

• Register of information on all contractual arrangements for ICT services, maintained in the prescribed structure and ready to submit.
• Identification of providers supporting critical or important functions.
• Pre-contract due diligence documented.
• Contractual terms covering access, audit and inspection rights; incident notification; service levels; data location; exit strategies and transition support.
• Concentration risk assessed — including where several providers resolve to one underlying dependency.
• Documented, tested exit strategy for each critical provider.

Two items reliably run late: the register in its required structure, and renegotiating contracts to add audit rights and exit support. Both depend on third parties, so both need starting long before the deadline you are working to.

6. Evidence to have ready

Approved framework and strategy; asset and function criticality mapping; incident register and sample reports; testing reports with remediation evidence; the register of information; contracts showing required clauses; management body minutes.

Key takeaways

• Critical-or-important function classification drives everything downstream.
• The register of information is prescriptive and takes longer than expected.
• Contract renegotiation depends on third parties — start early.
• Keep a record of incidents you decided were not major, with reasoning.