DORA's incident reporting regime is built on clocks: classify a major ICT incident promptly against the significance criteria, file the initial notification within the regulatory window, then deliver intermediate and final reports as the picture matures — root cause, impact, remediation. The clocks are fixed; what varies is how much of the deadline you spend finding facts. Teams that meet DORA deadlines comfortably share one property: the evidence the reports need already exists, connected, before the incident happens.
This guide covers the classification-and-deadline mechanics, the failure pattern that burns the reporting window, and the evidence architecture that lets a team classify fast and report accurately without an email-driven forensics scramble.
The regime has three reporting stages — initial notification shortly after classification, an intermediate report as understanding develops, and a final report with root cause and remediation detail. Everything hinges on the classification step: an incident is assessed against significance criteria including the criticality of services affected, number and share of clients impacted, geographic spread, duration, and data losses. Two operational implications follow. First, classification must happen fast, which means the criteria's inputs must be measurable on demand. Second, misclassification cuts both ways — under-classifying invites supervisory findings; over-classifying floods your own process. The discipline is a documented triage: every candidate incident assessed against the criteria, with the assessment recorded whichever way it goes.
Post-incident timelines at software-heavy firms show the same pattern: an hour to stabilize, a day to understand, and most of the reporting window consumed reconstructing the story — which release introduced the failure, who approved it, what testing said, when detection fired, what remediation is underway. The facts exist, scattered across deploy logs, chat threads, CI systems, and ticket trackers, none referencing each other. The team writes the report from interviews under deadline, and the intermediate report contradicts the final one because reconstruction kept revising. None of this is an incident-response failure; it's an evidence-architecture failure surfacing at the worst time.
Change context on demand. Every production change rides a structured change request scoped by system, with policy-recorded approvals. "What changed on the payments platform in the 72 hours before onset" becomes a filter — the first question every report asks, answered in minutes.
Validation state, linked. Test executions and CI/CD and monitoring signals bound to those releases show what was verified and what the pipeline knew — the "could this have been caught" section, from records instead of recollection.
Remediation as live status. Fixes ride tracked work items under SLA policies with escalation, so the intermediate report quotes current state and the final report shows verified closure — no stale summaries.
Assembly, not authorship. The Release Compliance Dossier holds the connected chain per release; report drafting becomes narrative over evidence, and the supervisory follow-up ("provide the change and testing records behind this incident") is already answered. Compliance objectives keep the whole posture visible to your ICT risk function between incidents.
Run the exercise quarterly: pick a past incident (or simulate one on a critical service), start the clock, and produce the initial notification's facts plus the change-and-testing story within your target window. Time the classification inputs separately — client impact and service criticality numbers are the usual bottleneck, and fixing their availability is cheap before an incident and impossible during one. Teams that drill report a consistent result: the writing was never the problem; the finding was, and structural evidence removes it.
DORA's incident clocks don't measure how fast your team writes — they measure how prepared your evidence was before the incident. Classify from measurable criteria, report from release-linked records, track remediation as workflow state, and the deadlines become schedule items instead of crises.
Prompt classification against significance criteria, an initial notification on a tight regulatory clock, then intermediate and final reports covering root cause, impact, and remediation as understanding matures.
Assessment against criteria including criticality of the services affected, the number and share of clients impacted, geographic spread, duration, and data losses. The triage assessment should be recorded whichever way it goes — undocumented 'not major' calls are their own exposure.
The window gets consumed reconstructing evidence — which release introduced the failure, who approved it, what testing showed, what remediation is underway — from scattered systems under deadline. The writing was never the bottleneck; the finding was.
Change history scoped by system with recorded approvals answers 'what changed' in minutes; test executions and monitoring signals show the validation state; and SLA-tracked remediation gives intermediate reports live status instead of stale summaries.