NIS2 Reporting Obligations: The 24-Hour Early Warning in Practice
The NIS2 reporting obligations require affected entities to report significant security incidents within a staggered deadline cascade: an early warning within 24 hours, a full notification within 72 hours and a final report within one month — in each case to the competent authority or the national CSIRT respectively.
Key Takeaways
- ✓The NIS2 deadline cascade has three stages: early warning within 24 hours, full notification within 72 hours, final report within one month of the 72-hour notification.
- ✓The recipient is the competent national authority or the CSIRT — in Austria the Federal Office for Cybersecurity at the BMI provided for under the NISG 2026, in Germany the BSI under the NIS2UmsuCG in force since 6 December 2025.
- ✓The clock starts running from when the incident becomes known (awareness), not from when it began — the operational bottleneck is reliable, documented detection.
- ✓A structurally similar, staggered reporting logic also applies under the EU Cyber Resilience Act (early warning 24h, full notification 72h from 11 September 2026) and under DORA — although DORA works with a considerably tighter initial notification for ICT incidents classified as major; anyone subject to multiple regimes needs a unified reporting process.
- ✓AI-supported SOC tools assist above all with detection, complete documentation and deadline tracking; the legal responsibility and the final submission remain human.
- ✓This article does not constitute legal advice — specific thresholds and procedures must be clarified with qualified advisers in the respective jurisdiction.
The NIS2 reporting obligations require affected entities to report significant security incidents within a staggered deadline cascade: an early warning within 24 hours, a full notification within 72 hours and a final report within one month — in each case to the competent authority or the national CSIRT respectively. This cascade is the operational core on which an organisation's reporting capability is decided.
- Three deadlines, one trigger: 24 hours early warning, 72 hours full notification, one month final report — counted from awareness of the incident, not from its onset.
- One recipient channel: the competent national authority or the CSIRT (in Austria the Federal Office for Cybersecurity at the BMI provided for under the NISG 2026; in Germany the BSI).
- The real bottleneck is not the form but the detection: anyone who notices the incident late has already lost the 24-hour clock.
Why the deadline cascade exists
NIS2 replaces the old NIS Directive and considerably broadens its scope. In Germany, the number of affected companies rises from around 4,500 to roughly 29,500 according to BSI estimates; in Austria, around 4,000 companies across 18 sectors are covered. As the scope widens, so does the importance of a functioning reporting system: authorities build a situational picture from the incoming reports, warn other entities and coordinate in the event of cross-border incidents.
The staggered logic accounts for a real conflict. In the first hours of a security incident, the facts are unclear — a complete forensic analysis is not yet available. At the same time, the authorities need an early signal. The cascade resolves this by first requiring little but quickly (early warning) and then catching up on the substantive depth over 72 hours and one month.
The decisive and often overlooked point: the deadlines run from awareness of the significant incident, not from the moment the attack actually began. This shifts the compliance risk forward — into detection. This is precisely where the structural asymmetry comes into play that defender organisations know in 2026: attackers work asynchronously and are retry-tolerant, while defenders are bound to the 24-hour early warning.
The three stages in detail: deadline, content, recipient
The following table summarises the NIS2 cascade. It is intended as guidance; the exact arrangement results from the respective national implementing legislation.
Deadline | Content (core) | Recipient |
|---|---|---|
Within 24 hours (early warning) | Initial indication that a significant incident has occurred: suspicion of unlawful/malicious action, possible cross-border impacts. No full analysis required. | Competent authority / national CSIRT |
Within 72 hours (notification) | Updated assessment: severity, impacts, indicators of compromise where available; confirmation or correction of the initial indication. | Competent authority / national CSIRT |
On request (intermediate report) | Status update on relevant developments, where the authority requires it. | Competent authority / national CSIRT |
Within 1 month of the 72h notification (final report) | Detailed description: root cause analysis, mitigation measures taken and ongoing, any cross-border impacts. | Competent authority / national CSIRT |
Important: if the incident is still ongoing at the time of the one-month report, a progress report initially takes the place of the final report; the final report follows once the handling is complete.
Who is the recipient — and what changes in the DACH region?
NIS2 is an EU directive and only takes its concrete effect through the national implementing legislation. For practice in the DACH region, this means different addressees and timetables:
- Germany: The NIS2 Implementation Act (NIS2UmsuCG) has been in force since 6 December 2025 — with no transition period. The BSI is responsible; the registration portal opened at the beginning of 2026. The BSI has announced that it will actively identify unregistered entities.
- Austria: The NISG 2026 was promulgated on 23 December 2025 and enters into force on 1 October 2026. A new Federal Office for Cybersecurity within the Federal Ministry of the Interior (BMI) is provided for, which is currently being established. The law relies on self-classification and self-declaration by the affected entities.
- Switzerland (for context): Switzerland is not bound by NIS2 but has a parallel regime in the revised Information Security Act. Operators of critical infrastructures have had to report significant cyberattacks to the Federal Office for Cybersecurity (BACS) within 24 hours since 1 April 2025 — in the first six months, over 12,000 reports were already received there.
For companies operating across the DACH region, an uncomfortable reality follows: multiple reporting channels, multiple authorities, in part different thresholds. Added to this are sector-specific regimes with their own, but structurally similar, reporting logic — such as the EU Cyber Resilience Act, whose reporting obligations take effect from 11 September 2026 (early warning within 24 hours, full notification within 72 hours via the central platform at ENISA and the national CSIRT), as well as DORA for the financial sector, which provides for its own staggered incident reporting for ICT incidents classified as major, with an initial notification within four hours of classification.
Concrete example: the 24-hour clock is running
A mid-sized mechanical engineering company (likely an "important entity" under NIS2) notices unusual authentication events on Friday at 22:14. Detection is the typical bottleneck in 2026: studies show that a high proportion of detections are "malware-free" — attackers log in with valid credentials instead of breaking in, and intrusion speed has dropped drastically (average breakout time of 29 minutes in 2025, fastest observed value 27 seconds). Delayed detection, or none at all over the weekend, costs hours here that are later missing against the 24-hour deadline.
Simplified sequence:
```
22:14 Awareness — anomalous logins detected (T0, clock starts)
→ 24h clock runs until Saturday 22:14
23:30 Initial assessment: suspected compromised identity, significant?
Sat 03:00 Early warning to authority/CSIRT (within 24h):
"Significant incident, suspected malicious action,
cross-border impact currently not ruled out"
→ 72h clock runs until Monday 22:14
Mon 18:00 Full notification (within 72h):
severity, affected systems, indicators, initial measures
+1 month Final report: root cause analysis, mitigation, lessons learned
```
The decisive factor is: the early warning had to be issued at night and over the weekend. Without 24/7 detection capability — whether through an in-house SOC, an MDR provider or AI-supported triage — the 24-hour deadline would have been effectively impossible to meet.
How a process or agent provides support — and where the limit lies
AI-supported SOC tools address exactly the three pain points of the cascade: detection, documentation, deadline tracking. In productive deployments, significant efficiency gains in tier-1 triage are demonstrable — providers report a 70 to 90 percent reduction in manually handled alerts; individual tools cite investigation times of a few minutes compared with around 25 minutes manually. This is relevant for the reporting obligation because faster, more reliable detection starts the 24-hour clock earlier and more cleanly.
Sensible support functions along the cascade:
- Detection: Alert enrichment, correlation across multiple sources, deduplication and prioritisation — so that a significant incident becomes visible as such in a timely manner in the first place.
- Documentation: Automatic, audit-proof logging of timestamps, affected systems, steps taken and indicators of compromise as a basis for the 72-hour notification and the final report.
- Deadline tracking: An incident workflow that counts the 24h, 72h and one-month deadlines from the moment of awareness, triggers escalations and keeps the status (early warning sent / notification open / report due) visible.
The limit nonetheless remains clear: as of May 2026, no production-ready SOC operates autonomously without human control at critical decision points. Two risks are particularly relevant for the reporting obligation. First, hallucinated incident attribution: large language models generate plausible-sounding but incorrect attributions to threat groups or geographies — and an incorrect statement to an authority is material. Second, auditability: NIS2 requires evidence of decision-making; AI-generated conclusions must remain traceable and verifiable. The assessment of significance, the content sign-off and the external communication to the authority therefore remain humanly accountable. The agent accelerates and documents — it does not decide and does not report externally on its own.
A practical note from the defender reality: logs, phishing emails and reconnaissance traffic can deliberately contain prompt-injection content that manipulates a defender LLM. Anyone integrating AI into the reporting process should know and have tested the prompt-injection defences of the tool deployed.
Practical preparation in five points
- Define awareness: When is an incident considered "known"? This moment starts all deadlines and must be unambiguously documented.
- Ensure 24/7 detection: In-house SOC, MDR provider or AI-supported triage — the 24-hour deadline cannot be met without continuous detection.
- Clarify the reporting channel in advance: Registration with the competent authority, access credentials for the reporting portal, designated responsible persons.
- Incident workflow with deadline tracking: A process that maps the three stages and triggers escalations automatically.
- Test the reporting process: Tabletop exercises that realistically run through the 24-hour early warning — including a night and weekend scenario.
For agencies and B2B decision-makers
For marketing agencies and B2B service providers, the NIS2 reporting obligation is relevant in two respects. First, as a supply chain matter: anyone working for an essential or important entity often effectively falls within their security and reporting expectations via contractual requirements — clean detection and documentation processes become a selection criterion in tenders. Second, as a content and consulting field: the deadline cascade requires explanation, is highly search-relevant and is a natural anchor for well-founded, citable content. Blck Alpaca designs AI-supported knowledge bases and process building blocks for this purpose that connect detection, documentation and deadline tracking — as a robust foundation, not as a substitute for human responsibility in the reporting process.
Note: this article serves as professional guidance and does not constitute legal advice. Specific thresholds, classifications and procedures under NIS2, the NIS2UmsuCG, the NISG 2026, the CRA or DORA must be clarified with qualified advisers in the respective jurisdiction.
FAQ
Which three deadlines apply under the NIS2 reporting obligations?
When does the 24-hour deadline start running?
Who is the report submitted to?
What must the 24-hour early warning contain?
Can an AI agent take over the NIS2 notification?
Does the same cascade also apply to the CRA and DORA?
Want to go deeper?
Get new analyses straight to your inbox – or see how we put this knowledge to work for companies.