A reporting deadline is only as generous as the work that has to happen before it. Under DORA, a financial entity has four hours to file an initial notification once an incident has been classified as major. The four hours are not the difficult part. Getting to classification is.
Consider an insurer whose policy administration platform starts returning errors on a Monday afternoon. Some quotes complete, some fail. The pattern is not obvious. Engineering thinks it is a failed integration. Operations thinks it is a data issue. Nobody has yet used the word major.
Meanwhile the questions that decide the reporting clock are sitting unanswered. How many clients are affected? Has any data been lost? Is a critical function down, or degraded? Who is entitled to decide that this meets the classification threshold, and are they in the building?
This is where DORA major incident reporting timelines stop being a compliance diagram and become an operational problem. The regulation sets the deadlines. What determines whether a firm meets them is how quickly it can assemble the facts those deadlines assume it already has.
A reporting obligation is met during the incident or not at all.
What Are The DORA Major Incident Reporting Timelines?
DORA requires financial entities to report a major ICT-related incident to their competent authority in three stages: an initial notification, an intermediate report and a final report. The joint technical standards on major incident reporting set the time limits, and they have applied since 12 March 2025.
The European Banking Authority states the timings as an initial notification four hours after classification, an intermediate report at 72 hours and a final report at one month. DORA itself, Regulation (EU) 2022/2554, entered into application on 17 January 2025.
One detail is worth checking rather than assuming. Article 19 of DORA does not set the time limits itself. It defers them to the technical standards made under Article 20, and published summaries word the reference points for the 72-hour and one-month clocks differently. Confirm the exact reference points and the reporting templates against the final technical standards and your competent authority, rather than against a summary.
The Clock Does Not Start When The Incident Does
The four-hour clock runs from classification, not from the first alert. That sounds like a concession. In practice it is the opposite, because classification is an act somebody has to perform, and firms rarely time how long it takes them to perform it.
In the insurer example the errors began at 14:10. If classification happens at 16:30, the notification is due at 20:30 and the firm has spent two hours and twenty minutes on a step that appears nowhere in the regulation as a deadline. Those minutes are invisible to the timeline and entirely visible in the outcome.
Classification also cannot be rushed honestly. It depends on knowing the number of clients affected, the duration, the data involved, whether a critical function is down and whether other entities are touched. Those are facts, and facts take time to assemble unless something was collecting them from the start.
What Does The Initial Notification Actually Require?
The initial notification is not a holding message. Article 19 requires it to carry the information the competent authority needs to determine the significance of the incident and assess possible cross-border impacts.
That means, within four hours of classification, a firm is describing what happened, what is affected, how many clients or counterparties are involved and whether the impact crosses a border. At that point the incident is usually still running and the people who know the answers are the people fixing it.
The intermediate report follows when the status of the incident has changed significantly. The final report comes when root cause analysis is complete and actual figures replace the estimates in the earlier submissions. Each stage assumes the firm can show its working.
Estimates Become Commitments
Figures given in the initial notification are estimates, and the regulation expects the final report to replace them with actuals. That is reasonable. It also means the first numbers a firm produces under time pressure will be compared, in writing, with the numbers it produces after analysis.
A firm that estimated 400 affected clients and later reports 4,000 has a conversation ahead of it. So does a firm that cannot explain how either number was reached. The gap between the two is a question the regulator is entitled to ask, and the only satisfying answer is a record showing what was known at each point and why the estimate moved.
Why Reconstruction Is The Expensive Route
Most firms can produce a DORA report. The question is what producing it costs them and how defensible it is when finished.
Reconstructing a report after the fact usually means someone assembling a narrative from a monitoring tool, a service management ticket, a chat channel, two email threads and the recollection of people who were busy at the time. That work happens in the week after an incident, on top of the remediation the incident created.
It also produces a weaker document. A reconstructed timeline is an account of what people remember deciding. A recorded timeline is evidence of what was decided and when. Both may say the same thing. Only one of them was written before anyone knew how the story ended.
This is the same gap that shows up in operational resilience during a live incident, where the minutes between detection and declaration disappear because nothing was capturing them.
Challenging The Assumption That Reporting Is A Compliance Task
Reporting is usually owned by compliance or risk, sits in a policy, and is tested by asking whether the firm knows the deadlines. By that measure most firms in scope are ready. They know the deadlines. They have templates. Someone has run a workshop.
The assumption underneath is that reporting is a task performed after an incident. It is not. Every input to the initial notification is generated during the incident, by people who are not thinking about reporting, in the first two hours, under pressure.
Which makes reporting readiness an operational property rather than a documentary one. A firm is ready if its response process happens to capture, as a by-product, the things the report will ask for. If it does not, no amount of template preparation closes the gap, because the information was never written down while it was true.
A Practical Test For DORA Reporting Readiness
Take your last significant ICT incident, whether or not it was classified as major. Then work backwards through five questions:
- At what time was the incident classified, and can you evidence that time rather than estimate it?
- How long passed between the first alert and that classification, and where is that interval recorded?
- Who made the classification decision, and is their authority to make it written down?
- Could you state the number of affected clients at the four-hour point, or only afterwards?
- If your initial estimate had proved wrong by a factor of ten, could you show why you believed it at the time?
A firm that can answer all five from records rather than memory is reporting-ready. A firm answering from memory is relying on the next incident being small enough to remember clearly.
How Crises Control Supports Incident Evidence
Crises Control is an Operational Incident Coordination Platform. It sits between the systems that detect a problem and the people who have to respond to it. Monitoring platforms detect operational issues without coordinating the people, tasks or decisions needed to resolve them. Communication tools send notifications without coordinating ongoing updates, acknowledgements or response activities. Email and spreadsheets create delays and make an accurate incident record difficult to maintain.
The approach is not to replace those systems. It is to connect them, so response teams can coordinate every stage of an incident from one operational view while keeping the technology already in place.
For reporting specifically, the useful property is that the record is a by-product of the response rather than a separate exercise. Incident management software maintains a complete incident timeline from activation through resolution, with communications, updates and decisions recorded chronologically as the incident runs. The operational record covers communications, acknowledgements, updates, decisions and response activities, and supports governance, reporting, compliance and post-incident review.
That record is what turns compliance management from an after-the-fact assembly job into a read of something that already exists, and it is the same evidence base that incident reporting and wider operational resilience for financial services obligations draw on.
The platform does not classify an incident as major. That is a judgement made by a named person against a written threshold. Its role is to make sure that when the judgement is made, the facts it depends on are already recorded, and the time it took is visible rather than lost.
Reporting Readiness Is Built Before The Deadline
The deadlines in DORA are fixed and public. What varies between firms is how much work sits behind each one, and that work is decided long before a deadline is in view.
The place to start is the interval nobody measures: first alert to classification. Time it on a real incident, or a realistic exercise, and the number will tell you more about reporting readiness than any template review. To see how an incident record builds itself while the response is running, request a walkthrough with the Crises Control team.
Frequently Asked Questions
What are the DORA major incident reporting timelines?
DORA major incident reporting timelines cover three stages: an initial notification, an intermediate report and a final report. The European Banking Authority states these as four hours after classification, 72 hours, and one month. The technical standards that set them have applied since 12 March 2025, and firms should confirm the exact reference points and templates with their competent authority.
When does the four-hour clock start?
The four-hour clock starts when the incident is classified as major, not when it is first detected. That makes classification the decisive step in DORA major incident reporting timelines, because any time spent reaching it sits outside the deadline but inside the incident. Firms that do not measure the interval between first alert and classification are usually surprised by it.
Does DORA Article 19 set the deadlines?
No. Article 19 requires financial entities to report major ICT-related incidents to the relevant competent authority, but it defers the time limits to the technical standards made under Article 20. This is why the deadlines should be checked against the standards rather than the regulation text alone.
What goes into a DORA initial notification?
Article 19 requires it to contain the information the competent authority needs to determine the significance of the incident and assess possible cross-border impacts. In practice that means the nature of the incident, what is affected, the scale of client impact and whether the effects cross a border, submitted while the incident is often still running.
What happens if the initial estimates turn out to be wrong?
The final report is expected to replace estimates with actual impact figures, so a change between the two is anticipated rather than a problem in itself. What matters is being able to show why the original estimate was reasonable at the time. That depends on having a contemporaneous record rather than a reconstruction.
This article was drafted with AI assistance and reviewed by the Crises Control team. Featured image: AI-generated.
