NIS2 After the Grace Period: From Registering to Reporting
The BSI's leniency on registration ended on 31 July 2026. The figures show many registrations and few reports. What counts as a significant incident, when the 24-hour clock starts, and how a company becomes ready to report.
The statutory registration deadline under the German NIS2 Implementation Act passed on 6 March 2026, and the leniency granted by the BSI ended on 31 July. Today the BSI states plainly that the deadline has passed and calls on companies in scope to register without delay. Anyone who has not done so is no longer in a transition phase.
For registered entities, a different question arises. Registration is a one-off step; the reporting duty under Section 32 of the German BSI Act is a permanent state. Whether a company can meet it only becomes clear during an incident.
What the figures show
The BSI publishes its figures regularly. As of 30 June 2026, 17,945 entities were registered, including 11,501 important and 6,215 essential entities. By the same date, the BSI counted 692 initial NIS2 reports and a total of 1,659 NIS2 reports submitted through the portal. The next update is announced for 31 October 2026.
These figures say nothing about individual companies, but they do allow one observation: the ratio of registered entities to initial reports is low. That may mean few significant incidents occur. It may also mean incidents are not recognised internally as reportable. Every management board should know which reading applies to its own organisation, because Section 38 of the BSI Act makes management responsible for implementation.
When an incident is significant
Not every security incident must be reported, only significant ones. Section 2 no. 11 of the BSI Act sets two tests: severe operational disruption or financial loss for the entity itself, or considerable material or non-material damage to others. Both expressly apply where the damage may occur, not only where it has occurred. For providers of digital infrastructure and digital services, such as cloud, data centre and DNS services or managed services, Implementing Regulation (EU) 2024/2690 specifies the thresholds in more detail.
The test is deliberately broad, and it targets impact rather than attack technique. An outage of a customer-facing service lasting several hours can be significant even if a misconfiguration, not an attacker, turns out to be the cause.
The clock starts with awareness
Section 32 of the BSI Act stages the reporting: an early initial report within 24 hours of becoming aware, stating whether unlawful or malicious action is suspected or cross-border impact is possible; a notification within 72 hours with an initial assessment of severity and impact and, where available, indicators of compromise; an interim report at the BSI’s request; and a final report no later than one month after the notification.
The critical point is the start. The deadline runs from awareness, not from the moment someone classifies the incident as reportable. If an alert arrives on Friday evening and the assessment only takes place on Monday, the 24-hour deadline has passed before anyone has even discussed a report.
Becoming ready to report
Reporting readiness is built before the incident. Four elements carry it:
- Set thresholds in advance: which outages, data leaks or impairments count as significant for your own services? A documented classification avoids a debate of principle in a real incident.
- Name responsibilities: who decides on the report, who deputises, and how is that person reached outside business hours?
- Secure access: reports are submitted through the BSI portal. Access and permissions must be in place before they are needed.
- Keep a timeline: detection, assessment and measures with timestamps, so that the initial, follow-up and final reports rest on the same facts.
An exercise with a realistic scenario quickly shows where the chain breaks. It is rarely the technology; more often it is the handover between the team that notices the incident and the function that decides on the report.
Perstat, our product for monitoring and security posture, addresses the start of that chain: outages and security-relevant changes are detected, escalated and recorded with timestamps. Classifying an incident as significant and submitting the report remain the company’s responsibility.
Being registered describes a status. Being ready to report describes a capability, and only the capability is tested when it matters.