DORA Implementation Timeline

DORA applies from 17 January 2025, and that date is the anchor for its timeline, but it is not the whole timeline. Before application, firms needed to understand scope, map services, build ICT risk arrangements, prepare incident processes, design testing, and review provider contracts and registers. After application, those arrangements live in operation: incidents are handled and reported, tests are run and acted on, provider relationships are monitored, and registers are kept current. Technical standards apply on their own stated dates, supervisory expectations develop over time, and each incident or test can trigger revision, so implementation continues as a rolling programme rather than ending at a launch moment.

A wealth platform illustration helps, and it is only an illustration. Launching a new portfolio service after application does not mean starting DORA from scratch, but it does mean revisiting the service map, the provider picture, and the test plan for that service, because the timeline for that service begins when the service begins.

Readiness work before application was, in essence, mapping and building. Mapping meant identifying in-scope entities, naming important services, tracing systems and providers behind each service, and understanding where group arrangements changed the picture. Building meant putting ICT risk governance in place, preparing incident classification and reporting paths, designing a proportionate testing programme, reviewing provider contracts for oversight and exit terms, and creating a register of provider information. Readiness also meant rehearsal: running an incident exercise or a recovery test before duties were live, so that weaknesses surfaced in a rehearsal rather than in a real disruption. Firms that treated readiness as a documentation project, without rehearsal, often found that their first live incident exposed gaps in decision making and information flow.

When DORA started to apply, its duties moved from preparation to live obligation. ICT risk arrangements had to operate, not merely exist on paper, incident processes had to be usable under pressure, testing had to be carried out and acted on, provider oversight had to be ongoing, and registers had to reflect current relationships. The change is subtle but important: a policy that was acceptable as a draft during readiness becomes a working arrangement that supervisors, customers, and providers will judge by its operation. Governance also shifts at this point, because senior management moves from approving a programme to overseeing a live risk picture, with incidents and test findings arriving as ordinary business rather than as project milestones.

Technical standards give the timeline a staggered rhythm, because each standard applies on the date stated in that standard. A firm therefore cannot mark a single date for full implementation and stop there; it needs a standards tracker that records each applicable standard, its application date, and the internal owner for the affected process. When a new standard arrives, the affected incident template, register, test approach, or provider process needs revision, and that revision needs its own timetable. The staggered rhythm is a feature, not a flaw: it allows detail to be developed and adopted in stages, but it rewards firms that track standards as a standing discipline and penalises firms that treat standards as a one-off reading task.

The ongoing rhythm is set by incidents, tests, provider changes, and supervision, each of which can trigger revision at an unpredictable moment. An incident may reveal a classification gap or a reporting weakness, a test may reveal a recovery step that does not work, a provider change may alter a dependency, and a supervisory finding may require remediation. A rolling programme accommodates that rhythm by keeping service maps, playbooks, test plans, and registers as living documents, with owners and review dates, rather than as frozen artefacts. Planning should therefore focus less on a single future date and more on the cadence of review: how often each service map is checked, how test findings are tracked to closure, and how provider changes are reflected in the register.

Planning from here begins with the current picture, not with an idealised past. List the services, the standards that touch each one, the tests and incidents that have changed each one, and the provider relationships behind each one, and then identify the next revision each item needs and who owns it. That list becomes a rolling plan, reviewed when a standard changes, when a service changes, when a provider changes, and when an incident or test produces a lesson. The plan should also include a horizon scanning habit, so that new ESA publications and supervisory themes are noticed early. A timeline planned in this way will never look tidy, because resilience work is untidy, but it will be honest about what is current, what is due, and what has been learned.