Last updated: 2026-11-06
Reporting is an obligation in its own right, separate from handling the incident itself. How you handle incidents technically and organisationally is part of the measures under Section 30 BSIG (point 2, incident handling).
Who has to report?
Essential and important entities report significant incidents to the joint reporting office of the BSI and the BBK (Section 32(1) of the German BSI Act, BSIG). The obligation has applied since 6 December 2025 and does not depend on registration. Operators of critical facilities additionally state the type of facility, the critical service and the impact on it (Section 32(3)).
Under Section 28(5) to (7), Section 32 does not apply to some entities, for example telecoms providers (telecoms providers under NIS2 and the TKG), certain energy companies and financial entities under DORA. The exemptions and their limits, for example where further activities under Annex 1 or 2 are added, are explained in the NIS2 applicability check.
When is a security incident significant?
Under Section 2 no. 11 BSIG, a security incident is significant if it has caused or can cause severe operational disruption of the services or financial losses for the entity, or if it has affected or can affect other persons by causing considerable material or non-material damage. What that means in practice depends on the entity type:
| Entity | Yardstick | Legal nature |
|---|---|---|
| eleven digital entity types, such as cloud computing, data centres and managed service providers (full list in the sector directory) | Articles 3 and 4 of Implementing Regulation (EU) 2024/2690 and the thresholds per entity type in Articles 5 to 14, for example, for cloud and managed service providers, a service that is completely unavailable for more than 30 minutes | legally binding |
| all other entities | according to the BSI: significant if at least one criterion of Article 3(1) of the Implementing Regulation is met; also always if the provision of critical services has failed or is impaired | BSI guidance |
The criteria of Article 3(1) of the Implementing Regulation, one of which is enough:
- direct financial loss of more than €500,000 or 5% of the previous year’s annual turnover, whichever is lower,
- exfiltration of trade secrets, caused or possible,
- death of a person or serious damage to a person’s health, caused or possible,
- successful, suspectedly malicious and unauthorised access to network and information systems capable of causing severe operational disruption.
Recurring incidents count together if they have occurred at least twice within six months with the same apparent root cause and together exceed the loss threshold (Article 4). Planned maintenance and its planned effects are not a significant incident (Article 3(2)). Section 56(4) BSIG provides for a separate German ordinance on significance; none of the sources we checked mentions one having been issued.
Which reporting stages and deadlines apply?
Three mandatory stages, an intermediate report on request and, for ongoing incidents, a progress report:
| Stage | Deadline | Content | Basis |
|---|---|---|---|
| early warning | without undue delay, at the latest 24 hours after becoming aware | whether the incident is suspected of having been caused by unlawful or malicious acts or could have cross-border impact | Section 32(1) sentence 1 no. 1 |
| incident notification | without undue delay, at the latest 72 hours after becoming aware | information from the early warning confirmed or updated, initial assessment with severity and impact, indicators of compromise where available | Section 32(1) sentence 1 no. 2 |
| intermediate report | at the request of the BSI | relevant status updates | Section 32(1) sentence 1 no. 3 |
| final report | at the latest one month after submission of the 72-hour notification | detailed description with severity and impact, type of threat or root cause, mitigation measures applied and ongoing, cross-border impact where applicable | Section 32(1) sentence 1 no. 4 |
| progress report | at the time the final report is due, if the incident is still ongoing | instead of the final report; the final report follows once the incident has been handled | Section 32(2) |
Three points that are easy to get wrong:
- The one-month period runs from the 72-hour notification, counted from its submission and independent of when you became aware of the incident. Submitting the notification earlier also brings the date for the final report forward.
- The BSIG sets no deadline for the final report after a progress report. It is due once the incident has been handled. The NIS2 Directive (EU) 2022/2555 provides for one month after the incident has been handled (Article 23(4)(e)); that is useful orientation but does not replace the German wording. The report may still not come arbitrarily late: a final report under Section 32(2) sentence 2 that is not submitted in time is subject to a fine (Section 65(2) no. 5). Submit it without delay once the incident has been handled.
- The deadlines are maximum periods. The BSI stresses that they should not be used up. It regards the point of becoming aware as the moment at which an employee of the entity learns of a significant incident during working hours.
The BSI acknowledges receipt of a report without undue delay and, where possible, within 24 hours, and on request offers guidance or operational advice (Section 36(1)). The Directive states that reporting alone does not expose the entity to increased liability (Article 23(1)). The BSIG has no rule of its own on this; the consequences of a report in an individual case need legal review.
How and where do you report?
Reports go through the BSI portal. According to the BSI, entities that are in scope but not yet registered in the portal report through an online form in the reporting and information portal (Melde- und Informationsportal, MIP); operators of critical facilities and federal authorities temporarily use their existing reporting channels. Logging in to the BSI portal requires an ELSTER organisation certificate, see NIS2 registration.
- Who reports: According to the BSI, in principle any employee can report; access to the reporting office must be set up for the persons authorised to report. Service providers can be authorised to report; responsibility for the incident and the content remains with the entity.
- Speed before completeness: A report cannot be withdrawn. Errors and gaps are corrected and filled through follow-up reports.
- Documentation: Beyond the report itself there is no documentation obligation; the BSI nevertheless considers it useful to document and evaluate reports.
- After the report: The BSI can order the entity to inform the recipients of its services about the incident (Section 35(1)) or, after a hearing, require it to inform the public (Section 36(2)). It expects internal routes for reaching suitable contacts outside business hours as well.
Failing to submit a report, or submitting it incorrectly, incompletely or late, is an administrative offence (Section 65(2) nos. 4 and 5 BSIG). The maximum fine is €10 million for essential entities and €7 million for important entities; where total turnover exceeds €500 million, it can reach 2% or 1.4% of total turnover respectively. The other offences are listed in the overview of NIS2 requirements. According to the BBK, there is currently no reporting obligation under the German KRITIS umbrella act (KRITIS-Dachgesetz) yet; in any case, its Section 2 no. 9 excludes events that are solely IT security incidents.
Reporting process: roles and timeline
The law sets deadlines but leaves the internal organisation to you. The following allocation of roles is our recommendation for entities with a small IT team; each role needs a named deputy.
| Role | Task in the reporting process | Possible staffing |
|---|---|---|
| Person who detects | reports every suspicion internally to on-call IT at once; does not wait for certainty | all staff, IT service providers |
| On-call IT | first technical assessment, immediate measures, informs the incident manager | head of IT, on-call duty, service provider |
| Incident manager | decides on significance, starts the reporting clock, keeps the incident log | information security officer or head of IT |
| Person authorised to report | submits the reports in the BSI portal and tracks the deadlines | two people with portal access set up |
| Management body | informed at once if the incident is significant, decides on external communication and resources | managing directors |
| Legal, data protection, communications | check further reporting obligations, for example under data protection law, and customer information | internal or external |
The timeline separates statutory deadlines from internal target times. The target times are recommendations that you adapt to your situation.
| Time | Step | Who | Statutory deadline or recommendation |
|---|---|---|---|
| T0 | becoming aware of the incident, internal report to on-call IT | person who detects | by law, the deadlines start when you become aware of a significant incident; we recommend counting cautiously from first awareness |
| T0 + 1 h | incident manager informed, log started | on-call IT | recommendation |
| T0 + 4 h | decision on significance, management body informed | incident manager | recommendation |
| T0 + 8 h | early warning submitted | person authorised to report | recommendation; by law at the latest T0 + 24 h |
| T0 + 48 h | incident notification with initial assessment submitted | person authorised to report | recommendation; by law at the latest T0 + 72 h |
| on request | intermediate report | person authorised to report | by law at the request of the BSI |
| 72-hour notification + 1 month | final report or, if the incident is ongoing, progress report | incident manager | by law at the latest |
| after closure | final report following a progress report, evaluation and lessons learned | incident manager | by law without a fixed deadline, but not arbitrarily late (see above); recommendation: within one month |
Example: encryption on a Friday morning
Fictitious example, not a client. A food manufacturer with 300 employees is classified as an important entity (Annex 2, industrial production of food). On Friday, 13 November 2026, at 10:15, an employee notices that files on a file server have been encrypted.
- 10:15: internal report to on-call IT. IT disconnects the server from the network and finds signs of access via a compromised account.
- 11:30: The incident manager assesses the situation: successful, suspectedly malicious, unauthorised access that can disrupt production planning. Using Article 3(1)(e) of the Implementing Regulation as orientation, she classifies the incident as significant and informs the managing directors.
- 13:00: early warning via the BSI portal, stating the suspicion of a malicious act; no cross-border impact is apparent. Statutory latest time: Saturday, 14 November 2026, 10:15.
- Monday, 16 November 2026, 09:00: incident notification with initial assessment, severity, affected systems and indicators of compromise. Statutory latest time: Monday, 10:15.
- Wednesday, 16 December 2026: one month after the notification (our calculation). Restoring production planning is still under way, so a progress report goes to the BSI.
- January 2027: once the incident has been handled, the final report follows with root cause, mitigation measures and impact.
What worked in the example: two people had access to the BSI portal, significance was decided against prepared criteria, and the early warning went out before all the facts were established.
Reporting exercise: how to test the process
A reporting exercise tests whether roles, access and deadlines work in an emergency. We recommend the following sequence at least once a year and after every change in one of the roles. Important: no report is submitted to the BSI during the exercise, because submitted reports cannot be withdrawn. The exercise works with an internal copy of the form contents.
| Phase | Duration | What is tested | Result |
|---|---|---|---|
| 1. Preparation | 1-2 hours | scenario that matches your own operations, exercise lead, observers, time keeping | script with injects |
| 2. Trigger | 15 minutes | Does the internal report reach on-call IT, including outside core hours? | measured time to response |
| 3. Significance | 30 minutes | Does the incident manager decide against the criteria and document the reasoning? | decision with reasoning in the log |
| 4. Draft early warning | 30 minutes | Is all the information available that the BSI asks for in the early warning? Can the person authorised to report log in to the portal without submitting anything? | completed draft, login confirmed |
| 5. Escalation | 15 minutes | Is the management body informed, and who decides on informing customers and staff? | documented decision |
| 6. 72-hour notification | 30 minutes | assessment with severity, impact and indicators of compromise in draft | completed draft |
| 7. Evaluation | 1 hour | times against target times, gaps, owners and dates | action list, report on results to the management body |
Three typical gaps
| Gap | Cause | Effect | Remedy |
|---|---|---|---|
| Nobody can access the BSI portal during an incident | the ELSTER organisation certificate sits with one person or with accounting | the 24-hour deadline passes although the incident has been detected | at least two persons authorised to report, with access set up; test access in every reporting exercise |
| Significance is assessed only after the root cause analysis | no prepared criteria, fear of a “wrong” report | the report comes too late; speed before completeness is turned upside down | prepare the criteria of Article 3(1) of the Implementing Regulation as a decision aid; plan for corrections through follow-up reports |
| Final report scheduled wrongly | one-month period counted from becoming aware, or progress report unknown | date missed or report incomplete | enter the deadline, counted from submission of the 72-hour notification, in the log; plan for a progress report if the incident is ongoing |
This page provides general information. Whether a specific incident is significant has to be assessed in the individual case and, where in doubt, reviewed by a lawyer. If you want to know how reliable your reporting process is alongside the other obligations, the NIS2 gap analysis is the structured starting point.
Frequently asked questions
When does the 24-hour period start?+
When is the final report due?+
What if a reported incident turns out to be harmless?+
May our IT service provider report on our behalf?+
Do we have to report if we have not registered yet?+
Do near misses have to be reported?+
Read more
Sources
- BSIG Section 32: reporting obligations (gesetze-im-internet.de, as amended on 22 October 2026, German) (retrieved 2026-11-06)
- BSI Act (BSIG), consolidated version with Sections 2, 28, 35, 36, 56 and 65 (gesetze-im-internet.de, German) (retrieved 2026-11-06)
- Implementing Regulation (EU) 2024/2690, Articles 3 to 14 (retrieved 2026-11-06)
- Directive (EU) 2022/2555, Article 23 (retrieved 2026-11-06)
- BSI: NIS‑2 info package on reporting obligations (German) (retrieved 2026-11-06)
- BSI: general NIS‑2 FAQ (German) (retrieved 2026-11-06)
- BBK: FAQ on the KRITIS umbrella act (German) (retrieved 2026-11-06)
This content provides general technical and organisational information and does not constitute legal advice (no legal services within the meaning of the German RDG).