NIS 2 Logging und Protokollierung nach Artikel 21(2)(b)
Logging ist die Sichtbarkeitsebene der Vorfallsbewältigung. Artikel 21(2)(b) verankert die Pflicht, Deutschland setzt sie in §30(2)(2) BSIG um. Für die erfassten digitalen Anbieter nennt CIR Nummer 3.2 zwölf Ereignistypen und die Betriebsregeln.
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 Nummer 3.2 liefert die Details für die in Art. 1 CIR genannten digitalen Anbieter (DNS, TLD, Cloud, Rechenzentren, CDN, MSP, MSSP, Online-Marktplätze, Suchmaschinen, soziale Netzwerke, Vertrauensdienste). Soweit angemessen umfassen die Logs zwölf Ereignistypen; die Einrichtung legt Alarmschwellen und eine eigene Aufbewahrungsfrist fest, synchronisiert die Zeitquellen und betreibt das Monitoring redundant. Für andere Einrichtungen sind diese Details keine gesetzliche Pflicht; in Deutschland müssen nur Betreiber kritischer Anlagen Systeme zur Angriffserkennung einsetzen (§ 31 Abs. 2 BSIG).
Deutschland setzt die Maßnahme in §30(2)(2) BSIG um. IT-Grundschutz bietet die Bausteine OPS.1.1.5 'Protokollierung' und DER.1 'Detektion'; sie sind Empfehlungen, keine gesetzliche Vorgabe. 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 verwenden Instrumente, um Aktivitäten in ihrem Netz- und Informationssystem zu überwachen und zu protokollieren, damit sie Ereignisse, die als Sicherheitsvorfälle betrachtet werden könnten, erkennen und zur Eindämmung der Auswirkungen entsprechend darauf reagieren können.
Weil das eine Verordnung ist (keine Richtlinie), gilt sie unmittelbar als EU-Recht für die in ihrem Art. 1 genannten Einrichtungsarten (DNS, TLD, Cloud, Rechenzentren, CDN, MSP, MSSP, Online-Marktplätze, Suchmaschinen, soziale Netzwerke, Vertrauensdienste). Nummer 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. IT-Grundschutz bietet die Bausteine OPS.1.1.5 'Protokollierung' und DER.1 'Detektion von sicherheitsrelevanten Ereignissen'; sie sind Empfehlungen, keine gesetzliche Vorgabe.
Die zwölf Ereignistypen protokollieren
Die Liste der zu protokollierenden Anlagen ergibt sich aus der Risikoanalyse. 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 nennt Nummer 3.2.3 Buchst. k die 'Aktivierung, Beendigung und Pausieren der verschiedenen Protokolle' als eigenes Ereignis.
Auswertung ist der Kern, kein Nice-to-have
Für die erfassten digitalen Anbieter verlangt Nummer 3.2.4 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. Halten Sie fest, wer welche Alarme wann gesichtet hat und was daraus wurde.
BSI / IT-Grundschutz OPS.1.1.5 + DER.1
IT-Grundschutz bietet die Bausteine OPS.1.1.5 'Protokollierung' (was, wie lange, wie geschützt) und DER.1 'Detektion von sicherheitsrelevanten Ereignissen' (Alarmierung und Reaktion); sie sind Empfehlungen, keine gesetzliche Vorgabe.
ENISA Technical Implementation Guidance
Die ENISA TIG gibt für Nummer 3.2 Hinweise und Nachweisbeispiele, darunter Beispiele für Alarmschwellen, und sagt, dass die Aufbewahrungsfrist nach Geschäftsbedarf, Risikoanalyse und rechtlichen Vorgaben festgelegt wird. Ihre Mapping-Tabelle verknüpft 3.2 mit ISO/IEC 27001:2022 A.5.28, A.8.15, A.8.16 und A.8.17; die ENISA betont, dass das Mapping keine Gleichwertigkeit bedeutet.
Nationale Umsetzungsgesetze
Jeder Mitgliedstaat hat sein Umsetzungsgesetz (Niederlande: Cyberbeveiligingswet; Österreich: NISG 2026; Belgien: sein NIS2-Gesetz). CIR Nummer 3.2 gilt in jedem Mitgliedstaat unmittelbar, aber nur für die in Art. 1 CIR genannten digitalen Anbieter. Unterschiede: zuständige Behörde, Meldewege, Aufsicht.
Wir behalten alle Logs für immer, dann sind wir sicher.
Für die erfassten digitalen Anbieter verlangt Nummer 3.2.5 eine vorab festgelegte Aufbewahrungsfrist, keine unendliche. Für alle gilt: 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. Für die erfassten digitalen Anbieter will Nummer 3.2.4 nicht nur Speicherung. Sie 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.
Für die erfassten digitalen Anbieter ist Nummer 3.2.3 Buchst. e eindeutig: gesamter privilegierter Zugriff plus Admin-Aktivitäten. Admins sind die Nutzer mit der größten Wirkungstiefe im Netz, ihre Aktivität gehört also ins Log.
Der günstigste Einstieg: die Liste der zu protokollierenden Anlagen aus der Risikoanalyse ableiten, die Logs an einer Stelle sammeln (zentrale Ablage oder kleines SIEM), Schwellenwerte für die wichtigsten Ereignisse setzen und regelmäßig auswerten. Ein managed SOC am ersten Tag braucht es nicht. Es braucht jemanden, der die Alarme sichtet und weiß, was zu tun ist.
- 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 (Version 1.0, Juni 2025)
Sie sollen sich um NIS2 kümmern?
Am Ende haben Sie alles in einem Dokument: was getan ist, was noch offen ist, und die Freigabe Ihrer Geschäftsführung mit Namen und Datum. Die Texte schreibt die App.
