This guide explains the general German reporting duty under the BSIG. Special regimes, particularly for certain energy, telecommunications and financial undertakings, must first be identified. Trust service providers must also observe the directly applicable eIDAS notifications within 24 hours explained below. This guide replaces neither your entity’s incident assessment nor an individual administrative decision. Section 28(5)–(7), section 32 BSIG.
Overview of the staged reporting system
The common description “four stages” comprises an early initial notification, a follow-up notification, an intermediate report required only on request, and a final report. Not every incident therefore results in four standard forms becoming due in sequence.
Context and limits of evidence
The same point of awareness, different subsequent deadlines
On narrow screens, scroll the table sideways.
| Step | Deadline and trigger | Content under section 32 |
|---|---|---|
| Early initial notification / early warning | Without undue delay, no later than 24 hours after becoming aware of the significant security incident | In particular, whether unlawful or malicious acts are suspected or cross-border effects are possible. |
| Follow-up notification | Without undue delay, no later than 72 hours after the same awareness | Update of the initial notification, an initial assessment of severity and impact and, where available, indicators of compromise. |
| Intermediate report | At the BSI’s request | Relevant status updates; the request determines the specific subsequent procedure. |
| Final report | No later than one month after submitting the follow-up notification under subsection (1), first sentence, point 2 | A detailed description of severity and impact, the likely threat type or cause, remedial measures and, where applicable, cross-border effects. |
General German BSIG procedure: the 24 and 72 hours run from the same awareness. The month starts when the follow-up notification is submitted; an intermediate report is due only on request. If the incident is ongoing, a progress report replaces the final report at the one-month deadline. A final report follows after the incident has been fully handled (section 32(2)), without an additional numerically specified monthly deadline in German law. The separate 24-hour notifications for trust services are explained in the next section.
Scope of the table: the general German procedure under section 32; the additional 24-hour notifications for trust services are addressed separately below.
Source for the deadlines and content: Section 32(1), first sentence, points 1–4 BSIG. “Without undue delay” does not permit waiting until the hourly limits expire without a reason. “One month” is not a blanket period of 30 days.
Synthetic example for the general BSIG procedure: If the significant incident becomes known at 10:00 on Friday, 25 September 2026, the outer limits are 10:00 on Saturday, 26 September and 10:00 on Monday, 28 September. An initial notification at 12:00 on Friday does not restart the 72 hours. Section 32 contains no general weekend pause. Do not wait until the following working day to start assessment and escalation.
If the incident is still ongoing after one month
If the incident is still ongoing one month after the follow-up notification was submitted, section 32(2), first sentence, requires a progress report at that point instead of the final report. Under the second sentence, the final report must be submitted to the BSI after the incident has been fully handled. The German subsection specifies no additional numerical monthly deadline for this later final report.
This differs from Article 23(4)(e) of the EU Directive: for an ongoing incident, that provision requires the final report no later than one month after the incident has been handled. The Directive’s deadline is not presented here as identical wording in German law. For your procedure, this means meeting the one-month deadline even while handling continues, documenting completion of the handling, and then preparing and submitting the final report. As an organisational recommendation, this should happen without avoidable delay. This does not create another German one-month deadline or insert an “immediately” requirement into the statute. Section 32(2) BSIG, Article 23(4)(e) NIS2.
Special rules for trust services
Trust service providers must not generally allow 72 hours for their sectoral notifications. Alongside the BSIG, the directly applicable eIDAS Regulation contains separate notification duties. They concern qualified or non-qualified providers when providing the relevant trust services, not every company that uses certificates, electronic signatures or email.
The triggers are security breaches or disruptions in service provision or the specified operational measures that have a significant impact on the trust service or the personal data stored within it. This is a separate legal trigger, not simply a renamed BSIG notification.
On narrow screens, scroll the table sideways.
| eIDAS duty | Deadline wording and recipients |
|---|---|
| Non-qualified providers, Article 19a(1)(b) | Without undue delay, no later than 24 hours after becoming aware. Notify the supervisory body and identifiable affected individuals, also the public where this is in the public interest, and other relevant authorities where applicable. |
| Qualified providers, Article 24(2), first subparagraph, point (fb) | Without undue delay, in any event within 24 hours after the incident. Notify the supervisory body and identifiable affected individuals, and other relevant authorities where applicable; notify the public at the supervisory body’s request where this is in the public interest. |
The German text of the second provision specifically does not use the same awareness wording as Article 19a. Record the time of the event and the time of awareness separately, and initiate the relevant notifications without undue delay once the facts become known; do not plan a blanket additional 24-hour waiting period from awareness. This explanation does not decide fault or sanctions for an incident discovered only later. eIDAS, Article 19a(1)(b) and Article 24(2), first subparagraph, point (fb).
In Germany, section 2(1) VDG assigns supervision of the specified signature, seal, time-stamp and registered delivery services, and associated preservation services, to the Federal Network Agency. The BSI is responsible for the creation, verification and validation of website authentication certificates. Under subsection (2), BSIG responsibilities remain unaffected. Define the competent recipient and specific submission route for each service in the reporting plan; a report to the joint BSIG reporting office does not automatically demonstrate notification of every eIDAS recipient. Section 2 VDG.
A separate issue is Article 23(4), second subparagraph NIS2: for significant incidents affecting trust services, it requires the more detailed notification under point (b) within 24 hours of awareness. Section 32 BSIG does not expressly state this shorter period. The Directive is neither read into the German wording here nor treated by itself as a directly applicable basis for imposing that duty. The separate eIDAS notifications apply regardless of this transposition difference. In practice, both sets of duties are tracked separately in the incident plan; 72 hours is not general permission to wait. Article 23(4) NIS2, section 32 BSIG.
What is a significant security incident?
The assessment has two steps. First, there must be a security incident: an event that actually compromises the availability, integrity or confidentiality of data or services. A vulnerability alone or an attempt repelled without consequences is not, merely for that reason, such an incident. Its significance must then be assessed. Section 2, points 1, 11, 38 and 40 BSIG.
Under section 2, point 11, one of the listed consequences or possible consequences is sufficient: severe operational disruption of services or financial loss for the entity, or significant material or non-material harm to other persons. The damage need not yet have fully occurred or been quantified. The general German definition contains no fixed minimum euro amount applying to every entity.
On narrow screens, scroll the table sideways.
| Observation | Appropriate next assessment |
|---|---|
| An external check finds a missing security header. | Address the configuration finding. This alone establishes neither actual compromise nor significant incident impact. |
| An attack was fully repelled without compromising data or services. | Assess the near miss and possible voluntary notification; do not automatically treat it as a significant security incident. |
| Unauthorised access to an important system is confirmed; the consequences are not yet fully known. | Assess the impact and possible significant damage without undue delay. Do not wait for completed forensics or a final loss figure. |
| An email service suffers a prolonged outage that affects an essential service. | Assess the cause, duration, users, affected services and possible consequences; sectoral criteria may further define significance. |
| Personal data has been disclosed without authorisation. | Also assess the data protection notification duty separately; its conditions and recipients differ. |
Additional criteria for certain digital services
The digital services and trust services listed in Article 1 of Implementing Regulation (EU) 2024/2690 are subject to its criteria. Examples include DNS, cloud and data centre services, and managed service providers; an ordinary user of a cloud or email service does not thereby automatically become part of this provider group.
Article 3 sets out several independent cases of significance. One concerns direct financial losses above EUR 500,000 or above 5% of total annual turnover in the preceding financial year, whichever threshold is lower. Other cases concern, for example, trade secrets, serious harm to health or certain successful unauthorised access. There are also recurring incidents under Article 4 and service-specific criteria in Articles 5–14. For DNS services, for example, Article 5 includes complete unavailability for more than 30 minutes. The euro rule is therefore neither a universal limit nor the only reporting threshold. Implementing Regulation (EU) 2024/2690, Articles 1 and 3–5.
The BSI also uses the criteria in Article 3(1) as guidance for other entities: according to its guidance, significance may be assumed when those criteria are met. This administrative guidance does not automatically make the whole Regulation applicable to every sector, nor does it provide general reassurance below those values. BSI: guidance on NIS2 reporting duties.
When does awareness arise?
An ambiguous alert is not the same as awareness of a significant incident. Suspicious events must nevertheless be assessed promptly. For entities covered by the Implementing Regulation, recital 31 explains awareness by reference to an initial assessment that establishes a significant incident with reasonable certainty. It does not permit delaying that assessment.
The BSI explains the German starting point as follows: awareness by an employee during their working hours is sufficient; informing management or obtaining its approval is therefore not the starting point. This is an interpretation by the authority, not a literal addition to section 32. Organise short escalation routes and record when reliable information became available. The wording about working hours does not create a general weekend pause in deadlines for the entity. BSI reporting guidance, Implementing Regulation, recital 31.
How and where do you report?
The statutory recipient is the joint reporting office of the BSI and the Federal Office of Civil Protection and Disaster Assistance. Section 32(1), second sentence, provides that the obligation starts no earlier than establishment of the reporting route. Lack of registration does not postpone an existing reporting duty.
For cross-border digital providers, jurisdiction must be checked first: section 60 includes rules on the main EU establishment and representatives of providers without an EU establishment. The German reporting office is therefore not automatically responsible for every service with German customers. Section 60 BSIG.
According to the BSI guidance read for this article, the BSI portal is intended for NIS2 registration and incident reporting. For entities not yet registered, the BSI refers to the MIP online form for reports without registration. Operators of critical installations and federal authorities should continue using their established MIP procedures during the transition. The correct classification of your reporting case is decisive; several available routes do not imply a request for unnecessary duplicate reports. BSI: registration and reporting routes, BSI reporting duties.
Check access, permissions, deputies and the route specified by the authority before an incident. A general contact form, a vulnerability report or a message to the data protection officer does not automatically replace the required notification to the competent body.
Registration and incident reporting are different tasks
Registration under section 33(1) is generally required no later than three months after an entity first enters scope or enters scope again. The first deadline, 6 March 2026, concerns entities already in scope on 6 December 2025. Later entry into scope starts its own deadline. Certain digital entity types must also provide the information under section 34.
For critical installations, reading the section 33 currently displayed in isolation is insufficient: section 66 keeps parts of the earlier version applicable until the KRITIS ordinance specified there enters into force. These include additional registration information and the previous rule on annual changes to certain supply and component data; other changes must generally be notified without undue delay, no later than two weeks after awareness. The new KRITIS framework is not a general suspension of existing NIS2 registration. Sections 33, 34, 66 BSIG.
What workable reporting preparation includes
Keep an incident log with times, the information known and decisions. Record affected services, known or possible impacts, contacts, measures already taken and open questions. For operators of critical installations, section 32(3) requires additional information about the affected installation and critical service.
Distinguish confirmed facts from working hypotheses. Submit the legally required information based on what is known at each stage and supplement it as the procedure continues. According to the BSI, corrections should be made through updates or follow-up notifications; incomplete knowledge is no reason to withhold the first notification until analysis is finished. The log structure recommended here is a working aid, not an additional statutory list of forms.
Which other notifications may be required?
For a personal data breach, the controller must also assess Article 33 GDPR: notify the competent data protection authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to natural persons’ rights and freedoms. Processors inform the controller without undue delay. Where a high risk is likely, communication to the affected individuals under Article 34 may also be required. GDPR, Articles 33–34.
DORA financial entities face different reporting sequences and deadline triggers. Neither the GDPR nor DORA can be dealt with simply by copying the BSIG table. A shared internal case file may help; legal bases, thresholds, recipients and submissions must still be assessed separately.
What can happen if a report is omitted or late?
Section 65(2), points 4 and 5, covers reporting offences. For the relevant offences, subsection (5), first sentence, point 1 provides maximum fine limits of up to EUR 10 million for particularly important entities and EUR 7 million for important entities. For an undertaking with worldwide total turnover above EUR 500 million, the turnover-based limits in subsections (6)–(8) of up to 2% or 1.4% apply to the covered cases. These are not automatic fines after every incident. Registration offences have a different limit. Section 65 BSIG.
What an external check contributes to assessment
An external Web, Email or API Check can record selected publicly observable configurations. It is not continuous incident detection, forensic evidence or a complete picture of your entity’s situation. A missing header or DNS record does not prove a reportable attack; a good score does not rule one out either.
In your case file, distinguish the technical observation, the risk inferred from it and the established event. Add internal logs, information from affected service providers and actual impacts. The reporting decision rests on these facts and the applicable law, not on a score.
Test the reporting chain before an incident
Work through a synthetic incident with those responsible: who assesses significance? When does the clock start? Who can report when someone is absent? Where are the access details and secure means of communication? Who adds information and follows through to closure?
Document and close the gaps you identify. Self-reported answers about existing processes do not yet confirm a working reporting route. The NIS2 checklist organises the other measures; the management responsibility guide explains implementation, oversight and delegation.