What NIS2 Is and Why 2026 Is the Decisive Year
NIS2 is the EU's second directive on network and information security (Directive (EU) 2022/2555). It replaces the first NIS Directive and substantially expands its requirements — both in the range of companies affected and in the duties for risk management, reporting and evidence. In Germany the transposition came later than originally planned: the NIS2 Implementation Act was published in the Federal Law Gazette on 5 December 2025 and entered into force one day later, on 6 December 2025 (Greenberg Traurig 2025). There is no general transitional period — the obligations generally apply immediately (Reed Smith 2025).
This makes 2026 the year in which the new obligations become practically effective. Unlike earlier rules, NIS2 affects not only classic operators of critical infrastructure but a broad mid-section of the economy. Anyone running a website or online platform as an essential part of their business should therefore check whether they fall within scope — and if so, whether internal processes can even map the short reporting deadlines.
There is no individual notification by the authority. Every entity must assess for itself whether it falls under NIS2, register where applicable and meet the obligations (Mayer Brown 2025). Failure to register is a separate offence under Section 65 BSIG — regardless of whether an incident has occurred.
The Expanded Scope Since December 2025
The biggest practical difference from the previous regime is the reach. Estimates suggest the number of regulated organisations in Germany rises from around 4,500 to roughly 29,000 (Reed Smith 2025). Entities are captured across a long list of sectors — including energy, transport, finance, health and, above all, digital infrastructure (OpenKRITIS 2025). For most sectors a size threshold applies: in scope is anyone with at least 50 employees or an annual turnover of more than 10 million euros (Freshfields 2025).
Within scope, the law distinguishes two tiers, to which different maximum fine ceilings are attached. Classification follows sector and size and determines the maximum sanction risk.
| Category | Typical threshold | Maximum fine |
|---|---|---|
| Essential entities | from 250 employees or over EUR 50m turnover | up to EUR 10m or 2% of global annual turnover |
| Important entities | from 50 employees or over EUR 10m turnover | up to EUR 7m or 1.4% of global annual turnover |
| Digital infrastructure (sub-areas) | regardless of size | depending on essential/important classification |
Especially relevant for the web sphere: several kinds of digital services fall under NIS2 regardless of their size. These include DNS service providers, top-level-domain registries, providers of public electronic communications networks and qualified trust service providers under eIDAS (K&L Gates 2026). Cloud computing services, data centre services, content delivery networks, online marketplaces, search engines and social network platforms are also captured by the digital services rules, provided their main establishment is in Germany (K&L Gates 2026). Anyone running a platform that others depend on should therefore not read the size threshold as an all-clear.
Behind the jump from around 4,500 to roughly 29,000 entities is a deliberately broad interpretation of the directive by the German legislator, capturing a wide spectrum of critical, essential and important entities (Reed Smith 2025). In practice this means: even mid-sized companies from areas such as mechanical engineering, research, food or waste management, which previously did not see themselves as part of a critical infrastructure, can now slide into scope (OpenKRITIS 2025). Classification as an important or essential entity follows not one's own self-perception but the statutory thresholds of headcount, turnover and balance sheet total in combination with the sector (Freshfields 2025). Anyone unsure whether their organisation is captured should document the assessment early and traceably, because even a well-founded negative answer should be evidenced in case of doubt.
Even if an entity sits just below the threshold, it can be pulled in via supply chains: NIS2 requires in-scope entities to also consider the security of their service providers and suppliers. Agencies, hosting partners and managed service providers therefore often receive contractual requirements passed down — related to the idea that also underpins script integrity and supply-chain monitoring.
The Staggered Reporting Deadlines in Detail
The heart of the NIS2 duties is the three-stage report of a significant security incident to the BSI. The stages build on one another and are deliberately designed so that speed comes before completeness at the start (Glocert 2025). Importantly: the deadlines run from the point at which the entity gains awareness of the incident — not from the incident itself. This is exactly why early, timestamped detection is so valuable.
- Early warning within 24 hours — without undue delay, no later than 24 hours after awareness. It indicates in particular whether the incident is suspected to stem from unlawful or malicious acts or could have a cross-border impact (OpenKRITIS 2025).
- Notification within 72 hours — no later than 72 hours after awareness. It updates the early warning and contains an initial assessment of the incident including severity and impact, plus indicators of compromise where available (Glocert 2025).
- Intermediate report on request — upon request of the BSI or a CSIRT, relevant status updates must be supplied (Glocert 2025).
- Final report after one month — no later than one month after the notification, with a detailed description of the incident, its severity and impact, and the measures taken (OpenKRITIS 2025).
Reporting is done through a single reporting centre at the BSI (Reed Smith 2025). An incident is significant in the sense of NIS2 if, among other things, it has caused or is capable of causing severe operational disruption or financial loss — or if it has affected or is capable of affecting other persons through considerable material or non-material damage (Glocert 2025). For a website operator, that could be a prolonged outage, a defacement attack, a data leak or a successful manipulation of embedded scripts.
The 24-hour deadline starts with awareness of the incident. Anyone who notices an outage or manipulation only hours later by chance has already used up a large part of the deadline before the actual handling begins. The earlier and more precisely the starting point is documented, the more realistic an on-time early warning becomes.
Registration Requirement With the BSI via the MUK Portal
Alongside the reporting obligations there is a separate registration requirement. In-scope entities had to register via the platform provided by the BSI by 6 March 2026 (K&L Gates 2026). The registration portal has been available since 6 January 2026 (Privacy World 2025). Registration is two-step: first an account via Mein Unternehmenskonto (MUK/ELSTER), then registration in the BSI portal (Enobyte 2026).
Anyone who missed the deadline should still complete the registration rather than sit it out. A significant share of affected companies had not registered by the cut-off date — and the BSI has signalled systematic enforcement for 2026 (K&L Gates 2026). Unregistered entities then risk sanctions not only for missing security measures, but also for the registration violation as an offence in its own right under Section 65 BSIG (K&L Gates 2026).
Create an organisation account via Mein Unternehmenskonto — it requires an ELSTER organisation certificate.
Register entity data and contact points in the BSI reporting portal, which has been live since January 2026.
Designate a reachable reporting contact so an early warning within 24 hours can be organised at all.
Document records on detection, response and remediation — they become relevant in the final report and during an audit.
Fines and Liability: What Failures Can Cost
Sanctions are tiered under Section 65 BSIG. For essential entities the ceiling is 10 million euros or 2% of global annual turnover — whichever is higher. For important entities it is up to 7 million euros or 1.4% of turnover (Greenberg Traurig 2025). On top of that comes personal responsibility at management level: the German transposition provides for fines of up to 500,000 euros for individual managers who fail to meet their governance duties (Greenberg Traurig 2025).
These figures make clear that under NIS2 cybersecurity becomes a board-level matter. Management must approve the risk management measures and oversee their implementation — mere delegation to IT is formally not enough. A documented, continuous monitoring of one's own services is therefore not only technically sensible but also demonstrable evidence that the management level is meeting its supervisory duties.
A common misconception is that sanctions only loom after a security incident. In fact, even missing registration or the absence of appropriate risk management measures is a separate offence (K&L Gates 2026). Prevention therefore does not start only in an emergency, but with demonstrable, ongoing diligence.
Why the Deadlines Are Hard to Meet Without Monitoring
The 24-hour deadline assumes the incident is noticed promptly in the first place. This is exactly where many organisations are practically weak: an outage, a defacement attack or an expired certificate is often discovered only through a customer's tip-off or by chance — potentially many hours after the actual event. By then the deadline is already running without anyone having started the clock. A manual, occasional visual check reflects neither the continuous coverage nor the temporal precision that NIS2 effectively requires.
Continuous, automated monitoring reverses this relationship. Instead of waiting for an external tip-off, ongoing monitoring detects the status change itself — and stamps it with a timestamp. This timestamp is the objective basis for when the 24- and 72-hour deadlines began to run, and at the same time provides material for the final report. Operators already know the principle of gapless target-versus-actual capture from the monitoring of security.txt and vulnerability disclosure; with NIS2 the same discipline serves on-time reporting.
Multi-region checks detect outages in minutes and document start and end with a timestamp — the basis for uptime monitoring.
Expiring or revoked certificates are flagged early, before they become an outage — see SSL monitoring.
Changes to DNS records and to the DNSSEC status are monitored, a frequent lever for attacks on availability.
Visual and content changes are checked against a baseline — unauthorised manipulation becomes visible this way.
Security-relevant HTTP headers and common vulnerability patterns are checked regularly to evidence the posture status.
Every relevant status change triggers an alert via email, Slack, Discord or Telegram — with escalation if no one responds.
The value lies in shortening the time between event and awareness. If an outage is detected and alerted within a few minutes, the 24-hour deadline starts with the maximum possible lead time for the actual response. By contrast, anyone who only notices hours later that something is wrong has to handle the remaining deadline under pressure. The article on the cost of website outages shows how high the economic leverage of fast detection is.
From Detection to On-Time Reporting
Monitoring does not replace legal assessment — whether an incident is significant in the sense of NIS2 and must be reported is decided by those responsible on a case-by-case basis, ideally with legal support. What monitoring delivers is reliable, temporally precise detection and gapless documentation on which this assessment builds. Together they turn an abstract deadline into a manageable process.
A practical sequence can look like this: monitoring detects a status change and alerts the contact point. Those responsible assess whether a significant incident exists. If so, the 24-hour clock runs from the documented detection time, and the early warning is prepared. The gapless log from monitoring — when the outage began, when it was detected, when it was resolved — feeds into the 72-hour notification and later into the final report. This chaining is the actual compliance benefit, far beyond mere availability. The escalation logic behind it is described in the article on incident management with escalation tiers.
The 24-hour deadline runs from awareness, not from the incident. Anyone who detects early and with a timestamp gains exactly the hours that decide whether the early warning is on time.
— XICTRAQ Compliance Monitoring
NIS2 is therefore not a purely legal topic, but one that presupposes technical visibility. Anyone who does not observe their services continuously can neither report reliably nor prove that they responded appropriately. Continuous monitoring is therefore the practical bridge between the legal obligation and its fulfilment. Anyone who also keeps an eye on the vulnerability reporting obligation of the Cyber Resilience Act taking effect in September 2026 can serve both frameworks on the same monitoring and evidence basis.
This article is based on data and analysis from: DLA Piper (NIS 2 Directive Transposed in Germany, 2026), K&L Gates (Registration Requirement Expires on 6 March 2026, 2026), OpenKRITIS (NIS2 Implementation in Germany / DE NIS2), Reed Smith (Germany Implements NIS2: Immediate Effect, Broad Scope, Near-Term Registration, 2025), Greenberg Traurig (NIS2 in Germany: The New BSI Act, 2025), Freshfields (Germany implements NIS2, 2025), Mayer Brown (Cyber Rules for Essential and Important Entities Take Effect in Germany, 2025), Glocert International (NIS2 Incident Reporting Playbook, Article 23), Privacy World (Registration portal opens 6 January 2026, 2025), Enobyte (Start of registration with the supervisory authority, 2026). Legal bases: Act on the Federal Office for Information Security (BSIG) as amended by the NIS2 Implementation Act, Directive (EU) 2022/2555 (NIS2). This article is general information and does not constitute legal advice.