DORA applies from today. The first 90 days matter most.

Today, January 17, 2025, the Digital Operational Resilience Act applies. After two years of preparation programs, gap analyses, and steering committees, financial entities across the Union are now subject to a regulation that asks a deceptively simple question: can your critical services withstand, respond to, and recover from ICT disruption, and can you prove it?

If your program is behind, you are in wide company. Our advice is not to attempt everything at once, but to spend the first 90 days on the obligations that are hardest to improvise later. The distinction that matters here is between what can be produced under pressure and what cannot. A policy document can be written the week before an inspection. A two-year-old incident timeline cannot be conjured from logs that were never kept. Spend the first quarter on the second kind.

First: know your dependencies from traffic, not documents

DORA's register of information demands a complete view of ICT third-party arrangements, mapped to the critical functions they support. Most institutions have built this register from contracts and interviews. The gap between that register and reality is where supervisory findings will live. Reconcile it against what actually flows: every external dependency of a critical service passes through your integration layer, and that layer can enumerate them without asking anyone's memory to cooperate.

The reconciliation itself is often the most revealing exercise of the entire program. The dependencies that appear in live traffic but not in the register are the ones nobody is managing: the provider a team wired in directly, the feed that outlived the project that commissioned it, the "temporary" integration from three years ago. Each is both a compliance gap and a genuine operational risk, and you cannot close either until you know it is there.

Second: make incident timelines reconstructable

The incident reporting regime imposes tight deadlines, with initial notification within hours of classifying a major incident. The institutions that will meet those deadlines are not the ones with the best template but the ones who can reconstruct what happened from records: which services were affected, which transactions, which third parties were involved. If assembling that picture takes three days of log archaeology, the timeline is already missed.

Under DORA, evidence has a deadline. Anything you cannot produce quickly, you effectively do not have.

The trap here is that most institutions can, given enough time, reconstruct almost anything, and so they assume they are ready. The deadline is the whole point. Evidence that takes a week to assemble is worthless against a clock measured in hours. The work in the first 90 days is not to make reconstruction possible; it is to make it fast enough to matter, which usually means the records have to exist already, in one place, before the incident begins.

Third: rehearse one failover, end to end

Resilience testing obligations phase in over time, but supervisors are already asking a basic question: when did you last prove that a critical service survives the loss of a key provider? Pick one service, fail over one dependency, and record everything. The exercise will surface more real findings than a quarter of documentation review, and the record itself becomes evidence.

Choose the exercise for what it will teach, not for what will look good in a report. The most valuable failover to rehearse is usually the one the team is least confident about, because that is where the undocumented assumptions and the broken runbooks are hiding. A drill that goes perfectly proves less than one that surfaces three problems you can now fix before a real incident finds them for you.

What can wait, briefly

Perfecting policy documents, harmonizing terminology across entities, and tooling debates can all survive the spring. The register, the timelines, and one rehearsed recovery cannot. Waygrid customers in financial services start with an advantage here: the platform already records every interaction and dependency with multi-year retention. But the principle holds on any stack. Begin where the evidence is, and the rest of the program has something solid to stand on.