DORA Incident Reporting Timeline: 4 Hours, 24 Hours, 72 Hours and One Month Under RTS 2025/301, and Who Loses the Weekend Rule

A payment institution becomes aware of a ransomware incident at 16:00 UTC on a Friday and classifies it as major at 21:30. Its initial notification is due at 01:30 UTC on Saturday. Because that falls on a weekend, it may file by noon on Monday instead. A bank in the same situation may not, and has to file in the early hours of Saturday. Same incident, same clock, and more than two days between their deadlines.

That difference comes from Article 5(5) of Commission Delegated Regulation (EU) 2025/301, the act that sets the time limits DORA Article 19(4) leaves open. DORA itself sets no reporting hours. This guide covers the four time limits and what starts each one. It also covers the rules most summaries skip: late classification, updated intermediate reports, the delay notice, the weekend rule and who loses it, and the separate duty to tell clients.

Who Runs This Clock, and Who Keeps the Weekend Rule

In plain terms: every financial entity under DORA reports major ICT-related incidents on the same time limits. The only thing that differs by entity type is whether a deadline that lands on a weekend or bank holiday can wait until the next working day.

Article 5 of RTS 2025/301 has no separate limits for microenterprises or for the Article 16(1) entities that run a simplified framework. Recital 5 explains the intent: the timelines “should not pose a disproportionate burden to microenterprises and to other financial entities that are not significant” and “should take into account weekends and bank holidays”. Recitals are not binding. In the operative text, that intent is carried out through the weekend rule in Article 5(4) to (6), not through longer deadlines.

Financial entity	Weekend relief for initial notification and intermediate report	Weekend relief for final report	Provision
Credit institutions	No	Yes	Art. 5(5)
Central counterparties	No	Yes	Art. 5(5)
Operators of trading venues	No	Yes	Art. 5(5)
Any other financial entity identified as an essential or important entity under NIS2 Article 3	No	Yes	Art. 5(5)
A significant or systemic entity that its competent authority has notified of a decision	No, for incidents reported after the notification	Yes	Art. 5(6)
All other financial entities: payment and e-money institutions, investment firms, insurers, crypto-asset service providers, microenterprises	Yes	Yes	Art. 5(4)

The NIS2 row is the one compliance teams most often get wrong. It does not cover every financial entity. It covers only those that national NIS2 rules have actually identified as essential or important. Our comparison of DORA and NIS2 reporting explains how that identification works and why DORA Article 1(2) then takes over the reporting.

The Four Clocks and What Starts Each One

In plain terms: each report has its own clock. Only the first one runs from the incident itself. After that, each clock starts from your previous submission. So the deadlines shift as you file.

Submission	What starts the clock	Time limit (RTS 2025/301)	Provision
Initial notification	Classification as major, with a cap counted from awareness	“as early as possible, but in any case, within four hours from the classification … and no later than 24 hours from the moment the financial entity has become aware”	Art. 5(1)(a)
Initial notification, late classification	Classification as major, more than 24 hours after awareness	“within four hours from the classification”	Art. 5(2)
Intermediate report	Submission of the initial notification	“at the latest within 72 hours … even where the status or the handling of the incident have not changed”	Art. 5(1)(b)
Updated intermediate report	Recovery of regular activities, a relevant status update, or the authority’s request	“without undue delay, and in any case when the regular activities have been recovered”	Art. 5(1)(b); DORA Art. 19(4)(b)
Final report	Submission of the intermediate report or the latest updated one	“no later than one month after”	Art. 5(1)(c)

The chaining was a deliberate change. In the consultation draft, the intermediate and final report clocks ran from classification too.

The chaining has a practical side effect: filing early pulls every later deadline forward. A firm that sends its initial notification two hours after classification has 72 hours from that moment for the intermediate report, not from hour four. “As early as possible” is still the rule. You cannot hold back the first report to buy time for the second. But plan staffing on the actual submission time, not the latest permitted one.

Two template rules make an early filing workable. Implementing Regulation (EU) 2025/302 Article 1(3) requires estimated values “where accurate data are not available at the time of reporting” for the initial notification or intermediate report. Article 1(4) lets each later report update what was sent before. Article 2 allows two or all three reports to be combined where regular activities have recovered or the root cause analysis is complete, “provided that the time limits … are met”. A short incident can therefore close in a single submission, but on our reading only if that submission meets the earliest time limit still running.

Late Classification: When the 24-Hour Cap Stops Applying

In plain terms: the 24-hour cap only applies if you classify within 24 hours. Classify later, and you get a fresh four hours from the moment of classification.

Article 5(2) reads: where the financial entity “has not classified an ICT-related incident as major within 24 hours from the moment the financial entity has become aware” but classifies it as major later, it “shall submit the initial notification within four hours from the classification”. Two consequences follow.

First, the 24-hour cap only bites when classification comes late inside the first day. Classify at hour 22 and you have two hours left, not four. Classify at hour 30 and the deadline is hour 34. This is how the text works, not a loophole. The regulation sets no time limit for classification itself. But it does not reward delay either. Recital 2 says the initial notification should come “as short as possible after an ICT-related incident has been classified as major”. Annex II of ITS 2025/302 also asks for two separate timestamps: field 2.2, the time “at which the financial entity has become aware” of the incident, and field 2.3, the time it was classified as major. Both are entered in ISO 8601 UTC. Both timestamps are required in every report, so the supervisor sees the gap between them.

Second, a late classification often comes from recurring incidents. Delegated Regulation (EU) 2024/1772 Article 8(2) treats non-major incidents as one major incident when they occurred at least twice within six months, share the same apparent root cause, and together meet the major criteria. Entities must check this “on a monthly basis” (microenterprises and Article 16(1) entities are exempt). For recurring incidents, field 2.2 records when the last incident was detected. A monthly review that turns up such a pattern can therefore start the initial-notification clock under Article 5(1)(a), or under Article 5(2) if more than 24 hours have passed since that detection.

The opposite case has its own route. Under ITS 2025/302 Article 5, if an incident reported as major “at no time fulfilled” the criteria, you notify a reclassification to non-major through the template fields “type of report” and “other information”, where the glossary asks for the reasons. An incident that has stopped meeting the thresholds does not qualify: the test is whether it ever met them.

Intermediate and Updated Intermediate Reports

In plain terms: the first intermediate report is due at hour 72 whether or not anything has changed. Further updates are owed whenever the situation moves, and always once normal service is back.

DORA Article 19(4)(b) describes the intermediate report as due once the status “has changed significantly”, “followed, as appropriate, by updated notifications every time a relevant status update is available, as well as upon a specific request of the competent authority”. The RTS adds two hard triggers. The intermediate report is due within 72 hours “even where the status or the handling of the incident have not changed”. And the entity “shall submit an updated intermediate report without undue delay, and in any case when the regular activities have been recovered”.

The final report runs from the intermediate report or, “where applicable”, from “the latest updated intermediate report”, so each update moves the final deadline. The final-report date is not fixed until the last update has been sent. A team that sends its recovery update on day 6 and a last status update on day 9 has its final report due one month after day 9.

The final report has a content trigger as well as a time limit. DORA Article 19(4)(c) calls for it “when the root cause analysis has been completed, regardless of whether mitigation measures have already been implemented, and when the actual impact figures are available to replace estimates”. The one-month limit is the latest date. It does not require you to wait a month. Our guide to the NIS2 one-month final report shows how differently the NIS2 version of this clock is anchored.

The Weekend Rule: Article 5(4) to 5(6)

In plain terms: most financial entities may push a weekend or bank-holiday deadline to noon of the next working day. Banks, CCPs, trading venues and NIS2-identified entities may not do this for the first two reports. Authorities can add more entities, for incidents reported after they notify them.

Article 5(4): where the time limit for an initial notification, intermediate report or final report “falls on a weekend day or a bank holiday in the Member State of the reporting financial entity, the financial entity may submit … by noon of the next working day”. Article 5(5) switches this off “for the submission of an initial notification or an intermediate report” by the entities in the scope table above. Article 5(6) lets a competent authority do the same for other entities that “are significant or have a systemic character”. The decision applies “only … in respect of incidents reported after the date of notification of the decision”.

The ESAs’ final report explains the design. They removed the need to file final reports at weekends for every entity, and they extended the relief to the initial notification “so that not all FEs will be required to maintain a 24/7 incident reporting support function”. They also replaced the consulted deadline of one hour after the start of business with noon. Read the opening example with this in mind. The bank’s Saturday 01:30 UTC deadline stands. The payment institution’s moves to Monday noon. If a final report for either one falls on 25 December, it may be filed by noon of the next working day for both, because Article 5(5) does not cover final reports.

Three points the text leaves open:

• Which time zone “noon” means. The template runs on UTC, but the bank-holiday test refers to “the Member State of the reporting financial entity”. The more natural reading is local noon in that Member State. The RTS does not say so, so confirm it with your authority.
• Updated intermediate reports. Article 5(5) and 5(6) name the “intermediate report” only. The cautious reading treats an update the same way, and that is what we would plan for.
• When the deadline “falls”. A Friday 23:00 UTC limit is already Saturday in Athens, Helsinki and Bucharest. We judge the weekend by the local date of the deadline, because Article 5(4) ties the test to the entity’s own Member State, but the text does not settle it.

When we built the reporting clock for our own DORA templates, the weekend test took more design work than the four-hour arithmetic. A spreadsheet’s NOW() returns the computer’s local time, the template wants UTC, and the bank-holiday calendar is national. Every timestamp needs a stated time zone, or the clock is wrong for part of the year.

The Delay Notice and Other Fallbacks

In plain terms: if you will miss a deadline, tell your authority before it passes and say why. The notice does not move the deadline.

Article 5(3): entities “unable to submit the initial notification, intermediate report, or final report within the time limits … shall inform the competent authority thereof without undue delay, but no later than the respective time limits for the submission of the notification or report, and shall explain the reasons for the delay”. The notice has its own deadline, the same one as the missed report. The RTS grants no extension for it, so on our reading the report is still late. The notice keeps a late report from also being an unannounced one.

Three other fallbacks are often confused with the delay notice:

• Template impossible. DORA Article 19(1): where “a technical impossibility prevents the submission of the initial notification using the template”, the entity notifies the authority “via alternative means”.
• Channel unavailable. ITS Article 4 requires the secure electronic channel “as made available by their competent authority”. If you cannot use it, you report through other secure means agreed with the authority, and resubmit through the channel if required. Channels vary: Latvijas Banka takes reports through its FAS security system, with email as a fallback. Ireland’s Pensions Authority takes completed templates by email. Record the backup route in the procedure before you need it.
• Outsourced reporting. DORA Article 19(5) lets a third party file for you, but the entity “remains fully responsible”. ITS Article 6 requires you to tell the authority about the arrangement “at the latest prior to the first notification or reporting”.

The Client Notice: A Separate Clock Under Article 19(3)

In plain terms: if a major incident hits clients’ financial interests, you must tell them without undue delay. The duty is separate from your reports to the authority, and the law sets no hours for it.

DORA Article 19(3): where a major ICT-related incident “has an impact on the financial interests of clients, financial entities shall, without undue delay as soon as they become aware of it, inform their clients about the major ICT-related incident and about the measures that have been taken to mitigate the adverse effects”. For a significant cyber threat, entities “shall, where applicable, inform their clients that are potentially affected of any appropriate protection measures”.

Three things make this clock different. It has two conditions, a major incident and an impact on clients’ financial interests, so a major incident without that impact does not trigger it. It is phrased as “without undue delay”, not in hours, so RTS 2025/301 Article 5 does not govern it, the weekend rule included. And on our reading it can fall due before the initial notification does, because nothing ties it to the four-hour count. The supervisor will see the client side anyway: point (i) of RTS Article 3, the content list for intermediate reports, asks for the “impact on the financial interest of clients”.

Counting Four Hours and One Month

In plain terms: count four hours as four clock hours, and one month as the same date in the next month. Treat anything more generous as unconfirmed.

Regulation (EEC, Euratom) No 1182/71 sets the EU’s default rules for time limits. It applies “save as otherwise provided” to acts of the Council or Commission, and RTS 2025/301 is a Commission act. Under its Article 3(2)(c), a period in months ends on the same date in the last month, or on the month’s last day if that date does not exist. So one month from 31 January ends on 28 February (29 in a leap year), not after 30 days. On our reading, its own weekend roll-over in Article 3(4) gives way here, because Article 5(4) of the RTS provides otherwise with the noon rule.

One provision there cuts the other way, and we mention it only to discourage relying on it. Article 3(1) says that for a period expressed in hours, “the hour during which that event occurs” is not counted. Read literally, a four-hour limit starting at 21:30 would end at 02:00, not 01:30. We have found no supervisor that publishes this reading, and the RTS asks for the initial notification “as early as possible”. Plan on the plain four hours.

DORA and NIS2 Side by Side

In plain terms: a financial entity reports on DORA’s clock, not NIS2’s. If its Member State also wants a copy for the NIS2 authority, it sends the same DORA report there.

Stage	DORA (RTS 2025/301 Art. 5)	NIS2 (Art. 23(4))
First report	4 h from classification as major, no later than 24 h from awareness	Early warning within 24 h of becoming aware
Second report	72 h from submission of the initial notification	Incident notification within 72 h of becoming aware
Updates	Updated intermediate reports, always on recovery	Intermediate report on request
Final report	One month after the intermediate report or, where there is one, the latest updated intermediate report	One month after the incident notification
Weekend relief	Noon of next working day, with Art. 5(5) and 5(6) exclusions	None in the Directive

Under DORA Article 1(2), DORA is “a sector-specific Union legal act for the purposes of Article 4” of NIS2 for financial entities identified under NIS2, so they report on the DORA column. The link between the two is DORA Article 19(1), last subparagraph: Member States “may additionally determine” that some or all financial entities also send each DORA report to the NIS2 competent authorities or CSIRTs, using the DORA templates. Ask your authority whether your country does this. The NIS2 Directive anchors its second report to awareness, not to the first submission. That is why the two 72-hour figures differ, despite looking the same.

Who Owns What When the Clock Starts

Role	What to settle before the next incident
Compliance officer	Which weekend row of the scope table you are in; whether an Art. 5(6) decision has been notified; your authority’s channel and backup route; whether your Member State uses the Art. 19(1) copy to NIS2 authorities
CISO / incident manager	An internal classification target well inside 24 hours; UTC timestamps for awareness and classification; a trigger that sends an updated intermediate report when service is recovered
Management body	Who signs a delay notice under Art. 5(3) at 03:00 on a Sunday, and who approves the client message under Art. 19(3)
Owner of a small firm or microenterprise	The same limits apply to you, but weekend relief usually does too. Write down who files on Monday morning and from which account

The DORA hub has the wider requirements, scope and recurring deadlines in one place: DORA compliance requirements, scope and deadlines. For how DORA fits into the regulation as a whole, see what DORA is and whom it covers.

Frequently Asked Questions

Does the DORA 72-hour clock run from awareness of the incident?

No. Under RTS 2025/301 Article 5(1)(b), it runs from the submission of the initial notification. That is the main difference from NIS2, where the 72 hours run from becoming aware.

Can a bank use the weekend rule for its final report?

Yes. Article 5(5) removes the relief for credit institutions, CCPs, trading venue operators and NIS2-identified entities only for initial notifications and intermediate reports. A final report due on a weekend or bank holiday may be submitted by noon of the next working day.

Can we send the initial, intermediate and final reports at once?

Yes, under ITS 2025/302 Article 2, where regular activities have recovered or the root cause analysis is complete, and provided the Article 5 time limits are met. On our reading, that means the combined submission must arrive within the earliest Article 5 time limit that still applies.

What happens if we cannot file on time?

Inform the competent authority without undue delay, and no later than the deadline you will miss, explaining the reasons (Article 5(3)). The RTS grants no extension for doing so.

Do microenterprises get longer reporting deadlines?

No. Article 5 sets the same limits for every financial entity. Microenterprises benefit from the weekend rule unless NIS2 identification or an Article 5(6) decision removes it, and they are exempt from the monthly recurring-incident check in RTS 2024/1772 Article 8(2).

Conclusion: Write the Clock Down Before You Need It

The four numbers are easy to remember. The harder part is the anchors. The 24-hour cap is counted from awareness. The 72 hours run from your own first submission. The final month restarts with every update. The weekend rule depends on your entity type and your national calendar. Before the next incident, write five facts into your procedure: your weekend row, your authority’s channel and backup route, who decides classification and by when, who signs a delay notice, and who approves the client message.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

How This Guide Was Verified

Every quotation from DORA, RTS 2025/301, ITS 2025/302 and RTS 2024/1772 is taken from the official English texts on EUR-Lex. EUR-Lex lists no amending act for RTS 2025/301 or ITS 2025/302. Each has one corrigendum, for the French language version only, so the English wording quoted here is unchanged. Where a point is our reading rather than the text, the guide says so.

Sources

1. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA) — EUR-Lex (Articles 1(2), 19, 20)
2. Commission Delegated Regulation (EU) 2025/301, content and time limits for major ICT-related incident reports — EUR-Lex (Articles 2, 3, 5; Recitals 2, 5)
3. Commission Implementing Regulation (EU) 2025/302, standard forms and procedures for incident reporting — EUR-Lex (Articles 1, 2, 4, 5, 6; Annex II fields 2.2, 2.3)
4. Commission Delegated Regulation (EU) 2024/1772, classification of ICT-related incidents — EUR-Lex (Article 8(2))
5. Directive (EU) 2022/2555 (NIS2) — EUR-Lex (Article 23(4))
6. Regulation (EEC, Euratom) No 1182/71 on periods, dates and time limits — EUR-Lex (Articles 1, 3)
7. ESAs, JC 2024 33, Final report on the draft RTS and ITS on incident reporting, 17 July 2024 — ESMA (PDF)
8. Pensions Authority (Ireland), Major ICT-related incident reporting and significant cyber threats
9. Latvijas Banka, Incident reporting