The Dispatch

Issue #001 — April 2026 — DORA

Why Your DORA Programme Will Fail Without a Delivery Manager

DORA is not an IT audit. It is a programme. And most organisations are treating it like the former while paying the price of the latter.

By January 2025, financial entities across the EU were required to comply with the Digital Operational Resilience Act. The regulation is clear on what it demands: ICT risk management, incident classification and reporting, resilience testing, third-party oversight, and information sharing. What it does not tell you is who should own the cross-functional work of getting there.

In most organisations, DORA compliance lands with a Chief Risk Officer, a CISO, or a compliance team. They produce frameworks. They write policies. They run gap analyses. All of that is necessary. None of it is sufficient. Because what DORA actually requires is change — change to how teams operate, how vendors are managed, how incidents are escalated, how recovery is tested. That change requires someone who can run a programme, not just a project.

The gap nobody talks about

The typical DORA failure mode is not a lack of awareness. It is a lack of delivery ownership. Workstreams get defined. Accountable teams get named. But then the quarterly review rolls around and everyone has made 60% progress on everything, which means nothing is done. Dependencies between the ICT register, the resilience testing schedule, and the third-party risk reviews are not tracked. No one is removing blockers. No one is escalating the things that need escalating.

This is precisely what a Delivery Manager does. Not manage tasks. Remove the things that stop the programme from moving forward.

What DORA-compliant delivery looks like

• ICT risk as a live artefact. The register is not a document you file. It is a working tool that changes when your architecture changes. Someone needs to own that discipline.
• Incident response that actually gets tested. DORA requires TLPT (threat-led penetration testing) and regular resilience exercises. These do not happen because someone wrote a policy. They happen because someone schedules them, tracks dependencies, and follows through.
• Third-party oversight that scales. Critical ICT third parties require contractual controls, exit strategies, and monitoring. Across 20 or 50 vendors, this is a programme management problem, not a legal review.
• Reporting that regulators can trust. The data behind DORA submissions needs to be defensible. That means the processes feeding it need to be consistent, the people accountable for them need to understand what is expected, and someone needs to be checking.

What this means for you

If your DORA programme is running behind schedule, or if you are not confident your team could demonstrate operational resilience to a regulator today, the answer is rarely more documentation. It is usually better ownership of the cross-functional delivery work that sits between your risk team, your IT organisation, and your third-party relationships.

That is the work I do. Embedded, temporary, and exits cleanly when the programme is in shape.