NIS2 Incident Reporting: What, Who, How (24/72/30)

Main article: Section 30 BSIG: 10 obligations — the ten mandatory measures under § 30(2) BSIG, which include handling security incidents.

Who has to report: only classified entities

Only those classified by law as a particularly important entity or an important entity have to report — the reporting chain in § 32(1) BSIG is expressly addressed to these two groups, not to every company with an IT incident.

In Germany, classification under § 28 BSIG is linked to a type of entity listed in the Annexes to the BSIG. A particularly important entity includes anyone operating a type under Annex 1 with at least 250 employees, or an annual turnover of more than EUR 50 million together with an annual balance sheet total of more than EUR 43 million (§ 28(1) BSIG); irrespective of size, this also covers operators of critical installations, qualified trust service providers, top-level domain name registries, DNS service providers and certain providers of telecommunications services. An important entity is anyone attributable to a type under Annex 1 or Annex 2 with at least 50 employees, or an annual turnover and an annual balance sheet total each exceeding EUR 10 million, unless they already qualify as a particularly important entity (§ 28(2) BSIG). Size alone does not carry the classification under § 28 BSIG: it only takes effect together with attribution to a type of entity under Annex 1 or Annex 2 (§ 28(1) and (2) BSIG). Federal administration entities are not covered via Annex 1 but separately under § 29 BSIG. For calculating employee numbers, turnover and balance sheet total, Recommendation 2003/361/EC applies, with the exception of Art. 3(4) of its Annex (§ 28(4) BSIG).

In Austria, classification runs in parallel from the date the NISG 2026 becomes applicable on 1 October 2026: large companies of an Annex 1 type are essential entities; entities of the Annex 1 and Annex 2 types that are large or medium-sized companies are important entities (§ 24(1) and (2) NISG 2026). Large there means: at least 250 employees or an annual turnover of more than EUR 50 million with a balance sheet total of more than EUR 43 million; medium-sized: at least 50 employees or an annual turnover of more than EUR 10 million with a balance sheet total of more than EUR 10 million (§ 25(2) and (3) NISG 2026).

What has to be reported: the significant security incident

Only a significant security incident triggers the reporting chain. In Germany, an incident is significant if it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity, or if it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage (§ 2 no. 11 BSIG). Austria uses the same two-part test, but in the first limb requires severe operational disruption or severe financial loss (§ 35(1) no. 1 NISG 2026); the second limb (considerable material or non-material damage to other persons) corresponds to the German one (§ 35(1) no. 2 NISG 2026).

Quantitative thresholds exist only in part: EU Implementing Regulation 2024/2690 specifies significance with numerical criteria — including the number of users affected, financial impact and duration — but only for certain digital types of entity such as DNS service providers, TLD name registries, cloud and data centre services, CDN, managed (security) service providers, online marketplaces, search engines, social networks and trust service providers (cf. § 30(3) BSIG). For all other entities in Germany, only the definition in § 2 no. 11 BSIG applies until a statutory instrument is issued under § 56(5) BSIG. Practitioner recommendation: record the significance assessment together with its reasoning in writing — including where the outcome is negative and no report follows.

The 24/72/30 reporting chain at a glance

The reporting chain has four stages: early warning within 24 hours of becoming aware, report with an initial assessment within 72 hours of becoming aware, intermediate report upon request by the authority, and final report within one month of the 72-hour report (§ 32(1) nos. 1 to 4 BSIG). All stages go to the same place: in Germany to the joint reporting office of the BSI and the BBK (§ 32(1) BSIG), in Austria to the competent sector-specific CSIRT and, where there is none, to the national CSIRT (§ 34(1) NISG 2026). For the 24-hour and the 72-hour stages, the period starts when the entity becomes aware. The content column reflects the German version under § 32 BSIG; the Austrian chain under § 34(2) NISG 2026 matches the stages and periods of § 32(1) nos. 1 to 4 BSIG; for the progress report, Austria additionally sets an express one-month period (see the last table row). The references are in the last column, the differences in the Austria section.

The shorthand 24/72/30 is a memory aid. In law, the periods are 24 hours, 72 hours and one month — the third period is a monthly period, not a 30-day window, and it runs from the 72-hour report. Example: becoming aware on Friday at 22:10 — early warning by Saturday 22:10; report with initial assessment by Monday 22:10; final report one month after the report with the initial assessment as actually submitted — if that report is submitted before the period expires, the month runs from that earlier point in time (§ 32(1) no. 4 BSIG).

1. Detecting the incident

Detection is the step that starts the clock: in law, all that counts is when the entity becomes aware — the 24 and the 72 hours run from that point, not from the start of the incident (§ 32(1) nos. 1 and 2 BSIG). Triggers: SOC alert, IT failure, supplier notice, user report. Activate the crisis team within 30 minutes — Practitioner recommendation: these 30 minutes are an internal response time, not a statutory period.

Immediately after becoming aware, the significance assessment under § 2 no. 11 BSIG follows — it determines whether the reporting chain starts at all. Practitioner recommendation: record the point of awareness with date, time and source, because it determines both periods and should remain demonstrable at every later stage; define in advance who assesses significance and who approves the report, so that this decision does not have to be organised during the incident. These roles should be reachable around the clock, because the 24-hour period is not tied to business hours.

2. 24h initial report to the BSI

Within 24 hours of becoming aware, the early initial report goes to the joint reporting office of the BSI and the BBK (§ 32(1) no. 1 BSIG). Portal: bsi.bund.de/meldungen. The portal has been online since 6 January 2026 and accepts reports in structured form. Customary details in practice alongside the statutory content (see the table above): point in time, type (ransomware/DDoS/etc.), first damage estimate, measures, contact person. Practitioner recommendation: settle the registration under § 33(1) BSIG in advance — in practice it precedes the report.

The table above shows what has to be submitted in terms of content; in addition, what counts here is: the 24 hours are an upper limit, not a deadline date — the law requires the report without undue delay, at the latest within 24 hours. Type of threat and root cause only belong in the final report (§ 32(1) no. 4 BSIG) — the initial report is an early warning, and its information is confirmed or updated in the 72-hour report (§ 32(1) no. 2 BSIG). Practitioner recommendation: report within the period even with an incomplete picture, and update in the 72-hour report.

3. 72h update

At the latest 72 hours after becoming aware, the report with the initial assessment follows (§ 32(1) no. 2 BSIG). Customary content of the report in practice: detailed damage assessment, technical indicators (IOCs), vulnerability identification, further measures.

The table above shows what has to be submitted in terms of content; in addition, what counts here is: indicators of compromise only have to be submitted where available (§ 32(1) no. 2 BSIG). Independently of the three time stages, the BSI may at any time require an intermediate report on relevant status updates (§ 32(1) no. 3 BSIG); Austria likewise provides for an interim report upon request (§ 34(2) no. 3 NISG 2026). Practitioner recommendation: indicators of compromise typically come from the technical analysis by your own SOC or by a forensics service provider — clarify in advance who prepares and approves them, so that this stage does not fail on delivery; also keep the assessment running in the incident log, so that a request for an intermediate report can be answered without reworking it.

4. Final report (1 month)

The final report is due at the latest one month after the 72-hour report (§ 32(1) no. 4 BSIG) — not from the end of the incident. It contains the detailed description of the incident, the type of threat and the root cause (root cause analysis, lessons learned) as well as the remedial measures taken and ongoing (measures plan and prevention strategy), supplemented where applicable by cross-border effects.

If the incident is still ongoing at that point, the progress report takes its place first (§ 32(2) BSIG); the final report follows only once handling has been completed. In Austria, in that case the final report has to be submitted within one month of the end of incident handling (§ 34(2) no. 5 NISG 2026).

5. Parallel GDPR Art. 33

In the case of a Personal Data Breach: ADDITIONALLY a 72-hour report to the competent supervisory authority (Art. 33(1) GDPR) — in Germany to the competent state data protection authority (or the Federal Commissioner for Data Protection (BfDI)), in Austria to the Austrian Data Protection Authority (Datenschutzbehörde, DSB). The addressee is the supervisory authority, not your own data protection officer. NIS2 and the GDPR run in parallel.

The data protection period begins once the controller becomes aware of the breach; the report has to be made without undue delay and where feasible within 72 hours. It is not required if the breach is unlikely to result in a risk to the rights and freedoms of natural persons; where the report is made later than 72 hours, it has to be accompanied by reasons for the delay (Art. 33(1) GDPR). Where a high risk is likely, communication to the data subjects is added (Art. 34(1) GDPR); it is not required if appropriate protective measures such as encryption were applied, if the high risk no longer exists following subsequent measures, or if the communication would involve disproportionate effort — a public communication then takes its place (Art. 34(3) GDPR). The triggers differ: NIS2 asks about severe operational disruption, financial loss or considerable damage to third parties (§ 2 no. 11 BSIG), the GDPR about the risk to the rights and freedoms of natural persons (Art. 33(1) GDPR). There is a limit on sanctions: if a data protection supervisory authority has already imposed a GDPR fine for the same conduct, an additional fine under the BSIG is excluded (§ 65(11) BSIG).

6. Supplier escalation

What matters is not where the incident happened, but whether it reaches the threshold of a significant security incident under § 2 no. 11 BSIG for your entity: if an incident at a service provider reaches that threshold, you have to report — even where you are not primarily responsible; your 24-hour period runs from when you become aware.

So that this awareness arises early enough, § 30(2) no. 4 BSIG requires supply chain security measures; in Austria the corresponding obligation is in § 32(4)(d) NISG 2026. Practitioner recommendations for contract drafting — not statutory periods, but arrangements you agree yourself: the supplier reports to you within 24 hours, a supplier questionnaire with risk classification, cybersecurity clauses in the standard contract, and a right to audit for critical suppliers. A supplier is critical here if its failure or compromise can reach the threshold of § 2 no. 11 BSIG at your organisation — that is, would trigger severe operational disruption or considerable damage to third parties. The clause should at least cover: a reporting channel reachable around the clock with a named contact person, cooperation with your reports under § 32 BSIG, and the passing on of indicators of compromise. Where personal data are processed on your behalf, the data processing agreement under Art. 28(3) GDPR is added, setting out the subject matter, duration, nature and purpose of the processing as well as the obligations and rights of the controller; you should expressly cover the reporting channels between the Data Processor and the controller there as well (practitioner recommendation).

Austria (NISG 2026): reporting to the CSIRT instead of the BSI

DE/AT difference: The walkthrough above describes the German reporting route via the BSI portal. In Austria, the same stages and periods apply, but the report does not go to the BSI; it goes to the competent (sector-specific or national) CSIRT under § 34 NISG 2026; the supervisory authority is the Cybersecurity Authority (Cybersicherheitsbehörde). Fine range: up to EUR 10 million or 2% of worldwide annual turnover (essential entities), or EUR 7 million or 1.4% (important entities) under § 45 NISG 2026.

This reporting route becomes binding when the NISG 2026 becomes applicable on 1 October 2026; the act has been promulgated since 23 December 2025 (BGBl. I Nr. 94/2025). Under § 34(1) NISG 2026, the addressee is the competent sector-specific CSIRT and, in the absence of one, the national CSIRT; from there the report is forwarded to the Cybersecurity Authority. As long as no national CSIRT exists, GovCERT performs its tasks (§ 8(4) last sentence in conjunction with the transitional rule in § 51(6) NISG 2026); for public administration, GovCERT is the sector-specific CSIRT (§ 8(4) NISG 2026). The authority competent for supervision and enforcement is the Federal Office for Cybersecurity (Cybersecurity Authority, Cybersicherheitsbehörde), an authority directly subordinate to the Federal Minister of the Interior and based in Vienna (§ 3a(1) and (2), § 3b(3) NISG 2026); administrative penalties, by contrast, are imposed by the district administrative authority (§ 44(1) NISG 2026). A group operating in both countries reports separately: in Germany, registration is via the joint registration facility of the BSI and the BBK, at the latest three months after an entity first qualifies as a particularly important or important entity (§ 33(1) BSIG); in Austria, with the Cybersecurity Authority within three months of entry into force, that is by the end of 2026 (§ 29(2) and (3) NISG 2026).

Incident documentation: what has to run alongside the reporting chain

Documentation is itself an obligation: § 30(1) BSIG requires compliance with the risk management measures to be documented — that is, not only the measures themselves but their being complied with — and handling security incidents is one of the ten mandatory areas (§ 30(2) no. 2 BSIG; in Austria § 32(4)(b) NISG 2026).

The minimum structure of the incident file follows directly from the reporting stages (see the table above): whatever you have to report at each stage has to be available from the file at the time the period expires. Specifically, these are (1) the point of awareness with date, time and source, (2) the suspicion of an unlawful or malicious act as well as possible cross-border effects (24-hour stage), (3) severity, impact and indicators of compromise (72-hour stage), and (4) type of threat and root cause as well as remedial measures taken and ongoing (final report). Practitioner recommendations — established working practice, not statutory requirements: record the outcome and reasoning of the significance assessment under § 2 no. 11 BSIG in writing, keep a running log with time stamps instead of reconstructing it afterwards, keep proof of submission for each stage, maintain version control of the report texts, and have a documented approval by the management body, which has to monitor the implementation of the risk management measures in any event (§ 38(1) BSIG; in Austria § 31(1) NISG 2026).

Sanctions for an omitted or late report

Breaches of the reporting obligations carry fines. In Germany, the administrative offence can be penalised with up to EUR 10 million for particularly important entities and up to EUR 7 million for important entities (§ 65(5) sentence 1 no. 1 BSIG).

The BSIG does not apply a blanket 'whichever is higher' rule: the turnover variant — up to 2% for particularly important entities (§ 65(6) BSIG) and up to 1.4% for important entities (§ 65(7) BSIG) of worldwide total turnover — applies only where total turnover exceeds EUR 500 million and only for the breaches designated there. Total turnover is the sum of all worldwide turnover of the undertaking to which the entity belongs, in the financial year preceding the authority's decision (§ 65(8) BSIG). In Austria, by contrast, the higher amount in each case applies: up to EUR 10 million or 2% of total worldwide annual turnover for essential entities (§ 45(2) NISG 2026) and up to EUR 7 million or 1.4% for important entities (§ 45(3) NISG 2026); other infringements are penalised with up to EUR 50,000, and up to EUR 100,000 in the event of repetition (§ 45(4) NISG 2026).