The three blocks that consumed most of the time.
At four of the six financial institutions where we ran DORA readiness in 2024-2025, the same three domains sat on the critical path: ICT risk management framework, third-party risk, and the incident reporting chain to DNB. Not the threat-led penetration testing, that is a finite, recurring obligation the market adapted to quickly.
1. ICT risk management framework, from paper to operation.
Most organisations already had an ISO 27001- or NIST-based framework. DORA additionally requires an explicit link between ICT risks and business services. That mapping was usually absent: they knew which systems existed, but not which business function would stop if a system failed. That mapping turned out to be roughly ten percent of the entire DORA trajectory.
2. Third-party risk, the register debate.
The ICT third-party providers register sounds simple. In practice: what counts as a “critical” provider? A SaaS for email archiving? A hyperscaler for the production database? The norm provides criteria, but classification remains a policy choice. For one client the inventory phase alone took three months.
3. Incident reporting, the chain to DNB.
The DORA reporting template resembles the ENISA-NIS2 template, but differs in detail. More importantly: the chain from detection (SOC) → classification (Chief Information Security Officer (CISO) office) → reporting (compliance) → submission (DNB portal) did not run smoothly across all organisations. Drills helped.
What I would advise differently.
- Start with the business-service mapping, not the framework. The framework already exists. The mapping does not.
- Concentrate third-party classification in one meeting with procurement, risk and IT. Decide there; refine later.
- Run at least two incident drills before the deadline. Not to draft the report, but to test the chain.