NIS2 incident reporting: 24 hours from the moment you know — the one duty the fine catalogue names directly

It is Friday, 19:40, when your IT provider calls: encryption on three servers, the outage unclear, an attack probable. In that moment a clock starts that you cannot see — because Section 32 BSIG gives you 24 hours from gaining knowledge of a significant security incident to file the early warning with the BSI. Not from forensic confirmation, not from Monday morning: from knowledge. And unlike the management duty of Section 38 that we dissected yesterday, this duty sits verbatim in the fine catalogue.

This piece walks the reporting architecture the way the statute built it: which incidents are "significant" under Section 2 no. 11 BSIG, the cascade of up to four reports under Section 32, the three routes a report can take to the joint reporting point, the second and third clocks that start in parallel — the GDPR notification and the customer information duty of Section 35 — and what a missed deadline costs under Section 65. For every important and essential entity under Section 28 BSIG, this is the paragraph to know before the first incident, not during it.

The cascade: one duty, up to four reports

Section 32(1) BSIG obliges essential and important entities to report to a joint reporting point set up by the BSI and the Federal Office of Civil Protection and Disaster Assistance (BBK). The duty unfolds in stages, and the first stage is deliberately thin: within 24 hours of gaining knowledge, the entity files an early warning stating only whether there is suspicion that the incident was caused by unlawful or malicious acts, or could have cross-border effects. The statute asks for a suspicion, not a cause — nobody needs forensics to answer it.

Within 72 hours follows the incident notification: it confirms or updates the early warning and adds a first assessment — severity, impact, and where applicable indicators of compromise. On request of the BSI, interim reports follow on relevant status changes. One month after the incident notification the final report is due: a detailed description including severity and impact, the type of threat or its underlying cause, the mitigation measures taken and running, and any cross-border effects. If the incident is still running at that point, Section 32(2) substitutes a progress report, with the final report after the incident is closed. Operators of critical facilities owe a further layer under paragraph 3: the kind of facility affected, the critical service, and the incident's effects on it.

What "significant" means — the threshold sits lower than expected

Section 2 no. 11 BSIG defines the significant security incident in two alternative limbs. Limb one: the incident has caused — or can cause — severe operational disruption of the entity's services or financial losses for the entity. Limb two: it has affected — or can affect — other natural or legal persons through significant material or non-material damage. The operative word is can. A ransomware detonation that reached a reachable backup has not yet caused the outage — but it can cause one, and the clock is already running.

Two demarcations keep the definition honest. The near-miss of Section 2 no. 1 — the event whose occurrence was successfully prevented — is not reportable under Section 32. For it, Section 5 BSIG keeps the voluntary channel open by statute — anonymously if desired, for near-misses and companies outside the scope alike — and Section 30(7) guarantees that a voluntary report creates no additional obligations. And a facility disruption without service or third-party dimension stays below the threshold; the limb requires the disruption of services or the financial loss, not the mere presence of malware.

Where the report goes — three routes to one reporting point

The reporting point is a joint one of BSI and BBK, and Section 32(1) sentence 2 tied the duty to the existence of the reporting channel — a clause that is now settled fact: the channel has stood since the act entered into force on 6 December 2025. According to the BSI's reporting guidance, the route splits by status: entities registered in the BSI portal report there; entities in scope of NIS2 that have not yet registered use an online form in the reporting and information portal (MIP); operators of critical facilities and federal authorities continue to use their established MIP channels for the transition. The portal documentation adds that voluntary incident reports and anonymous vulnerability reports are open to everyone.

Who may file is wider than most expect: in principle any employee can report, several people in one entity can hold the authorisation, and the entity may empower companies or service providers to file on its behalf — while the responsibility for the incident and the report's content stays with the operator. Two downstream mechanics deserve note: under Section 32(5) the BSI forwards incoming reports to the competent federal supervisory authority without delay, and under paragraph 6 it may offer support in resolving the incident. The BSI confirms receipt of reports and feeds sanitised content into its situational products — the report informs the national picture, it does not quietly disappear.

The second clock: data protection — and the third: your own customers

A significant incident with personal data starts a second timer under a different statute. Article 33 GDPR requires notification of a personal data breach to the competent supervisory authority without undue delay and, where feasible, within 72 hours — a different trigger (personal data, not service disruption), a different recipient (the state data commissioner, not the BSI), a different clock. The two run in parallel; neither satisfies the other. What the BSIG adds is a protection against double punishment: Section 65(11) bars a second fine under the BSIG where a GDPR authority has already fined the same conduct.

The third clock points at your own service recipients. Under Section 35(1) BSIG the BSI may order essential and important entities to inform the recipients of their services about a significant incident without undue delay — the statute expressly allows the information to take the form of a publication on the entity's website. Section 35(2) goes further for five digitally close sectors — financial services, social security, digital infrastructure, ICT service management and digital services: there, entities must proactively notify potentially affected recipients of significant cyber threats together with the countermeasures available to them, where the recipients' interests prevail. That breach sits in the same top fine bracket as the reporting duty itself.

What a missed deadline costs — and who imposes the fine

Yesterday we showed that Section 38 — the management duty — does not appear in the fine catalogue at all. Section 32 is the opposite case. Section 65(2) nos. 4 and 5 BSIG punish a report under Section 32(1) or a final report under Section 32(2) that is not made, not made correctly, not completely or not on time — committed intentionally or negligently. A forgotten Saturday is not an excuse the catalogue knows.

The frame is the statute's top bracket under Section 65(5) no. 1: up to ten million euros for essential entities, up to seven million for important ones, and where the undertaking exceeds 500 million euros of worldwide turnover, up to two or 1.4 percent of it. Section 65(9) keeps the fine on the entity by excluding the redirection onto the acting organ. And Section 65(10) names the enforcing authority: the BSI itself — the same office that receives the report decides on the fine for its absence. The reporting duty is, in other words, the point where the incident becomes expensive twice: once in operations, once on paper.

Before the incident: five decisions that do not belong in the emergency

None of the mechanics above is hard in a quiet week. All of them are hard at 19:40 on a Friday. And all of them hang on a precondition the statute has long since written as a duty of its own: Section 30(2) no. 2 BSIG makes the handling of security incidents a mandatory measure area — whoever cannot notice the incident fails two provisions at once, and both sit in the fine catalogue. Five decisions belong in the board's calendar, not in the incident:

The pattern should look familiar — it is the same architecture as under Section 38: the duty is discharged in documentation or not at all. The difference is that this one is fine-backed from day one, and that its deadlines measure themselves in hours.

The honest remainder: what Section 32 does not demand

Three absences calm the duty down. The statute demands no finished forensics in 24 hours — the early warning asks for a suspicion, nothing more. It demands no completeness — the 72-hour notification exists precisely to correct and extend the first report. And it demands no reports for near-misses — the prevented incident of Section 2 no. 1 stays outside the duty, however instructive it was internally. What the statute does not forgive is the absence of a chain: whoever has no route by which a discovery becomes a report has organised the breach in advance.

Whoever takes one sentence from this piece: under NIS2 the incident is not the deadline — the knowledge is. The 24 hours that decide the fine run while you are still deciding whether it is serious. Build the clock before you need it.

Frequently asked questions about the NIS2 reporting duty