SaaSFort A SaaS founder discovers ransomware in a production VM at 9:47pm on a Sunday. Detection happened by accident — an on-call engineer noticed unusually slow database queries during a routine deploy. The legal clock for NIS2 Article 23 starts at 9:47pm. The early warning to BSI is due by 9:47pm Monday.
Most teams have never filed one. They will spend the first three hours of the incident not on containment, but on figuring out what BSI expects them to write. That is the gap this article — and our free incident-readiness bundle — closes.
The Article 23 Clock Starts at Awareness, Not Detection
Article 23(4) of the NIS2 Directive (EU 2022/2555) gives essential and important entities a 24-hour window for an early warning to their national CSIRT or competent authority — in Germany, that is the BSI via the Meldeportal. The clock does not start when the attacker first gains access. It starts when your organization becomes aware that a significant incident is in progress.
This distinction is the single most-misunderstood aspect of Article 23. We have seen teams argue with auditors about when “awareness” was established. The argument almost always loses. Document the moment of awareness in writing — with timestamps, who escalated, and what evidence triggered escalation — or expect a regulator to define it for you, less generously, after the fact.
The full timeline is three stages:
| Stage | Deadline | What you submit |
|---|---|---|
| Early warning | 24 hours | Acknowledgement of awareness, preliminary nature, suspected attacker (if known) |
| Incident notification | 72 hours | Initial impact assessment, indicators of compromise, cross-border effect |
| Final report | 1 month | Root cause, applied mitigations, preventive measures going forward |
Each stage is mandatory. Skipping the early warning because “we didn’t have all the facts yet” is the exact failure mode regulators penalize. The 24-hour stage is for acknowledgement — not for a complete root cause.
The Eight Fields BSI Expects in the 24-Hour Notification
The BSI Meldeportal form for §32 BSIG notifications maps to eight required fields. The free .docx template in the incident-readiness bundle mirrors this structure exactly so you can copy/paste during a live incident without redesigning the form on the fly. For the full 16-field cross-reference (DE Meldeformular ↔ English) and the honest split between scan-derivable evidence and template-only evidence, see our Article 23 field map.
1. Reporter and entity identification. Legal name, BSI registration number (if registered — and if you missed the registration deadline, you have a separate problem), point-of-contact name and email. The reporter does not need to be the CEO, but must have the authority to file on the entity’s behalf.
2. Incident detection time. When did your organization become aware? Use UTC and include the local timezone. Be precise. “Around 10pm Sunday” reads as evasive; “21:47:03 UTC, 2026-05-03 (Europe/Berlin)” reads as documented.
3. Suspected nature of the incident. Pick one or more from the BSI taxonomy: malware, unauthorized access, data exfiltration, denial of service, supply chain compromise, social engineering, other. You are not committing to a final classification — this is a preliminary judgment.
4. Affected services and systems. Customer-facing or internal? Production or staging? Geographically constrained or EU-wide? If you serve customers in multiple EU member states, flag cross-border effect — Article 23 requires CSIRTs to coordinate cross-border notifications.
5. Suspected attacker (if known). Threat actor name, TTPs that match a known group, attribution confidence. Most teams cannot answer this in 24 hours. “Unknown at this time” is an acceptable answer. Inventing one is not.
6. Initial impact assessment. Number of users affected, data categories potentially involved, services degraded or unavailable. Be conservative — overestimating is forgivable; underestimating and being corrected later is not.
7. Containment and response status. What you have done in the past 24 hours. “Production environment isolated, customer access suspended pending forensic review” reads professional. “We are working on it” reads unprepared.
8. Anticipated next update. When the 72-hour notification will follow, and any interim communications you plan with affected parties. The BSI expects continuity, not silence.
The Pre-Incident Work That Makes the Form Fillable
The 24-hour deadline is achievable if and only if these decisions have been made before an incident occurs:
- Who is authorized to file? (Pre-designate two named individuals; one will be on a flight or asleep when the time comes.)
- What is the entity’s BSI registration number? (Pinned to your IR runbook, not buried in an email thread.)
- What does “significant incident” mean for your organization, in writing? (Article 23(3) gives the legal threshold. Your runbook should give the operational threshold — concrete examples, not lawyer-speak.)
- Who decides? (Most teams default to the CEO. The CEO is rarely the right person at 3am. Pre-authorize the CISO or an on-call security lead.)
A tabletop exercise forces these decisions onto paper before the pressure of a real incident corrupts the process. Our bundle includes three scenarios — ransomware, data breach, sustained DDoS — each scripted as a 90-minute exercise with role cards (CTO, CISO, comms lead, legal, support) and timed injects. The output of every session is a populated 24-hour notification draft. You finish the exercise with an artifact, not just a debrief.
Tip from compliance teams who have done this: Run the tabletop on a Friday afternoon. The cognitive fatigue of a real incident is closer to the cognitive fatigue of late-week work than to the cognitive fatigue of a fresh Monday. The realism translates.
What Article 23 Will Not Forgive
Three failure modes show up consistently in NIS2 enforcement guidance and early case data from member states:
Late filing. Missing the 24-hour deadline triggers the supervisory authority’s discretion. For essential entities, fines reach €10M or 2% of global turnover, whichever is higher. The BSI has stated publicly that procedural failures — including late or incomplete notifications — are a primary enforcement target during the 2026–2027 ramp-up.
Inconsistent updates. If your 24h, 72h, and 1-month notifications disagree about basic facts (incident time, scope, affected systems), regulators read inconsistency as either negligence or concealment. Use one source of truth — the same template, version-controlled — across all three filings.
Notification without internal escalation evidence. Article 21(2)(b) requires documented incident-handling procedures. If you file an Article 23 notification without an audit trail showing who decided to escalate, when, and on what evidence, you have created a documented gap in your Article 21 controls. The Article 23 filing then becomes the evidence used against your Article 21 compliance.
The awareness-clock worksheet in the incident-readiness bundle is built specifically to close this third gap. It documents detection, triage, and the decision to escalate — line by line, with timestamps and named decision-makers.
How This Connects to Your Article 21 Posture
Article 23 mandates the notification process. Article 21 mandates the underlying controls — incident handling, vulnerability management, MFA, encryption, supply chain — that determine whether you have something to report and how fast you can detect it. The two are operationally inseparable.
Most teams in scope start with the Article 21 self-audit template to map their current control posture, then build the Article 23 notification capability on top. If you have not yet run the Article 21 audit, do that first — the ten controls listed in Article 21(2) are the inputs to almost every field in the 24-hour notification.
For SaaS vendors specifically, the setup guide for NIS2 incident reporting walks through tooling, roles, and runbook integration. The bundle is the artifact pack that operationalizes that guide. For broader supply-chain context, see the NIS2 SaaS vendor compliance checklist and the October 2026 deadline action plan.
What’s in the Free Bundle
The NIS2 Incident-Readiness Bundle includes:
- 24h, 72h, and 1-month notification templates in both German and English (.docx)
- Tabletop exercise with three scripted scenarios (ransomware, data breach, sustained DDoS), role cards, and timed injects
- Awareness-clock worksheet documenting detection, triage, and escalation timestamps
- Internal-comms log + decision sheet to capture who approved the notification and when
- CSIRT-format field map cross-referencing BSI, ENISA, and CSIRT.NL field requirements
It is free, email-gated, licensed for unlimited internal use, and built to be filed under your IR runbook within an afternoon.
FAQ
When does the NIS2 Article 23 24-hour clock actually start?
The clock starts the moment your organization becomes aware of a significant incident — not when the incident began, and not when remediation completes. The bundle’s awareness-clock worksheet documents detection time, triage decision, and the moment legal notification liability begins.
What format does BSI expect for the early-warning notification?
BSI accepts notifications via the BSI Meldeportal (online form) or structured email. The bundle’s .docx template mirrors the Meldeportal field layout so you can copy/paste during a live incident.
Do I need a separate template for German vs. English notification?
Yes if you operate in DE. BSI accepts German-language notifications, and most German CSIRT communications are German by default. The bundle includes both DE and EN versions of all three timeline templates.
What if my 24-hour assessment turns out to be wrong?
Article 23 explicitly allows preliminary assessments to be revised in the 72-hour and 1-month notifications. What it does not allow is silence between filings, or a 1-month report that contradicts the 24-hour filing without explanation.
Is the tabletop exercise prescriptive or open-ended?
Each scenario runs ~90 minutes with a moderator script, role cards, and timed injects. The output is a populated 24-hour notification draft — you finish the session with an artifact, not just a debrief.
The October 2026 NIS2 enforcement deadline is six months out. The first wave of supervisory action will target procedural failures — registration gaps, late notifications, missing documentation — because those are the failures auditors can establish without a deep technical investigation. The 24-hour notification process is the most procedural element of the entire directive.
Run a free SaaSFort scan — 66 checks, A-F grade, NIS2 compliance PDF in 60 seconds. Pair the scan baseline with this incident-notification rehearsal and your supervisory authority sees evidence of both posture and preparedness. Download our free SaaS Security Playbook 2026 for the complete framework. Companion: how to fill the NIS2 Article 21 self-audit.
Passez de la lecture à l'action
Scannez votre domaine gratuitement. Premiers résultats en moins de 10 secondes — sans inscription.