NIS 2 Logging und Protokollierung nach Artikel 21(2)(b)
Logging ist die Sichtbarkeitsebene der Vorfallsbewältigung. Artikel 21(2)(b) verankert die Pflicht, CIR §3.2 nennt die zwölf Ereignistypen und die Betriebsregeln, und Deutschland setzt dasselbe in §30(2)(2) BSIG um.
Die Kurzfassung
Logging und Monitoring sind unter NIS 2 keine eigenständige Pflicht. Sie sitzen innerhalb der Vorfallsbewältigung nach Artikel 21(2)(b). Die Logik ist schlicht: Wer nicht sieht, was im Netz passiert, erkennt keinen Sicherheitsvorfall und kann ihn auch nicht eindämmen.
CIR (EU) 2024/2690 §3.2 liefert die Details. Zwölf Ereignistypen sind zu protokollieren, dazu Regeln für Alarmierung und qualifizierte Reaktion, eine definierte Aufbewahrungsfrist, zeitsynchronisierte Systeme und ein redundantes Monitoring. Das ist der Mindeststandard für die im CIR-Anhang genannten Sektoren.
Deutschland setzt dasselbe in §30(2)(2) BSIG um. Die praktische Grundlage liefern IT-Grundschutz OPS.1.1.5 'Protokollierung' und DER.1 'Detektion'. Diese Seite geht die Richtlinie, die EU-Durchführungsverordnung und die deutsche Umsetzung in dieser Reihenfolge durch.
Artikel 21(2)(b) NIS 2 Richtlinie (2022/2555)
Bewältigung von Sicherheitsvorfällen.
Das ist Buchstabe (b) der zehn Cybersicherheitsmaßnahmen, die jede wesentliche und wichtige Einrichtung umsetzen muss. CIR §3 operationalisiert das. Logging und Monitoring sitzen in §3.2.
CIR (EU) 2024/2690, Anhang §3.2.1
Die betreffenden Einrichtungen legen Verfahren fest und nutzen Instrumente, um Aktivitäten in ihren Netz- und Informationssystemen zu überwachen und zu protokollieren, sodass Ereignisse, die als Sicherheitsvorfälle anzusehen sind, erkannt und so bearbeitet werden können, dass ihre Auswirkungen eingedämmt werden.
Weil das eine Verordnung ist (keine Richtlinie), gilt sie unmittelbar als EU-Recht. §3.2 gliedert sich dann in sieben Unterpunkte zu Ereignistypen, Alarmierung, Aufbewahrung, Zeitsynchronisation und Redundanz. Keine nationale Umsetzung nötig.
§30(2)(2) BSIG (Deutschland)
Bewältigung von Sicherheitsvorfällen.
Deutschland übernimmt den EU-Wortlaut. Das praktische 'Wie' liefert IT-Grundschutz: OPS.1.1.5 'Protokollierung' für die Logging-Architektur und DER.1 'Detektion' für Alarmierung und Reaktion.
Die zwölf Ereignistypen protokollieren
Die Liste entsteht aus dem Asset-Inventar. Soweit angemessen zu erfassen: ein- und ausgehender Netzverkehr, Anlage und Änderung von Benutzern und Privilegien, Zugriff auf Systeme und Anwendungen, Authentifizierungsereignisse, gesamter privilegierter und Admin-Zugriff, Zugriff auf kritische Konfigurations- oder Backup-Dateien, Logs von Sicherheitswerkzeugen (AV, IDS, Firewall), Ressourcen- und Performancenutzung, physischer Zugang, Nutzung von Netzwerkgeräten, Aktivierung oder Pause von Logs selbst, sowie Umgebungsereignisse.
Prüfung, Alarm, qualifizierte Reaktion
Logs zu sammeln reicht nicht. Sie sind regelmäßig auf ungewöhnliche oder unerwünschte Muster zu prüfen. Schwellenwerte sind dort zu setzen, wo angemessen. Bei Überschreitung erfolgt automatisch ein Alarm. Und es muss jemand qualifiziert und zeitnah reagieren. Speicherung ohne Auswertung erfüllt §3.2 nicht.
Schutz, Aufbewahrung, Zeitsync, Redundanz
Logs sind selbst Beweismittel. Sie werden für eine definierte Aufbewahrungsfrist gehalten, vor unbefugtem Zugriff und Änderungen geschützt, alle Systeme sind zeitsynchronisiert (damit Ereignisse korrelierbar sind), und das Monitoring läuft redundant. Die Überwachung der Überwachung ist von den überwachten Systemen unabhängig.
Logs sind ein Asset, kein Nebenprodukt
§3.2.5 behandelt Logs wie kritische Daten. Definierte Aufbewahrungsfrist, Manipulationsschutz, Zugriffsschutz. Wenn ein Angreifer die Logs löschen kann, die seine Aktivität zeigen, ist die Pflicht nicht erfüllt. Genau deshalb listet §3.2.3(k) ausdrücklich 'Aktivierung, Deaktivierung oder Pause' von Logs als eigenes Ereignis.
Auswertung ist Pflicht, kein Nice-to-have
§3.2.4 verlangt regelmäßige Prüfungen, Schwellenwerte wo angemessen, automatische Alarme bei Überschreitung und eine zeitnahe qualifizierte Reaktion. Ein SIEM, in das niemand schaut, erfüllt das nicht. Im Audit kommt die Frage: wer hat welche Alarme wann gesichtet und was wurde daraus.
BSI / IT-Grundschutz OPS.1.1.5 + DER.1
Das BSI verweist auf IT-Grundschutz als praktischen Weg. OPS.1.1.5 'Protokollierung' regelt das Logging-Design (was, wie lange, wie geschützt). DER.1 'Detektion' regelt Alarmierung und Reaktion (Prüfintervalle, SIEM-Regeln, qualifizierte Bearbeitung). Zusammen decken sie CIR §3.2 ab.
ENISA Technical Implementation Guidance
Die ENISA TIG zeigt konkrete Evidenzbeispiele für §3.2: Vorlagen für Logging-Policies, beispielhafte Alarmschwellen, Aufbewahrungsdefaults und ein Mapping auf ISO/IEC 27001:2022 Anhang A (A.8.15 Protokollierung, A.8.16 Überwachung). Wer bereits ISO 27001 betreibt, kann den Großteil der Kontrollen wiederverwenden.
Nationale Umsetzungsgesetze
Jeder Mitgliedstaat hat sein Umsetzungsgesetz (Niederlande: Cyberbeveiligingswet, Österreich: NISG, Belgien: NIS2-Wet). Die §3.2-Pflicht ist überall dieselbe, weil die CIR direkt gilt. Unterschiede: zuständige Behörde, Meldewege, Auditrhythmus.
Wir behalten alle Logs für immer, dann sind wir sicher.
§3.2.5 verlangt eine definierte Aufbewahrungsfrist, keine unendliche. Alles für immer zu behalten ist ein Datenschutzproblem (Art. 5(1)(e) DSGVO Speicherbegrenzung) und ein Kostenproblem. Pro Logtyp ein Aufbewahrungsfenster festlegen, dokumentieren, gegen die Risikolage begründen und daran halten.
Das SIEM hat alles, damit sind wir durch.
Fast. §3.2.4 will nicht nur Speicherung. Es will regelmäßige Auswertung, Schwellenwerte wo angemessen, automatische Alarme bei Überschreitung und eine qualifizierte Person, die tatsächlich reagiert. Ein SIEM ohne Regeln, oder mit Regeln, die niemand pflegt, erfüllt §3.2.4 nicht.
Wir protokollieren Nutzer, aber keine Admins.
§3.2.3(e) ist eindeutig: gesamter privilegierter Zugriff plus Admin-Aktivitäten. Admins sind die Nutzer mit der größten Wirkungstiefe im Netz. Sie nicht zu protokollieren ist die Lücke, die ein Prüfer als erstes findet.
Was wir sehen: die meisten Mittelständler haben Firewall-Logs und Active-Directory-Logs. Die zwölf §3.2.3-Ereignistypen sind selten systematisch abgedeckt. Privilegierter Zugriff, Änderungen an Konfigurationsdateien und physischer Zugang sind die drei üblichen Lücken.
Der günstigste Weg: die §3.2.3-Liste gegen das Asset-Inventar (RSK 2.2) aufbauen, alles in eine zentrale Ablage oder ein kleines SIEM pipen, Schwellenwerte für die hochwertigen Ereignisse setzen und wöchentlich auswerten. Ein managed SOC am ersten Tag braucht es nicht. Es braucht jemanden, der die Alarme sichtet und weiß, was zu tun ist.
Das INC-Modul deckt die §3.2-Logging-Strategie ab: welche Ereignistypen, gegen welche Assets, mit welcher Aufbewahrungsfrist. Einmal schreiben, freigeben, fertig ist die auditfähige Logging-Policy.
Das EFF-Modul deckt die §3.2.4-Auswertungsseite ab: Alarmschwellen, Prüfintervalle, Nachweise zur qualifizierten Reaktion. Freigaben und Audit-Trail zeigen einem Prüfer, dass die Alarme gesichtet und bearbeitet wurden. Kein Tabellenstapel. Kein zweites Tool.
- Richtlinie (EU) 2022/2555 (NIS 2), Artikel 21(2)(b) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Durchführungsverordnung (EU) 2024/2690 (CIR), Anhang §3.2 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSI-Gesetz (BSIG), §30(2)(2) i.d.F. des NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetzes
- IT-Grundschutz Kompendium, OPS.1.1.5 'Protokollierung' und DER.1 'Detektion' — bsi.bund.de/grundschutz
- ENISA Technical Implementation Guidance zur CIR (EU) 2024/2690 (Stand Mai 2026)