DORA Incident Reporting: The 4, 24, and 72 Hour Clocks

A major ICT-related incident under DORA generates three reports on three separate clocks, and the deadlines are set by Commission Delegated Regulation (EU) 2025/301, not by the regulation's headline text. The initial notification goes in as early as possible and in any case within four hours of classifying the incident as major, and no later than 24 hours from the moment the financial entity became aware of it. The intermediate report follows within 72 hours of the initial notification, even where nothing about the incident has changed. The final report is due no later than one month after the intermediate report, or after the latest updated intermediate report where more than one was filed.

The four-hour clock is the one that catches teams out, because it starts at classification, which is a judgment your team makes, and not at containment, which is the moment most incident plans are built around.

Everything below works out what that means for a runbook, how classification actually happens, and how these clocks sit alongside the GDPR and NIS2 obligations that fire from the same incident.

Key takeaways

• A major ICT-related incident generates three reports on three separate clocks, set by Commission Delegated Regulation (EU) 2025/301 rather than by DORA's headline text.
• The four-hour initial notification starts at classification, a judgment your team makes, and not at containment, which is what most incident plans are built around.
• Both limits bind. Classifying slowly buys nothing, because the 24-hour outer bound runs from awareness regardless; it only compresses the window between the decision and the deadline.
• Classification is where the real work sits. If your telemetry cannot answer how many EU clients were affected and for how long inside an hour, your four-hour clock is really a one-hour clock.
• One incident routinely triggers several regimes on clocks that do not align. Keep one incident record with several parallel determinations, each with its own owner.

The three reports and their clocks

Article 5 of the delegated regulation sets the schedule.

Initial notification. As early as possible, and in any case within four hours of the classification of the incident as a major ICT-related incident, and no later than 24 hours from the moment the entity became aware of the incident. Note that both limits bind: classifying quickly does not extend the 24-hour outer boundary, and taking a long time to classify does not extend it either.

Intermediate report. At the latest within 72 hours of the initial notification, and it is due even where the status or the handling of the incident has not changed. There is no "nothing to report" exemption, which is deliberate. Supervisors want a heartbeat, not only news.

Final report. No later than one month after the intermediate report, or after the latest updated intermediate report where several were submitted. Complex incidents produce updated intermediate reports, and each one restarts the clock on the final.

Article 5(4) is narrower than it is usually described: where a time limit falls on a weekend day or a bank holiday in the entity's Member State, the report may be submitted by noon of the next working day, not by the end of that day. Article 5(5) then withdraws even that, for the initial notification and the intermediate report only, from credit institutions, central counterparties, operators of trading venues, and other entities identified as essential or important under Article 3 of NIS2. If you run a bank, the weekend is not a mitigating circumstance.

The clock that hurts: four hours from classification

Most incident response plans are built around a containment-first sequence: detect, triage, contain, then notify. DORA inverts part of that. Once your own classification process concludes that an incident is major, you have four hours, and containment is very often not finished.

Two consequences follow.

First, the initial notification has to be a document your on-call can produce under pressure with incomplete information. That means a template with the fields pre-mapped to the reporting form, a named person authorized to submit it without waiting for a committee, and a decision rule for what goes in the fields you cannot yet answer. Teams that write this template during an incident file late.

Second, and less obvious: because the clock starts at classification, an organization that classifies slowly is not safer. The 24-hour outer bound from awareness runs regardless, so slow classification does not buy time, it just compresses the window between the decision and the deadline. We have watched an entity spend nineteen hours deciding whether an incident was major and then have five hours of runway left rather than twenty-four.

Classification is where the real work sits

Article 18 of DORA sets the criteria financial entities use to classify an incident as major:

• The number and relevance of clients or financial counterparts affected, and whether the incident has a reputational impact
• The duration of the incident, including service downtime
• The geographical spread, particularly where more than one member state is affected
• Data losses affecting availability, authenticity, integrity, or confidentiality
• The criticality of the services affected, including the entity's transactions and operations
• The economic impact, in direct and indirect costs and losses

The European Supervisory Authorities set the materiality thresholds that operationalize those criteria. The practical point for a security team is that classification is a defined procedure with inputs your monitoring has to be able to supply quickly: how many clients, for how long, in which countries, which services. If your telemetry cannot answer "how many EU clients were affected and for how long" inside an hour, your four-hour clock is really a one-hour clock with three hours of data archaeology in front of it.

Build the classification worksheet before you need it, rehearse it in a tabletop, and store it with the runbook. This is the single highest-value hour of preparation available for DORA incident reporting, and it costs nothing but attention.

Significant cyber threats, and voluntary notification

DORA also lets entities notify significant cyber threats voluntarily, assessed against the criticality of the services at risk, the number and relevance of clients or counterparts targeted, and the geographical spread of the areas at risk. This is a threat, not an incident: something aimed at you that has not yet produced a reportable event.

Voluntary means voluntary, and the decision is a judgment call about the value of early sector-wide warning against the cost of reporting something that may come to nothing. Entities with a mature threat intelligence function tend to use it. Entities without one should not build a program around it before they can reliably file the mandatory reports.

How DORA's clocks sit with GDPR and NIS2

One incident routinely triggers several regimes, and the clocks do not align.

GDPR requires notification of a personal data breach to the supervisory authority without undue delay and where feasible within 72 hours of becoming aware of it. That is a personal-data trigger measured from awareness. DORA's trigger is operational: an incident affecting the security of network and information systems, classified as major, whether or not personal data is involved. An availability incident with no data exposure can be a DORA major incident and not a GDPR breach at all. A small exposure of customer records can be a GDPR breach and fall below the DORA thresholds.

NIS2 adds its own early-warning and reporting duties for essential and important entities in the sectors it covers, on national timelines, and where an entity is caught by both regimes, DORA operates as the sector-specific rulebook for the financial obligations.

The failure mode is not ignorance of any one clock. It is a single triage process that produces one answer, when three regimes are asking three different questions from the same facts. Our article on breach notification deadlines works through the multi-regime version of this problem, and the same discipline applies: one incident record, several parallel determinations, each with its own owner and its own clock.

What vendors owe their financial customers

If you are a technology provider rather than a financial entity, none of these clocks are yours, because DORA does not regulate you directly. Your customer's are, and your contract almost certainly makes their clock your problem.

Article 30(2)(f) requires ICT contracts to oblige the provider to give assistance at no additional cost, or at a cost determined in advance, when an ICT incident related to the contracted service occurs. In a well-drafted addendum that becomes a notification commitment with a number of hours attached, because a customer who has to classify inside four hours cannot wait a day for your status page to update.

That clause is one of the nine Article 30(2) baseline terms covered in what a DORA addendum asks you to sign. Practically, it means three things a vendor should be able to state in writing: how quickly you will notify a financial customer of an incident affecting their service, what information the first notification will contain, and who they can reach for the specifics their classification worksheet needs. If your standard incident communications are written for a general SaaS audience, they will not carry a regulated customer through a four-hour window.

Where Top Floor fits

We build the classification worksheet, the report templates mapped to the required fields, and the escalation path that makes a four-hour filing achievable, as part of our DORA work. Where the underlying gap is that the entity has no rehearsed response capability at all, that is incident response work first and reporting work second, and doing it in the other order produces a beautiful template nobody can populate.

We will also say plainly when this is not an engagement. An entity with a mature response function, a good SIEM, and a competent legal team usually needs a mapping workshop and a tabletop, not a project.

How to decide this week

Run a thirty-minute exercise. Take your last significant incident, real or invented, and ask three questions with a timer running.

• When did we become aware, when would we have classified, and could we have filed inside four hours of that classification?
• Could we have answered how many EU clients were affected, in which countries, for how long?
• Who, by name, is authorized to submit the initial notification at two in the morning without waiting for anyone else?

If any answer is uncomfortable, you have found this quarter's work, and it is smaller than a program.

Frequently asked questions

What are the DORA incident reporting deadlines?

Three reports. The initial notification is due as early as possible and within four hours of classifying the incident as major, and no later than 24 hours from the moment the entity became aware of it. The intermediate report is due within 72 hours of the initial notification, even if nothing has changed. The final report is due no later than one month after the intermediate report, or after the latest updated intermediate report. The deadlines are set in Article 5 of Commission Delegated Regulation (EU) 2025/301.

Does the four-hour clock start when the incident happens?

No, it starts when the entity classifies the incident as major. The separate 24-hour limit runs from awareness of the incident, and both apply, so a slow classification does not extend the deadline, it only shortens the time between the decision and the filing. This is why the classification procedure, and the telemetry that feeds it, matter more than the notification template.

How is a DORA major incident different from a GDPR breach?

They test different things. GDPR asks whether personal data was breached and runs a 72-hour clock from awareness. DORA asks whether an ICT-related incident meets the Article 18 materiality criteria, covering clients affected, duration, geographical spread, data losses, service criticality, and economic impact, and runs its own clocks from classification and awareness. An availability outage with no data exposure can be a major incident under DORA and not a breach under GDPR, and the reverse also happens.

Do software vendors have to report incidents under DORA?

Not to a supervisor, unless they are a designated critical ICT third-party service provider. Vendors carry a contractual obligation instead: Article 30(2)(f) requires ICT contracts to commit the provider to assistance during incidents affecting the contracted service, and financial customers translate that into notification timelines fast enough to support their own four-hour classification window. In practice a vendor's obligation is to its customer's clock rather than to a regulator's.