Incident Reporting Timelines Explained

DORA reporting timelines are set in the applicable technical standard, and they are organised by phase rather than by a single deadline for the whole report. The initial phase is sent early, while the incident is still being understood, the intermediate phases follow as the position develops, and the final phase follows once the incident is closed and the analysis is complete. The purpose of this structure is to give the authority early notice without demanding a complete account before the facts exist. A firm that waits until it has the full picture before sending anything has misunderstood the timeline.

A single deadline for a complete report would create a dilemma. Send early, and the report would be full of guesses. Send late, and the authority would learn of a major incident long after it happened. Phased timing resolves that dilemma by asking for different things at different stages. Early phases ask for what is known, intermediate phases ask for progress, and the final phase asks for the completed analysis. Each phase therefore has a timing logic of its own. The initial phase is urgent because its value lies in early warning. The final phase is less urgent in the same sense, because its value lies in completeness and in lessons that can only be drawn once the incident is over.

A firm handles incomplete facts by stating them as incomplete. An initial report that says the cause is under investigation, the affected groups are still being confirmed, and recovery is in progress is more useful, and more honest, than a report that fills those gaps with plausible assumptions. The same applies to intermediate reports. Where a figure is an estimate, the report should say so and give its source, so that a later correction is understood as a refinement rather than a contradiction. Firms sometimes fear that admitting uncertainty will look weak, but an authority that receives a candid early report is better placed to judge the incident than one that receives a confident report that later proves wrong.

Meeting an external timeline depends on an internal timetable that is tighter than the external one. The firm needs time to gather the log, to check the service account against the technical account, to have the report reviewed, and to send it through the right route. If the internal process starts only when the external phase is due, it will usually be late or rushed. A practical approach is to set internal milestones for each phase, with a named owner and a reviewer, and to rehearse the first phase so the team knows how long drafting and review actually take. That rehearsal often reveals that the first phase takes longer than expected, which is useful knowledge to have before a real incident rather than during one.

If a phase will be delayed, the firm should still communicate, through the route available to it, rather than letting silence create its own message. If a phase needs correction, the correction should be sent promptly and should explain what changed and why, rather than quietly replacing the earlier version. Both actions protect the firm's credibility, because they show that the firm is managing its reporting rather than drifting. A delayed or corrected report is not, by itself, a sign of failure. Incidents are messy, and reporting systems should expect some corrections. What matters is whether the firm recognised the problem, acted on it, and kept the record straight.

After an incident, the reporting timeline itself is worth reviewing. The firm can ask whether each phase went out when it should have, whether the internal timetable held, and whether any phase was rushed or delayed by a process problem rather than by the incident itself. That review may reveal a template that asks for information the log does not capture, a reviewer who was unavailable, or a route that required a login nobody held. Fixing those problems improves the next incident's reporting more reliably than exhorting the team to be faster. Timelines, in this sense, are not merely deadlines to meet. They are a diagnostic tool for the firm's own incident process.