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, CIR §3.2 names the twelve event types and the operational rules, and Germany puts the same rule into §30(2)(2) BSIG.
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 §3.2 fills in the detail. It names twelve event types you must log, sets the rules for alerts and qualified response, fixes a defined retention period, and asks for time-synchronised systems plus redundant monitoring. That is the floor for the sectors named in the CIR Annex.
Germany puts the same rule into §30(2)(2) BSIG. The practical baseline is IT-Grundschutz OPS.1.1.5 'Protokollierung' and DER.1 'Detektion'. 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 instruments to monitor and log activities on their network and information systems so that events that could be considered as security incidents can be detected and acted upon to contain their impact.
Because this is a regulation (not a directive), it is directly binding EU law. §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. The practical 'how' comes through IT-Grundschutz: OPS.1.1.5 'Protokollierung' for the logging design, and DER.1 'Detektion' for the alerting and response side.
Log the twelve event types
Build the list against your asset inventory. 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 §3.2.3(k) explicitly lists 'activation, deactivation or pause' of logs as an event you must log.
Reviewing logs is a duty, not a nice-to-have
§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. An auditor will ask who reviewed which alerts, when, and what they did about them.
BSI / IT-Grundschutz OPS.1.1.5 + DER.1
The BSI points at IT-Grundschutz as the practical route. OPS.1.1.5 'Protokollierung' is where the logging design lives (what to log, retention, protection). DER.1 'Detektion' covers the alerting and response side (review cadence, SIEM rules, qualified handling). The two together map onto CIR §3.2.
ENISA Technical Implementation Guidance
ENISA's TIG gives concrete evidence examples for §3.2: logging-policy templates, sample alert thresholds, retention defaults, and a mapping onto ISO/IEC 27001:2022 Annex A (A.8.15 Logging, A.8.16 Monitoring activities). If you already run ISO 27001, you reuse most of the controls.
National transposition laws
Every member state has its own transposition (Netherlands: Cyberbeveiligingswet, Austria: NISG, Belgium: NIS2-Wet). The §3.2 duty is the same because the CIR is directly applicable. What differs: which national authority you talk to, and how reporting channels and audit cadences are run locally.
We keep all logs forever, so we are covered.
§3.2.5 wants a defined retention period, not an infinite one. 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. §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.
§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. Not logging them is the gap an auditor finds first.
What we see in practice: most Mittelstand companies have firewall logs and Active Directory logs. They rarely have the twelve §3.2.3 event types covered systematically. Privileged access, config-file changes, and physical access are the three usual gaps.
The cheapest fix: build the §3.2.3 list against your asset inventory (RSK 2.2), pipe everything to one place (a central log store or a small SIEM), set thresholds on the high-value events, and review weekly. You do not need a managed SOC on day one. You need someone who looks at the alerts and knows what to do.
The INC module covers the §3.2 logging strategy: which event types you log, against which assets, with which retention window. You write it once, sign it off, and it becomes your audit-ready logging policy.
The EFF module covers the §3.2.4 review side: alarm thresholds, review cadence, qualified-response evidence. Sign-offs and audit trail show an auditor that someone looked at the alerts and acted on them. No spreadsheet pile. No second tool.
- 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 (as of May 2026)