The Reporting Duty Is a Detection Problem
Read the NIS2 reporting rules and they sound like a documentation exercise: three notifications, a few defined fields each, sent to a government portal. That framing is what trips companies up. The obligation under NIS2 is not "write a report." It is "notice a significant security incident and file an early warning within 24 hours of becoming aware of it." The word that does the damage is aware. The 24-hour clock does not start when you finish investigating; it starts the moment the incident is knowable to you. If your logging and monitoring cannot surface a serious compromise for three days, you are already three days into a 24-hour deadline before anyone types a word.
So the honest question is not "can we fill in the form in time?" It is "can we detect a significant incident in time?" For most Mittelstand firms that were pulled into scope by NIS2 — manufacturers, energy suppliers, waste operators, food producers, digital providers who never thought of themselves as regulated infrastructure — the answer today is no. They have firewalls and antivirus and backups. They do not have detection: no central log collection, no alerting tuned to what "significant" looks like for them, and no one whose job is to look. The reporting duty simply makes that gap legally visible.
Are You In Scope? Nobody Sends a Letter
NIS2 — formally Directive (EU) 2022/2555 — widened the old NIS regime from a short list of named operators to whole sectors, sorted by size. Crucially, there is no register you get added to and no notification that you are covered. The directive works on self-identification: you are responsible for determining whether you fall in scope, registering with the competent authority, and complying — whether or not anyone tells you to. "We were never contacted" is not a defence.
Essential vs important entities
Scope turns on two things: your sector and your size. The directive splits covered organisations into essential and important entities, which differ mainly in supervision (essential entities face proactive oversight; important entities are supervised reactively, after something goes wrong) — but the reporting duties are effectively the same. As a rough guide: large enterprises (around 250+ employees, or over €50m turnover and €43m balance sheet) in the high-criticality sectors are essential; medium enterprises (roughly 50+ employees, or over €10m in turnover and balance sheet) land as important, as do large enterprises in the "other critical" sectors. Some entity types — DNS providers, TLD registries, qualified trust service providers, certain telecoms, and operators designated as critical — are in scope regardless of size.
Do not eyeball this. The sector annexes and the size arithmetic have edge cases — group structures, partial activities, headcount versus turnover tests — that decide the classification, and getting it wrong cuts both ways: unnecessary cost if you over-scope, unbudgeted liability if you under-scope. This article is written by an engineer, not a lawyer; the classification itself is a legal determination, and it is exactly where a qualified adviser and the competent authority's own guidance earn their fee.
The self-identification duty
Because scope is self-assessed, the first deliverable is not technical at all: a defensible, written scoping decision. Which entity, which sectors, which size class, and the reasoning — dated and kept. If a supervisor ever asks why you did or did not register, that document is your answer. It is cheap to produce now and expensive to reconstruct after an incident.
The Article 23 Reporting Cascade
Article 23 of the directive lays out a staged cascade, not a single report. Each stage has its own deadline and its own required content, and the later stages update the earlier ones as your understanding improves.
What each stage has to carry, in plain terms:
- Early warning — within 24 hours of awareness. A short first signal, not an analysis. It flags whether the incident is suspected to be caused by unlawful or malicious action, and whether it could have cross-border impact. That is roughly all it needs — which is precisely why the bottleneck is noticing, not writing.
- Incident notification — within 72 hours. Updates the early warning and adds an initial assessment: severity and impact, and, where available, indicators of compromise. This is where you commit to a first real picture of what happened.
- Final report — within one month. A detailed description of the incident and its severity and impact, the type of threat or root cause that likely triggered it, the mitigation measures applied and ongoing, and cross-border effects where relevant. If the incident is still ongoing at the one-month mark, you report progress then and file the final report within a month of handling it.
A "significant" incident is the trigger, and the directive defines it: one that has caused or is capable of causing severe operational disruption or financial loss to you, or considerable material or non-material damage to others. The competent authority may also request an intermediate status update at any point. If the GDPR's 72-hour breach clock feels familiar, this is the same reflex applied to operational security — and worth reading alongside how the 72-hour rule plays out in practice, because a single event can trigger both.
Germany: The Law Is Now in Force
For a long time the honest German answer was "the directive exists but the national law does not yet." That changed. The EU transposition deadline was 17 October 2024, which Germany missed by more than a year — but the NIS-2-Umsetzungsgesetz (NIS2UmsuCG) was passed by the Bundestag on 13 November 2025 and entered into force on 6 December 2025. So the duties are now live German law, implemented through the BSI-Gesetz, not a future prospect you can wait out.
The competent authority is the BSI (Bundesamt für Sicherheit in der Informationstechnik). It runs the registration and the reporting portal, and the transposition expands the population of covered organisations dramatically — from a few thousand KRITIS operators to a figure the legislature put at roughly 29,000–30,000 entities. If you are a mid-sized manufacturer or supplier who has never dealt with the BSI, that is the shift: you are now expected to register yourself and to be able to report. Because the exact registration mechanics and deadlines can move, confirm the current state against the BSI's own published guidance rather than a blog — including this one.
What "Able to Report in 24 Hours" Actually Requires
Strip away the legal framing and the target is concrete: on any given day, if a significant incident happens, you can notice it and file within 24 hours. That capability has four parts, and only one of them is a document.
Detection is the long pole
The hard, expensive part is surfacing the incident. That means logs actually collected in one place from the systems that matter, retained long enough to be useful, and — the step most firms skip — alerting tuned so that a genuinely significant event rises above the daily noise. A log nobody queries is not detection; it is storage. This is detection engineering, and it overlaps heavily with securing the systems in the first place, which is why the same disciplines from securing LLM and software applications apply here: know your assets, watch the boundaries, and assume you will have to reconstruct what happened.
Detection is also where the work compounds with good logging design. If your systems — AI ones included — emit structured, queryable audit logs by default, "reconstruct what happened" becomes an afternoon instead of an archaeology project. It is the same argument I made for the EU AI Act Article 12 log schema: decide what a usable event record looks like before the incident, not during it. Writing detection rules is a discipline of its own — our own multi-agent KQL generator for Microsoft Sentinel exists precisely because turning "we want to catch X" into a validated detection query is slow, expert work that pays back every time an alert fires correctly.
The other three parts are lighter, and you should not let their ease tempt you into treating them as the whole job:
- An incident-response runbook. A short, rehearsed procedure: who decides an event is a "significant incident," how the clock is started and recorded, who files, and how the 72-hour and one-month follow-ups are tracked. Decided on a calm afternoon, not at 2 a.m.
- A named responsible person. One accountable owner for detection and reporting, with a deputy. "Everyone in IT" means no one, and the 24-hour clock does not pause for holidays or notice periods.
- Pre-drafted notification templates. The early-warning and notification fields filled out to a skeleton in advance, so that under pressure you are completing a form, not composing one. This is the part that is genuinely just paperwork — do it once, in advance.
What I would not do is buy a large SIEM platform and a managed detection contract on day one because a compliance deadline appeared. For a mid-sized firm that is often a way to spend heavily on tooling while still not detecting the incidents that matter, because the alerts are untuned and no one owns them. Start from the incident types that would actually be "significant" for your operation, instrument for those, and grow. Right-sizing that — rather than maximising it — is the point.
Where Tippel Fits
NIS2 is not primarily a legal problem for you to solve with a policy binder; it is a detection-and-response capability you either have or do not. Tippel builds that capability as engineering: working out what a "significant incident" looks like for your specific systems, getting the right logs into one place, writing detection that surfaces real events without drowning you in noise, and leaving you with a runbook and templates a non-specialist can actually run. On-premise where the data cannot leave the building.
If you have just realised you are in scope and are staring at a 24-hour clock you currently could not meet, a scoped AI Readiness Check is a sensible way to find the real gap cheaply — or you can just get in touch and describe your setup. Bring the legal classification to a lawyer; bring the detection problem to an engineer.