NIS 2 logging and monitoring under Article 21(2)(b)
Logging is the visibility layer of incident handling. Article 21(2)(b) is where the duty lives and Germany carries it in §30(2)(2) BSIG. For the digital providers it covers, CIR point 3.2 names twelve event types and the operational rules.
The short version
Logging and monitoring are not a separate duty under NIS 2. They sit inside the incident-handling measure of Article 21(2)(b). The logic is simple: if you cannot see what is happening on your network, you cannot detect a security incident, and you cannot contain it.
CIR (EU) 2024/2690 point 3.2 fills in the detail for the digital providers listed in Art. 1 CIR (DNS, TLD, cloud, data centres, CDNs, MSPs, MSSPs, online marketplaces, search engines, social networks, trust services). Where appropriate, logs cover twelve kinds of events; the entity sets alarm thresholds and its own retention period, keeps time sources synchronised and runs monitoring redundantly. For other entities this detail is not a legal duty; in Germany only operators of critical facilities must run attack detection systems (§ 31 Abs. 2 BSIG).
Germany carries the measure in §30(2)(2) BSIG. IT-Grundschutz offers OPS.1.1.5 'Protokollierung' and DER.1 'Detektion' as building blocks; they are recommendations, not a legal baseline. This page walks the directive, the EU follow-up regulation, and the German transposition in that order.
Article 21(2)(b) NIS 2 Directive (2022/2555)
Incident handling.
This is point (b) on the list of ten cybersecurity measures every essential and important entity has to put in place. CIR §3 then operationalises it. Logging and monitoring sit inside §3.2.
CIR (EU) 2024/2690, Annex §3.2.1
The relevant entities shall lay down procedures and use tools to monitor and log activities on their network and information systems to detect events that could be considered as incidents and respond accordingly to mitigate the impact.
Because this is a regulation (not a directive), it is directly binding EU law for the entity types listed in its Art. 1 (DNS, TLD, cloud, data centres, CDNs, MSPs, MSSPs, online marketplaces, search engines, social networks, trust services). Point 3.2 then breaks down into seven subpoints covering the event types to log, alerting, retention, time sync and redundancy. No national transposition needed.
§30(2)(2) BSIG (Germany)
Incident handling.
Germany copies the EU text word for word. IT-Grundschutz offers OPS.1.1.5 'Protokollierung' and DER.1 'Detektion von sicherheitsrelevanten Ereignissen' as building blocks; they are recommendations, not a legal baseline.
Log the twelve event types
Build the list of assets to log from your risk assessment. Where appropriate, capture: inbound and outbound network traffic, user and privilege changes, system and application access, authentication events, all privileged and admin activity, access to critical configuration or backup files, security-tool logs (AV, IDS, firewall), system resource use, physical access, network-equipment use, activation or pause of logs themselves, and ambient events.
Review, alarm, qualified response
Collecting logs is not enough. Check them on a regular cadence for unusual or unwanted trends. Where appropriate set thresholds. When a threshold is exceeded, fire an automated alarm. And make sure someone qualified actually responds in time. Storage without review is not logging under §3.2.
Protect, retain, time-sync, redundant
Logs themselves are evidence. Keep them for a defined retention period, protect them from unauthorised access and changes, time-synchronise all systems so events can be correlated, and run the monitoring system redundantly. The monitoring of the monitoring system is itself independent of the systems it monitors.
Logs are an asset, not a by-product
§3.2.5 treats logs like critical data. Defined retention period, protection from tampering, protection from unauthorised access. If an attacker can delete the logs that show what they did, the logging duty is not met. That is also why point 3.2.3(k) lists the 'activation, stopping and pausing of the various logs' as something to log.
Reviewing logs is the point, not a nice-to-have
For the digital providers the CIR covers, point 3.2.4 wants regular checks for unusual trends, thresholds where appropriate, automated alarms on threshold breach, and a timely qualified response. A SIEM that no one looks at does not meet this. Keep a record of who reviewed which alerts, when, and what they did about them.
BSI / IT-Grundschutz OPS.1.1.5 + DER.1
IT-Grundschutz offers OPS.1.1.5 'Protokollierung' (what to log, retention, protection) and DER.1 'Detektion von sicherheitsrelevanten Ereignissen' (alerting and response) as building blocks; they are recommendations, not a legal baseline.
ENISA Technical Implementation Guidance
ENISA's TIG gives guidance and evidence examples for point 3.2, including example alarm thresholds, and says the retention period is set from business needs, the risk assessment and legal requirements. Its mapping table links 3.2 to ISO/IEC 27001:2022 A.5.28, A.8.15, A.8.16 and A.8.17; ENISA states the mapping is not a measure of equivalence.
National transposition laws
Every member state has its own transposition (Netherlands: Cyberbeveiligingswet; Austria: NISG 2026; Belgium: its NIS2 law). Point 3.2 CIR applies directly in every member state, but only to the digital providers listed in Art. 1 CIR. What differs: which national authority you talk to, and how reporting and supervision are run locally.
We keep all logs forever, so we are covered.
For the digital providers the CIR covers, point 3.2.5 wants a predefined retention period, not an infinite one. For everyone, keeping everything forever is a data-protection problem (Art. 5(1)(e) GDPR storage limitation) and a cost problem. Decide a retention window per log type, write it down, justify it against your risk picture, and stick to it.
The SIEM has it, so we are fine.
Close, but not quite. For the digital providers the CIR covers, point 3.2.4 does not just want storage. It wants regular review, thresholds where appropriate, automated alarms on breach, and a qualified person who actually responds. A SIEM that runs without rules, or with rules no one tunes, fails §3.2.4.
We log user activity but not admin activity.
For the digital providers the CIR covers, point 3.2.3(e) is explicit: all privileged access to systems and applications plus admin-account activities. Admins are the highest-impact users on your network, so their activity belongs in the logs.
The cheapest start: build the list of assets to log from your risk assessment, send the logs to one place (a central log store or a small SIEM), set thresholds on the events that matter most, and review them regularly. You do not need a managed SOC on day one. You need someone who looks at the alerts and knows what to do.
- Directive (EU) 2022/2555 (NIS 2), Article 21(2)(b): eur-lex.europa.eu/eli/dir/2022/2555/oj
- Commission Implementing Regulation (EU) 2024/2690 (CIR), Annex §3.2: eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSI Act (BSIG), §30(2)(2) as amended by the NIS2 Implementation and Cybersecurity Strengthening Act
- IT-Grundschutz Kompendium, OPS.1.1.5 'Protokollierung' and DER.1 'Detektion': bsi.bund.de/grundschutz
- ENISA Technical Implementation Guidance for CIR (EU) 2024/2690 (version 1.0, June 2025)
Been asked to handle NIS2?
In the end you have everything in one document: what is done, what is still open, and your management's approval with name and date. The app writes the texts.
