Most incident response plans record the reporting deadlines correctly and still miss them. The reason is rarely the arithmetic. It is that each instrument starts its clock at a different moment: awareness of a personal data breach 1, awareness of a significant incident 2, the classification of an incident as major 3, a determination that an incident is material 5, the discovery of a cyberattack 6. Most of those moments are decisions your organisation makes under pressure, and the law counts from when the decision was due, not from when it was taken.
Six duties, six different starting points
An organisation with Swiss operations, EU subsidiaries, a product on the EU market and a US listing is not on one clock. It is on six, and they do not start together.
| Duty | The clock starts at | First deadline |
|---|---|---|
| GDPR, Art. 33(1) | "having become aware" of the personal data breach 1 | 72 hours |
| NIS2, Art. 23(4)(a) | "becoming aware of the significant incident" 2 | 24 hours, early warning |
| DORA, Art. 5(1)(a) RTS | "the classification of the incident as major" 3 | 4 hours |
| Cyber Resilience Act, Art. 14 | becoming aware of an actively exploited vulnerability in your product 4 | 24 hours |
| SEC, Form 8-K Item 1.05 | "determining that a cybersecurity incident is material" 5 | 4 business days |
| Swiss ISG, Art. 74e(1) | the discovery of the cyberattack 6 | 24 hours |
Read the middle column again. Only two of the six start from something that happens to you. The others start from something you conclude: that a breach has occurred, that an incident is major, that it is material. The Cyber Resilience Act does not need an incident at all — for a manufacturer, an actively exploited vulnerability in a product already on the market starts a 24-hour clock whether or not any customer has been harmed 4.
The trigger is a decision, and the law dates it for you
The obvious temptation is to control the trigger. If the clock starts when we classify, classify late. Every one of these instruments anticipates that move.
DORA sets the initial notification at four hours from the classification of the incident as major, "and in any event no later than 24 hours from the moment the financial entity has become aware" of it 3. Classification discipline cannot buy more than a day. The SEC requires the materiality determination to be made "without unreasonable delay following discovery of the incident"; the four business days then run from the determination, so a slow determination is itself the violation rather than an extension 5. GDPR's 72 hours run from awareness, and awareness is not the moment the investigation concludes.
This has an organisational consequence that is easy to miss: the people who hold the trigger are usually not in the incident bridge. Classification as major under DORA, materiality under the SEC rule and the high-risk assessment under Art. 34 GDPR 1 are judgements for a named role with a mandate — not for whoever is on call at 03:00. If that role learns of the incident six hours late, the organisation has lost six hours of a four-hour clock.
Some clocks start from your own filing
The second source of error is more mechanical. Several deadlines do not count from the incident; they count from a report you yourself submitted.
NIS2's final report is due "not later than one month after the submission of the incident notification", not one month after the incident 2. DORA's intermediate report falls due 72 hours after the initial notification was submitted, and the final report one month after the intermediate one 3. Under the Swiss ISG regime, the report must be completed within 14 days of the initial report 6.
The practical consequence is counter-intuitive: filing early pulls your next deadline forward. A team that gets DORA's initial notification out in two hours has just moved its intermediate report two hours earlier as well. This is the right trade, but it should be a decision, not a surprise — and the only way to see it is to model the chain, not the individual duties.
The arithmetic that catches teams out
Four details account for most of the near-misses we see in exercises.
- Hours are elapsed hours. A 72-hour window opened on Friday evening ends on Monday evening. Nothing pauses for the weekend.
- Business days are a different system. The SEC's four business days are counted on the US federal calendar, and the filing has to be in before the close of the EDGAR day in New York 5. A Thursday determination before a Monday holiday is not four days of work.
- A month is a calendar month. NIS2 and DORA both use one-month windows 23. 31 January plus one month is 28 February, not 2 March.
- The clocks run in parallel, to different authorities, in different languages. One incident can require an early warning to a national CSIRT, a notification to a data protection authority, a filing with a financial regulator and a market disclosure — each on its own form.
What to decide before the incident, not during it
None of this is solved by a longer playbook. It is solved by four decisions taken while nothing is burning.
Who determines. Name the role that classifies an incident as major, determines materiality, and decides whether a breach is likely to result in a high risk to individuals. One name per judgement, with a deputy.
When they are told. Write the escalation threshold that puts the incident in front of that role, and make it deliberately low. The cost of an unnecessary call is minutes; the cost of a late one is a clock already half spent.
What goes out at T+4 hours. Draft the four-hour and 24-hour filings now, with the fields you will actually be able to fill at that point. Every one of these first reports is explicitly allowed to be incomplete: GDPR permits phased notification 1, NIS2's early warning asks only whether malicious action is suspected and whether there may be cross-border impact 2. Teams miss first deadlines because they wait for certainty the instrument never asked for.
Rehearse the clock, not only the breach. In the next tabletop, start the exercise clock at discovery and ask the team to produce the filings, on the forms, against the real deadlines. The failures that surface will be about authority and language, not about forensics.
A timeline you can read in the first hour
Because the mapping is mechanical, we built it as a tool and made it free: enter the moment of discovery and the incident reporting deadline calculator shows every clock you are on, on one timeline, with the provision behind each deadline and an export for your incident log. A short questionnaire selects the regimes from your countries, sectors and size, and you can tick or untick any duty by hand. It runs entirely in your browser, so no incident detail is transmitted anywhere — which is the only form in which a tool like this is usable during a real incident.
It is a map of the clocks, not legal advice, and the first thing to do with it is to disagree with it: every figure cites the provision it came from, so you can check it against the source before anyone relies on it.
Questions for leadership
- For each reporting duty that binds us, who holds the trigger decision, and who is their deputy at 03:00 on a Sunday?
- What is the escalation threshold that puts an incident in front of that person, and when did we last test that it fires?
- Do we have the four-hour and 24-hour filings drafted, with only the fields we could realistically complete in that time?
- Which of our deadlines run from our own earlier filings, and does the team know that filing early moves them?
- If our Swiss, EU and US duties conflicted on what may be said publicly and when, who decides, and in which minute of the incident?
Sources
- Official Journal of the European Union, “Regulation (EU) 2016/679 (General Data Protection Regulation), Articles 33 and 34”, 27 April 2016. eur-lex.europa.eu
- Official Journal of the European Union, “Directive (EU) 2022/2555 (NIS2), Article 23”, 14 December 2022. eur-lex.europa.eu
- Official Journal of the European Union, “Commission Delegated Regulation (EU) 2025/301 of 23 October 2024: content and time limits for reporting major ICT-related incidents under DORA”, 23 October 2024. eur-lex.europa.eu
- Official Journal of the European Union, “Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 14”, 23 October 2024. eur-lex.europa.eu
- US Securities and Exchange Commission, “Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure, Release Nos. 33-11216; 34-97989”, 26 July 2023. sec.gov
- Fedlex, Schweizerische Eidgenossenschaft, “Informationssicherheitsgesetz (ISG, SR 128), Art. 74a–74f: Meldepflicht für Cyberangriffe auf kritische Infrastrukturen”, 18 December 2020. fedlex.admin.ch