Preparation for and planning of DORA project implementation
This domain tests how you scope and sequence a DORA implementation programme, assign accountability and convert legal obligations into an executable plan.
Core rules and concepts
- Start with a structured gap analysis against each DORA chapter, mapping current policies, controls, contracts, incident processes and testing arrangements to the regulation.
- Establish a governance structure: an accountable executive, a programme lead, and workstreams for ICT risk, incident reporting, testing, third-party risk and information sharing. Legal, procurement, compliance and business owners must be involved early.
- Build a proportionate roadmap with dependencies. The register of information is often an early priority because it underpins risk assessment, concentration analysis, testing scope and contract remediation.
- Identify policy updates, data-quality work, contract renegotiations, reporting-process changes, training and evidence requirements. Record owners, deadlines and acceptance criteria.
- Engage supervisors and use final regulatory technical standards and implementing technical standards to refine timelines; do not wait for every detail before starting.
Worked example
An investment firm begins its DORA programme by building the register of information before rewriting its ICT risk policy. The reasoning: the register reveals which ICT third-party providers support critical functions, which contracts need DORA clauses, and which systems fall within testing scope. Sequencing the register first prevents the policy and testing plans from being built on incomplete dependency data.
Traps that cost marks
- Running DORA as an IT-only project and leaving legal, procurement and business continuity teams until late.
- Treating the register as a procurement list rather than a risk and oversight tool.
- Planning without explicit owners, evidence or dependency sequencing.
- Assuming proportionality means exemption for smaller entities.