BSI security incident notification: The 24-hour workflow under NIS-2
NIS-2 (§ 32 BSIG) requires an early warning to the BSI within 24 hours of becoming aware of a significant security incident, a follow-up report after 72 hours and a final report after one month. This post describes the complete workflow without any gaps.
§ 32 BSIG (in the version of the NIS2 Implementation Act) obliges essential and important institutions to report a significant security incident as an early warning to the Federal Office for Information Security within 24 hours of becoming aware of it, to submit a follow-up report with an initial assessment within 72 hours and to deliver a final report within one month. The deadlines are short, the content is clearly defined, and failure to do so is subject to a fine of up to 10 million euros or 2 percent of global group sales according to Section 60 BSIG.
This article describes the complete workflow operationally, not in regulatory terms. Who plays what role, what information must be available by when, what templates the BSI expects, and how the information security officer goes through the path without gaps. The article is aimed at ISB, IT management and management in the approximately 29,500 companies that are recorded in Germany according to NIS-2, and provides a workflow that works even at three in the morning. A topic overview of NIS-2 is linked on the website; The focus here is solely on reporting practices and first incident preparedness, not regulatory theory. All content refers to the legal status of May 2026.
Key Takeaways
- The 24-hour early warning to the BSI in accordance with Section 32 BSIG begins with the facility's knowledge of the incident, not with the complete technical explanation, and it can contain a justified initial assumption.
- The 72-hour follow-up message supplements the early warning with an initial assessment with severity, effect, trigger and initial countermeasures; The final report after one month contains the detailed root cause analysis.
- Without a prepared reporting path, without named roles and without a documented escalation path, the 24-hour deadline is effectively unattainable; CIVAC provides the path as a preconfigured workflow in the workspace.
What is a significant security incident according to NIS-2
The definition is in Section 2 Number 11 BSIG. A significant security incident is any incident that has caused or may cause significant operational disruption of the Services or financial loss to the entity in question, or that has or may affect other natural or legal persons through significant material or intangible damage. The definition is intentionally broad; The BSI specified in its advice from February 2026 that potential effects are also sufficient as soon as they can be specifically estimated, i.e. not just the effects that have occurred.
Practical examples are: Ransomware with encryption of productive systems, prolonged failure of a critical service (e.g. an ordering system for several hours), unauthorized access to personal data, successful phishing campaign with compromise of administrator accounts, DDoS attack with measurable impact on the Availability, or the unintentional publication of internal data due to misconfiguration. A non-exploitation pen test finding is not a reportable incident; However, an unused zero-day in a productively used system may be reportable if the discovery itself leads to significant measures.
The assessment is carried out by the Information Security Officer in coordination with the IT management and management. The ISB is not solely responsible for the report, but is responsible for preparing the report and meeting the deadline. The final decision is made by the management. The evaluation is always recorded in writing, even if it is negative and no report is made; The negative assessment with reasons protects against later accusations of having ignored the reporting obligation. This negative documentation is stored as a separate template in the CIVAC workspace. This means that every initial incident check is documented, regardless of the result.
The 24-hour early warning: content and form
The early warning to the BSI in accordance with Section 32 Paragraph 1 Sentence 1 BSIG contains: information as to whether the significant security incident is presumably due to illegal or malicious actions; an indication of whether it may have cross-border effects; a brief statement of facts and a well-founded initial assumption about the severity. Not more. The early warning is explicitly not a final report, but rather an early indicator for the BSI so that a cross-sector reaction can be made.
The period of 24 hours begins as soon as it becomes known. Knowledge exists as soon as the facility has reliable evidence that a significant security incident has occurred. Mere suspicion without evidence is not enough; However, one should not wait for complete technical clarification. In practice, this means: as soon as the ISB or the IT management is able to formulate a brief matter in writing, the countdown begins.
The form is the BSI's official reporting platform (online form via the BSI website). Pre-registration by telephone is possible and recommended in urgent cases, but does not replace written notification. The report is prepared by the ISB, approved by management and archived in the CIVAC workspace with a time stamp, content and person releasing it. The deadline expires, the workspace shows the remaining time as a countdown. In the case of very serious incidents, the BSI recommends making a short telephone call with the responsible reporting office before making a written report in order to warn the authorities and structure communication. This advance warning is voluntary and does not change the written reporting requirement. The telephone number of the reporting office is stored in the workspace and is available without searching in the event of a crisis.
The 72-hour follow-up report: initial assessment with substance
The follow-up report in accordance with Section 32 Paragraph 1 Sentence 2 BSIG will be made within 72 hours of becoming aware of it. It updates or confirms the early warning information and also includes: an initial assessment of the significant security incident, including its severity and impact; where available, the Indicators of Compromise (IoC); a description of the countermeasures taken to date; and if the impact persists, an assessment of the continued duration.
Severity and impact are captured in the CIVAC template along four dimensions: affected services or systems, number of affected users or data sets, duration of availability of the impact, and financial or reputational impact. Indicators are recorded in a structured format (hash values, IP addresses, domains, file names). This structure allows the BSI to automatically correlate the indicators with other reports and to recognise cross-sector patterns, which in turn benefits the reporting party in the form of warnings.
The follow-up report is the first opportunity to show the supervisory authority a clear picture of your own ability to react. A sloppily worded follow-up message creates questions and prolongs the process. A clearly structured follow-up report with clear numbers, clear indicators and clear countermeasures reduces the likelihood that an on-site inspection will follow. The auditor calls, the evidence is ready. Structured follow-up messages are also used in internal ISMS control because they make the maturity of the ability to respond objectively measurable and are incorporated into reporting according to ISO/IEC 27001:2022. The initial assessment is used in later audit cycles as a reference for the effectiveness of the controls, without further processing. The follow-up report should not be submitted prematurely before the 72 hours have expired, but only when the initial assessment is reliable; premature reporting leads to subsequent corrections.
The final report after one month: root cause analysis and lessons learned
No later than one month after the follow-up report, the institution submits a final report to the BSI in accordance with Section 32 Paragraph 1 Sentence 3 BSIG. The report includes: a detailed description of the security incident, including its severity and impact; the nature of the threat or root cause that likely triggered the security incident; the containment measures taken and ongoing; and, if applicable, the cross-border impacts.
The root cause is derived using a structured method, commonly the five why method or the fishbone analysis, combined with a timeline of events. Pure descriptions of symptoms are not sufficient for the BSI; The authority expects a statement on the root of the problem, such as a lack of patch discipline, a lack of multi-factor authentication, a lack of network segmentation, a lack of backup separation. This statement is also the basis for the subsequent measures, which are usually implemented within 90 days.
The final report is also the internal basis for the lessons learned session with ISB, IT management, management and, if necessary, data protection officers. The CIVAC template contains a lessons learned protocol with a list of measures, responsibilities and deadlines, which flows into the ISMS context according to ISO/IEC 27001:2022 and serves as evidence of continuous improvement during the next internal audit. Audit-proof, documented, § 32 BSIG-proof. The final report is also the basis for the next risk assessment because it documents the actually realized vulnerability and objectively tests the effectiveness of the previously documented assumptions. The resulting list of measures is given deadlines and checked for implementation in the next audit without creating a separate tracking table. A copy of the report will be sent to Group Compliance, if one exists, and to the relevant joint responsibility supervisory authority, if one existed.
Roles and responsibilities: who does what
The management bears ultimate responsibility in accordance with Section 38 BSIG. She approves the reports, she signs the final report and she is the contact person for the supervisory authority. The operational preparation of the reports lies with the ISB. The ISB collects the facts, writes the texts, meets the deadlines and executes the report in the system. The IT management provides the technical indicators, the impact analysis and the countermeasures.
In the event of personal-related incidents, the data protection officer is also involved; An NIS 2 report can also trigger a GDPR report according to Art. 33 with a 72-hour deadline. The two reporting paths run in parallel, not alternatively. The workspace manages them as separate tickets with linked issues. In the event of incidents affecting suppliers or customers, the compliance officer is informed; Contractual reporting obligations towards business partners are checked separately.
The representation regulation is mandatory. ISB vacation or ISB illness must not block the reporting path. CIVAC stipulates one representative per role in the standard contract and enables role-based handover in the workspace without data loss. Licence the workspace for your internal representatives, or have our representatives appointed, in both cases the representation is documented and verifiable in the audit trail. An additional escalation point for cases in which both the ISB and the representative fail is useful and is provided in the workspace with a third level, usually the IT management or an external crisis service provider. The third stage is checked at least annually to ensure that it is up to date and, if necessary, adjusted to accommodate changes in personnel. This multiple protection is part of the due diligence according to Section 38 BSIG and is documented in the supervisory audit; A missing third stage is considered an organisational deficiency and leads to follow-up questions from the authority.
Escalation path: From the initial indication to the released report
The first few minutes after the initial indication determines the 24-hour period. Level 1: Detection by the Security Operations Centre, by an employee or by an external tip. Stage 2: Initial assessment by the IT on-call service, usually in the first 30 minutes. Level 3: Escalation to the ISB as soon as a significant security incident is suspected. Stage 4: Pre-assessment by the ISB in coordination with the IT management, usually in the first two hours.
Stage 5: Escalation to the management as soon as the early warning threshold according to Section 2 Number 11 BSIG is reached. Stage 6: Release of the early warning by management, usually in the fourth to sixth hour. Stage 7: Transmission to the BSI via the reporting platform, with a time stamp and confirmation number. Stage 8: Activation of follow-up report preparation, parallel to the ongoing technical investigation. These eight stages are stored in the CIVAC workspace as a preconfigured workflow.
Each stage has an SLA, a person responsible and a representative. If a level is not achieved within the SLA, the system automatically escalates to the next higher level. This creates a documented process that makes the process comprehensible even in the event of a dispute and convinces the authority that the 24-hour deadline was not met randomly, but rather in a structured manner. The appointment certificate, signed, filed, verifiable, as well as the report itself. The path is practiced at least once a year as a tabletop exercise with all named roles, documented with date, participants and teaching points, and is part of the ISMS mandatory program. CIVAC provides a scenario package of three prepared incidents for the exercise, with suggested solutions and evaluation criteria that are included after each exercise in a lessons-learned format.
Templates, forms and the BSI reporting portal
Since the NIS2 implementation in 2026, the BSI has provided a digital reporting portal that supports the three reporting levels. Registration is done using the account registered by the institution; Initial registration is one of the first obligations following classification as an essential or important facility. In an emergency, anyone who fails to register cannot report within 24 hours because the registration itself takes one working day. Registration is a one-time but time-critical step.
The form structure of the BSI portal follows the order of the contents of Section 32 BSIG: identification of the facility, classification of the incident, facts, initial assumption, indicators, countermeasures, effects. Required fields are marked in colour. Attachments can be uploaded, common formats are PDF, STIX and CSV. The institution receives confirmation of the report as a signed PDF with the date of receipt and the report ID; This PDF is part of the audit trail.
CIVAC delivers the texts for each reporting level as a template in the workspace and fills the mandatory fields from the master data already in the system (facility ID, contact person, sector, location). The ISB only adds the incident-specific fields and passes on the report for approval. This template filling saves around 30 to 45 minutes per report during a crisis, i.e. exactly the time that is most scarce in the first few hours after knowledge. The templates are updated centrally as soon as the BSI changes its requirements so that the reporter always works with the current status and does not fill out outdated fields. Every template update is documented with version and date in the workspace and can be traced in the audit trail. A central care centre relieves the individual facilities of the burden of monitoring BSI information.
Fines, supervisory inspections and consequences of late reporting
§ 60 BSIG provides for fines, staggered according to the classification of the facility. For essential facilities, up to 10 million euros or 2 percent of the global group turnover of the previous financial year, whichever is higher. For important institutions up to 7 million euros or 1.4 percent of group sales. The fines can be imposed per violation; Multiple violations in one incident are possible if, for example, the early warning is late, the follow-up report is incomplete and the final report is late.
Other measures are available beyond the fines. The BSI can carry out a supervisory audit, order an external security audit, personally summon the management to a hearing and, in extreme cases, prohibit the activity. The ban is the strictest measure and has not yet been announced in the first twelve months of NIS2 implementation in Germany, but is provided for in the regulations.
The personal responsibility of management according to Section 38 BSIG is new compared to the previous regulation. Management is personally liable for compliance with security and reporting obligations and cannot resort to delegating orders. A documented reporting line from the ISB to the management with verifiable meetings and resolutions is therefore not a convenience, but rather mandatory evidence in the supervisory process. The CIVAC workspace displays this reporting line by default. The regular ISB meeting with the management is scheduled automatically, the minutes are stored in the audit trail and can be presented in the supervisory procedure without further processing. This means that management can see, without waiting, which topics are open and which deadline is next. The frequency of meetings depends on the risk class of the facility and is scheduled at least quarterly.
Turn reading into an assignment
The reporting path according to Section 32 BSIG is not a document, but a workflow. It only works under pressure if it has been fully played through before the incident, with every role named, every escalation step documented and every template approved. CIVAC delivers this workflow as a preconfigured part of the workspace, with the 490 audit templates, the 93 controls according to ISO/IEC 27001:2022 and the EU data residency, which is a prerequisite for a BSI report.
As a compliance platform and officer-as-a-service, CIVAC offers two paths. Licence the workspace for your internal representatives, or have our representatives order it. In the first case, your ISB and your IT management work in the workspace with a preconfigured reporting path. In the second case, a CIVAC ISB takes over the role within two working days, with an appointment certificate, reporting line to management and immediate activation of the reporting path. Both models fully cover the 24/72 hour deadlines, both models generate the same audit trail, and both models are backed by the central CIVAC representative in an emergency.
Turn reading into a mandate. Write to info@civac.de with your NIS 2 classification (essential or important), your sector and the current status of your reporting path, or use the contact form on civac.de. The first response contains a checklist of the necessary preparations and a cost indication, in writing within two working days, signed by the responsible representative. An optional tabletop workshop with your crisis team can be booked within two weeks of signing the contract and concludes with a documented test report in a test environment. This means that the path is not only described, but also completely traversed before the first real incident occurs.
FAQ
When does the 24-hour period begin according to Section 32 BSIG?
The period begins when the facility becomes aware of the significant security incident. Knowledge exists as soon as there are reliable indications that make a significant security incident plausible. Mere suspicion without evidence is not enough; However, one should not wait for complete clarification. The time is documented in the audit trail with the source and person so that the deadline remains traceable.
Does an incident need to be reported if it is already contained?
Yes, as long as it was significant. The reporting obligation according to Section 32 BSIG is based on the significance of the incident, not the duration of the impact. A ransomware attempt that is contained within one hour and has significant potential for damage must be reported. The rapid containment is positively documented in the follow-up report as a countermeasure, but does not change the reporting obligation itself.
Does the 24-hour period also apply on weekends and public holidays?
Yes. The deadline is a real-time deadline and does not recognise weekends or holidays. The facility's on-call service and the BSI reporting platform are available 24 hours a day, 7 days a week. Anyone who does not have a 24/7 on-call service must now contractually or organizationally ensure one, otherwise the deadline is effectively unattainable and the risk of fines is structurally present.
How is an NIS 2 report differentiated from a GDPR report according to Art. 33?
The NIS 2 message is addressed to the BSI in the event of significant security incidents; The GDPR notification addresses data protection supervision in the event of breaches of personal data with a risk for those affected. Both reports can occur in parallel, then they are created separately and transmitted separately. The 72-hour period according to Art. 33 GDPR also expires from the time of knowledge and is different in terms of content compared to the NIS 2 follow-up report, but is comparable in terms of time.
Can the ISB release the report without management?
No. The report is a declaration by the institution to the supervisory authority and is the ultimate responsibility of the management in accordance with Section 38 BSIG. The ISB prepares the report and the management approves it. If management is absent, the representation regulation applies, which is stored in the workspace with name, function and authorisation and remains verifiable in the audit trail.
What happens if the 24 hour deadline is missed?
According to Section 60 BSIG, a delayed early warning is subject to a fine of up to 10 million euros for essential facilities. The authority has discretion to take into account the reason for the delay, the willingness to cooperate and the measures taken. A clearly documented internal escalation that failed for external reasons has a mitigating effect; A missing reporting path has a more serious effect and often leads to an additional supervisory review.
Sounds like a lot of work?
Officer duties, deadlines, paperwork — that's exactly what we take off your hands. Say hello and we'll show you how.
Turn this into a mandate.
Let us carry the operational weight. External officer, templates and documentation in one workspace. No obligation.