NIS2 monitoring requirements: what IT and platform teams need for logging, incident detection and reporting

NIS2 monitoring requirements are among the most practical parts of the EU's revised cybersecurity directive for IT and platform teams: if you cannot detect a significant incident, reconstruct what happened and assess its impact quickly, you cannot meet the reporting deadlines either. NIS2 does not prescribe a specific tool, but it does require risk-management measures for incident handling and business continuity, and it sets hard clocks for incident reporting that start the moment you become aware of an incident.

This guide explains who is affected, which measures of Article 21 of Directive (EU) 2022/2555 touch monitoring, logging and incident handling, how the reporting obligations of Article 23 work and what the German implementation in the BSI Act looks like as of October 2026. It ends with a checklist table that maps each requirement to concrete observability capabilities and to the evidence auditors typically ask for.

Who is affected by NIS2?

NIS2 distinguishes between essential entities and important entities. Both must implement the same risk-management measures and report significant incidents; they differ mainly in supervision and maximum fines.

Whether an organisation is in scope depends on two questions:

• Sector: Annex I of the directive lists sectors of high criticality, including energy, transport, banking, financial market infrastructures, health, drinking water, waste water, digital infrastructure (for example cloud computing providers, data centre service providers, DNS and content delivery networks), B2B ICT service management (managed service and managed security service providers), public administration and space. Annex II lists other critical sectors such as postal and courier services, waste management, chemicals, food, manufacturing of certain products (for example medical devices, electronics, machinery and vehicles), digital providers (online marketplaces, search engines, social networks) and research.
• Size: As a rule, NIS2 applies to medium-sized and large enterprises as defined in Commission Recommendation 2003/361/EC. In the German BSI Act (§ 28 BSIG) this becomes concrete: an entity in a listed sector is generally an important entity with at least 50 employees or an annual turnover and balance sheet total of more than EUR 10 million each, and an essential (in German law: "particularly important") entity in an Annex I sector with at least 250 employees or more than EUR 50 million turnover and more than EUR 43 million balance sheet total.

Some providers fall in scope regardless of size, for example qualified trust service providers, top-level domain registries, DNS service providers and providers of public electronic communications networks or services. Operators of critical facilities (KRITIS) are essential entities in Germany. Platform providers serving in-scope customers should expect contractual NIS2 requirements, because supply chain security is itself a required measure.

Article 21: the measures that touch monitoring and logging

Article 21(2) lists ten minimum measures, (a) to (j), which entities must implement based on an all-hazards approach. Four of them are directly relevant for observability teams:

• (b) incident handling: you need a defined process to detect, analyse, contain and respond to incidents. Without monitoring and logging there is no detection.
• (c) business continuity, such as backup management and disaster recovery, and crisis management: you need to know whether your services are available, how fast you recover and whether your recovery procedures actually work.
• (f) policies and procedures to assess the effectiveness of cybersecurity risk-management measures: detection time, response time and incident recurrence show whether measures work.
• (i) human resources security, access control policies and asset management: an up-to-date inventory of services and their dependencies, plus access logs for sensitive systems, supports both detection and investigation.

The measures must be "appropriate and proportionate" and take into account the state of the art. For certain digital infrastructure and digital service providers, including cloud computing providers, data centre service providers, managed service providers and managed security service providers, Commission Implementing Regulation (EU) 2024/2690 adds more detailed technical requirements. Its annex contains a dedicated section on monitoring and logging: entities must establish procedures and tools to monitor and log activities on their network and information systems, automate monitoring where feasible, and maintain, document, review and protect logs.

Article 23: the 24-hour, 72-hour and one-month clocks

NIS2 incident reporting applies to significant incidents, meaning incidents that have caused or are capable of causing severe operational disruption or financial loss, or that affect other persons through considerable material or non-material damage. Article 23(4) defines a staged process towards the national CSIRT or competent authority:

Stage	Deadline	Content	What your telemetry must deliver
Early warning	Without undue delay, within 24 hours of becoming aware	Whether the incident is suspected to be caused by unlawful or malicious acts, and whether it could have a cross-border impact	A reliable detection timestamp, affected services and regions, first indicators of cause
Incident notification	Without undue delay, within 72 hours of becoming aware	Update of the early warning, initial assessment of severity and impact, indicators of compromise where available	Impact metrics (error rates, affected users, duration), severity classification, relevant log and trace evidence
Intermediate report	On request of the CSIRT or authority	Relevant status updates	Current incident timeline and mitigation status
Final report	No later than one month after the incident notification	Detailed description incl. severity and impact, likely threat type or root cause, applied and ongoing mitigation, cross-border impact where applicable	Root-cause analysis with evidence, complete timeline, remediation actions

If the incident is still ongoing when the final report is due, the entity submits a progress report at that point and the final report within one month after it has handled the incident. The clock starts at awareness, not at the end of your investigation, and the content maps almost one to one onto good incident practice: a timeline, a severity classification, impact data and a written postmortem.

Management liability: why this reaches the board

Article 20 requires the management bodies of essential and important entities to approve the cybersecurity risk-management measures, oversee their implementation, and makes them liable for infringements. Members of management bodies must also follow training. In Germany, § 38 BSIG implements this: management must implement the measures and oversee their implementation, is liable to the entity for culpably caused damage under the corporate law rules applicable to its legal form, and must regularly attend training.

Article 34 sets the floor for maximum administrative fines: at least EUR 10 million or 2 % of total worldwide annual turnover (whichever is higher) for essential entities, and at least EUR 7 million or 1.4 % for important entities. For platform teams this means management will ask for evidence that monitoring, logging and reporting measures exist and work, so design that evidence into your observability setup from the start.

Germany: status of the NIS2 implementation (October 2026)

Germany transposed NIS2 late; the EU deadline under Article 41 was 17 October 2024. According to the BSI, the NIS2 Implementation and Cybersecurity Strengthening Act (NIS2UmsuCG) was passed by the Bundestag on 13 November 2025, approved by the Bundesrat on 21 November 2025, promulgated in the Federal Law Gazette on 5 December 2025 and entered into force on 6 December 2025. It is an omnibus law; its core is a completely revised BSI Act (BSIG). The key provisions for technical teams are:

• § 28 BSIG defines particularly important and important entities, including the size thresholds above.
• § 30 BSIG lists the risk-management measures, mirroring Article 21(2), and requires entities to document compliance.
• § 32 BSIG sets the reporting duties to a joint reporting office of the BSI and the BBK: early report within 24 hours, report within 72 hours, intermediate report on request and final report no later than one month after the 72-hour report.
• § 33 BSIG requires registration with the BSI no later than three months after an entity first falls in scope.

The BSI states that the law contains no general transition period, so the obligations apply from entry into force. Registration runs through the BSI portal, which requires an organisation account ("Mein Unternehmenskonto"). The BSI's "NIS-2 in Zahlen" page reported more than 20,000 registered entities as of 30 September 2026, against an earlier BSI estimate of around 29,500 entities in scope. Reports about an informal tolerance period for late registrations circulated in 2026; since the legal deadline itself was not changed, do not rely on it, and check the current information on the BSI website if you have not registered yet. Sector-specific rules may add details; verify them with the competent authority.

Checklist: mapping NIS2 requirements to observability

The following table is a starting point you can copy into your compliance tracker. The evidence column shows what auditors typically ask for, not a legal standard.

NIS2 requirement	What to implement	Evidence for audits
Incident handling (Art. 21(2)(b), § 30 BSIG)	Centralised logs, metrics and traces for all in-scope services; alerting on symptoms and security-relevant events; on-call rotation with escalation	Alert rules with owners, on-call schedule, sample incident records with detection and response timestamps
Detection capability	Anomaly detection on error rates, latency, authentication failures and unusual traffic; synthetic checks for critical user journeys	Detection coverage list per service, MTTD trend over time
Log integrity and retention	Structured logging with consistent fields (timestamp in UTC, service, trace ID, user or client ID where lawful); immutable or access-controlled storage; defined retention per log class	Logging standard, retention policy, access logs for the log store itself
Personal data in telemetry	PII masking or pseudonymisation before storage, so logs can be kept long enough without violating the GDPR	Masking rules, data processing documentation, data residency statement
24-hour early warning	Incident tool with a "regulatory significance" field, a pre-filled early warning template and a named person responsible for submission	Template, runbook, records of submitted reports
72-hour notification	Impact dashboards per incident (affected services, users, regions, duration); severity matrix aligned with the "significant incident" criteria	Severity matrix, exported impact data per incident
One-month final report	Root-cause analysis with linked evidence; blameless postmortem process with tracked action items	Postmortems, action item status, links to supporting telemetry
Business continuity (Art. 21(2)(c))	Availability SLOs, backup job monitoring, regular restore tests, high-availability design for critical services	SLO reports, restore test results, disaster recovery exercise records
Asset management (Art. 21(2)(i))	Service catalogue and dependency map derived from telemetry, with owners per service	Exported service inventory with owners and dependencies
Effectiveness assessment (Art. 21(2)(f))	Quarterly review of incident metrics: detection time, time to mitigate, recurring causes, alert noise	Review minutes, metric reports presented to management

Copyable template: internal early warning record

Keep a record like this in your incident tool and fill it in as soon as an incident might be significant:

NIS2 early warning - internal record
Incident ID:            INC-____
Awareness timestamp:    YYYY-MM-DD hh:mm UTC (who, how detected)
Affected services:      ____
Affected regions / EU member states: ____
Suspected unlawful or malicious cause: yes / no / unknown (basis: ____)
Possible cross-border impact: yes / no / unknown
Current impact (example metrics): error rate __ %, affected users ~__, duration __ min
Severity (internal):    SEV1 / SEV2 / SEV3
Significant incident per NIS2 criteria: yes / no / under review
Reporting owner:        ____   Deadline 24h: ____   Deadline 72h: ____
Evidence links:         dashboards, log queries, traces

Common gaps we see in practice

The typical problems are gaps between tools and process, not missing tools:

1. No reliable awareness timestamp. Alerts in a chat channel without acknowledgement cannot prove when the clock started.
2. Logs that cannot be correlated. Without shared trace IDs and consistent timestamps, building a timeline for the 72-hour report takes days instead of hours.
3. Retention driven by cost, not by need. If security logs expire after seven days, the final report's root-cause analysis may be impossible. Set retention per log class.
4. Severity without impact data. "SEV1" alone does not tell an authority how many users or services were affected.
5. Postmortems without follow-up. The final report asks for applied and ongoing mitigation; untracked action items are hard to report.

If you are still building the foundation, our introduction to what observability is explains how logs, metrics and traces work together for investigations like these.

How Obseria helps

Obseria does not make an organisation NIS2-compliant, and compliance always depends on your processes and your own assessment. What it provides is the technical basis for many of the measures above: OpenTelemetry-native collection of logs, metrics, traces and events, a pipeline that filters and masks personal data before storage, and incident workflows that keep timestamps, severity and evidence in one place. Details on hosting, data residency and our security practices are on the security and trust page.

• Detection and timelines: anomaly detection, SLO burn-rate alerts and synthetic monitoring feed incident management with automatic timelines.
• Retention and privacy: Obseria Pipeline masks PII and routes data by class; Obseria Lake stores logs, metrics, traces and events with configurable retention and EU data residency.
• Root cause with evidence: Obseria Intelligence proposes causal root causes with the supporting telemetry, which shortens the work for postmortems and final reports.

To see how your own incident timeline and evidence would look, start a free trial with your telemetry.