The first 72 hours: who reports what, to whom, by when (NIS2, GDPR, DORA)

In the first 72 hours of a serious cyber incident your team fights on three fronts at once: containing systems, stabilising the business and reporting. Because while it is still unclear internally what exactly happened, external clocks are already running. Which ones depends on who you are and whose data is affected.

Three regimes set those clocks: NIS2 (transposed in Germany in the BSIG), the GDPR, and, for the financial sector only, DORA. They follow different logics, address different recipients and bind different audiences. The most expensive mistake happens before any incident: not knowing which of the three clocks applies to your own organisation.

The overview: which clock ticks for whom

The rule of thumb: NIS2 attaches to the entity, the GDPR attaches to the data, DORA attaches to the sector. That is why several clocks can run in parallel: a manufacturer under the BSIG that also loses HR data reports to the BSI and to the data protection authority, each on its own deadline and with its own content.

NIS2/BSIG: the three-stage chain to the BSI

For entities in scope of Germany’s BSIG, §32 sets a three-stage notification duty for significant incidents, the national implementation of the staged reporting the NIS2 Directive prescribes EU-wide. The clock starts on awareness, and the receiving counter has long existed: the BSI’s reporting and contact-point portal (MUK) has been in full operation since 1 June 2026.

The 24-hour early warning is deliberately designed as a first signal: it does not require a finished analysis. That is exactly what teams get wrong under pressure: they polish a complete assessment while a deliberately incomplete first notice could long have been filed.

GDPR: 72 hours to the authority, and sometimes to the individuals

Independently of NIS2, the GDPR applies to every controller. If an incident results in a personal data breach, Article 33 GDPR requires notification to the competent supervisory authority: without undue delay and, where feasible, within 72 hours of becoming aware. The only exception: a breach that is unlikely to result in a risk to individuals. If the notification comes later, the delay has to be justified.

Article 34 GDPR goes one step further: where the breach is likely to result in a high risk, the affected individuals themselves must be informed, again without undue delay. In practice this means that as soon as a ransomware incident encrypts or exfiltrates personal data, the Article 33 question is on the table, in addition to the NIS2 chain, not instead of it. Two clocks, two recipients, two sets of content.

DORA: its own clocks, but only for finance

DORA, Regulation (EU) 2022/2554 and applicable since 17 January 2025, covers financial entities and critical ICT third-party providers, and nobody else. For major ICT-related incidents, the technical standard RTS (EU) 2025/301 sets the reporting rhythm:

If you are not in the financial sector, you can note this section and file it away: DORA does not apply to you. If you are, the 4-hour deadline after classification is the sharpest clock in this article, and it only works with a classification process that exists before the incident does.

One incident, several clocks: the organisational truth

The real problem is rarely ignorance of the deadlines: it is operating them at three in the morning. All three regimes start their clocks at awareness or at a classification decision. Your own organisation therefore co-determines when the deadlines start running, and must be able to establish and document that moment cleanly. Four things belong in every reporting playbook:

• Ownership: who establishes awareness, who judges significance (BSIG), risk (GDPR) or severity (DORA), and who decides when they disagree?
• Drafts: pre-built skeletons for the early warning and the Article 33 notification, so that on the day only the facts need filling in.
• Access: who holds the accounts for the MUK portal and the authorities’ reporting channels, and who deputises when that person is unreachable?
• Record: a decision log with timestamps that can later show supervisors and insurers what was known and decided, when.

From deadline sheet to rehearsed notification

A playbook with those four elements is necessary, and still only a hypothesis as long as it has never run under pressure. That is why Verdus exercises ship with dedicated reporting-chain injects: in the middle of an escalating situation the team is confronted with the notification question, decides under time pressure whether, when and what to report, and every one of those decisions is captured with a timestamp. The debrief then does not say “we would probably have made it”: it shows in black and white whether the early warning would have reached the BSI within 24 hours.

The first 72 hours of an incident cannot be improvised, but they can be rehearsed. A team that has run the reporting chain once in a safe setting knows its gaps before a supervisor does.