Protokollieren für den Nachweis — was NIS2 wirklich verlangt

/01Begriff und Abgrenzung: Protokollierung ist nicht Nachweis

Protokollierung ist die technische Tätigkeit: Ereignisse werden erfasst, mit einem Zeitstempel versehen und irgendwo abgelegt. Ein Nachweis ist etwas anderes — die Fähigkeit, diese Ereignisse auf Verlangen vollständig, unverändert und in der richtigen Zeitspanne vorzulegen. Ein System, das seit Jahren protokolliert, aber die Daten nach drei Wochen automatisch überschreibt, weil niemand die Aufbewahrung konfiguriert hat, protokolliert zwar — es kann aber nichts nachweisen, sobald ein Prüfer nach dem Vorfall von vor zwei Monaten fragt. Dieser Unterschied trägt den ganzen Artikel.

Zu NIS2 und Protokollierung kursieren feste Zahlen — sechs Monate, zwölf Monate, vierundzwanzig Monate —, die in Angeboten und Blogartikeln wie Gesetzestext klingen. Für diesen Artikel wurden die Primärquellen im Volltext geprüft: die Durchführungsverordnung (EU) 2024/2690, das BSIG in der seit 06.12.2025 geltenden Fassung, der BSI-Mindeststandard zur Protokollierung und Detektion sowie der IT-Grundschutz-Baustein OPS.1.1.5. Das Ergebnis vorweg: Keine dieser Quellen nennt eine feste Monatszahl für die Protokollaufbewahrung. Was folgt, ist entweder wörtlich belegt oder ausdrücklich als Empfehlung gekennzeichnet — nicht vermischt.

Eine zweite Abgrenzung gehört ebenfalls in diesen ersten Abschnitt, weil sie die Reichweite des ganzen Themas bestimmt: NIS2 selbst gilt für „wichtige" und „besonders wichtige Einrichtungen" aus einer langen Sektorenliste, von Energie über Gesundheit bis KRITIS-nahe Betreiber. Die technisch konkreteste Regelung zur Protokollierung, die Durchführungsverordnung 2024/2690, bindet davon aber nur einen Teil — welchen, klärt Abschnitt 2.

/02Was die Verordnung wörtlich verlangt — und für wen

Die Durchführungsverordnung (EU) 2024/2690 der Kommission stützt sich auf Art. 21 Abs. 5 der NIS2-Richtlinie und legt technische und methodische Anforderungen fest — allerdings nicht für alle NIS2-Einrichtungen, sondern ausdrücklich für eine definierte Gruppe: Anbieter von DNS-Diensten, Namen-Registrierungsstellen für Top-Level-Domains, Cloud-Computing-Diensteanbieter, Rechenzentrumsdiensteanbieter, Anbieter von Content-Delivery-Networks, Anbieter verwalteter Dienste, Anbieter verwalteter Sicherheitsdienste, Betreiber von Online-Marktplätzen, Online-Suchmaschinen und Plattformen für Dienste sozialer Netzwerke sowie Vertrauensdiensteanbieter. Für alle anderen NIS2-Betroffenen — produzierendes Gewerbe, Gesundheitswesen, Energieversorger, Transport und viele mehr — gilt der allgemeinere Art. 21 der NIS2-Richtlinie beziehungsweise § 30 BSIG, ohne dass diese Verordnung sie unmittelbar bindet. Wer nicht zu den genannten Anbietern gehört, kann die DVO trotzdem als fachliche Referenz heranziehen — sie ist dann Orientierung, keine Pflicht.

Für die gebundenen Anbieter steht die Protokollierung in Anhang I Nummer 3.2 unter der Überschrift „Überwachung und Protokollierung". Drei Anforderungen daraus wörtlich: Nummer 3.2.1 verlangt, dass „die betreffenden Einrichtungen Verfahren fest[legen] und Instrumente [verwenden], um Aktivitäten in ihrem Netz- und Informationssystem zu überwachen und zu protokollieren". Nummer 3.2.2 konkretisiert die Erkennung: „Soweit durchführbar, erfolgt die Überwachung automatisch und wird vorbehaltlich der betrieblichen Kapazitäten entweder kontinuierlich oder in regelmäßigen Zeitabständen durchgeführt." Und zur Aufbewahrung, Nummer 3.2.5: „Die betreffenden Einrichtungen führen und sichern die Protokolle für einen vorab festgelegten Zeitraum und schützen sie vor unbefugten Zugriffen oder Änderungen."

Genau an dieser letzten Stelle endet der Verordnungstext, wo viele Sekundärquellen weiterschreiben. „Vorab festgelegter Zeitraum" ist keine Monatsangabe, sondern eine Verfahrensvorgabe: Sie legen die Frist selbst fest, bevor Sie protokollieren, nicht danach, und Sie können begründen, warum genau diese Frist gewählt wurde. Die 6/12/24-Monate-Angaben, die in Beratungsunterlagen kursieren, sind an branchenübliche Vorsorge, an Versicherungsbedingungen oder an Erfahrungswerte aus Vorfällen angelehnt — nachvollziehbare Empfehlungen, aber keine Zitate aus der Verordnung.

/03BSIG und der BSI-Mindeststandard: wer daran gebunden ist

Das BSIG selbst bleibt an dieser Stelle unspezifisch. § 30 Abs. 1 Satz 3 verlangt: „Die Einhaltung der Verpflichtung nach Satz 1 ist durch die Einrichtungen zu dokumentieren." § 30 Abs. 2 zählt rund zehn Maßnahmenkategorien auf — Risikoanalyse und Sicherheit für Informationssysteme, Bewältigung von Sicherheitsvorfällen, Aufrechterhaltung des Betriebs samt Backup-Management, Lieferkettensicherheit, Multi-Faktor-Authentifizierung und weitere. Eine eigene Kategorie „Protokollierung" nennt der Paragraph nicht ausdrücklich; sie folgt aus „Bewältigung von Sicherheitsvorfällen" und dem allgemeinen Stand der Technik — konkretisiert für die betroffenen Anbieter durch die Durchführungsverordnung aus Abschnitt 2, für alle übrigen NIS2-Einrichtungen bleibt sie eine Frage der Auslegung im eigenen ISMS.

Häufig als „die" NIS2-Protokollierungsvorgabe zitiert wird der Mindeststandard des BSI zur Protokollierung und Detektion von Cyberangriffen, aktuell Version 2.1 vom 14.11.2024. Sein eigener Geltungsbereich ist eindeutig: „Dieser Mindeststandard legt gemäß § 8 Abs. 1 BSIG das Mindestniveau für die Informationssicherheit des Bundes im Bereich der Protokollierung fest." Er bindet die Bundesverwaltung, nicht die private Wirtschaft. In Version 2.1 wurde laut BSI-Ankündigung „die Angabe zur Speicherfrist von Protokoll- und Protokollierungsdaten konkretisiert" — eine konkrete Zahl dazu ließ sich in den öffentlich zugänglichen Ankündigungstexten nicht wörtlich verifizieren, weshalb sie hier bewusst nicht genannt wird. Fachlich ist der Mindeststandard trotzdem eine gute Referenz, gerade weil er sauber zwischen allgemeinen Ereignissen und sicherheitsrelevanten Ereignissen unterscheidet, die von einer Löschung ausgenommen werden können.

Eine dritte Quelle liefert das methodische Gerüst, ohne selbst Gesetz zu sein: der IT-Grundschutz-Baustein OPS.1.1.5 „Protokollierung" des BSI. Als Basis-Anforderung verlangt OPS.1.1.5.A4 wörtlich: „Die Systemzeit aller protokollierenden IT-Systeme und Anwendungen MUSS immer synchron sein." OPS.1.1.5.A5 fordert: „Es MUSS technisch unterbunden werden, dass Protokollierungsdaten unkontrolliert gelöscht oder verändert werden." Als Standard-Anforderung ergänzt OPS.1.1.5.A6 den Aufbau einer zentralen Protokollierungsinfrastruktur in einem eigens dafür eingerichteten Netzsegment. Auch hier: keine Monatsangabe, aber ein belastbares Gerüst für die Fragen „was", „wie geschützt" und „wie zentral" — beantwortet als Empfehlung, nicht als Zahl.

/04Welche Quellen ins Protokoll gehören

Ein Nachweis, der nur die Firewall abdeckt, erklärt selten, wie ein Angreifer tatsächlich vorgegangen ist. Sechs Quellen liefern in der Praxis den größten Teil der Aussagekraft, weil sie unterschiedliche Phasen eines Vorfalls abdecken — vom Erstzugriff bis zur Ausbreitung im Netz.

Werkzeuge wie Wazuh decken einen großen Teil dieser Liste über einen einzigen Agenten ab — auf Endgeräten und Servern liest er Systemprotokolle, Dateiintegrität und Konfigurationsstand, während Firewall, Hypervisor und Postfachdienste meist über eigene Exportwege angebunden werden. Entscheidend ist nicht das einzelne Werkzeug, sondern dass am Ende ein SOC — intern oder als Managed-Dienst — tatsächlich alle sechs Quellen im Blick hat, statt nur die, die sich am leichtesten anschließen ließ.

/05Zentrale Sammlung und Schutz vor nachträglicher Änderung

Sechs verstreute Quellen mit sechs verschiedenen Aufbewahrungslogiken sind im Ernstfall kaum auswertbar — bis jemand sie zusammensucht, ist die Spur oft kalt. Eine zentrale Sammlung fasst die Ereignisse in einer durchsuchbaren Zeitleiste zusammen. Wichtig ist dabei die Rollenteilung: Werkzeuge wie Loki sind auf Protokolltexte ausgelegt, Prometheus auf Messwerte und Zeitreihen — ein SIEM baut auf einer solchen Sammlung auf und ergänzt Korrelation, Regeln und Alarmierung.

Der zweite, oft unterschätzte Teil von Nummer 3.2.5 der Verordnung ist der Schutz „vor unbefugten Zugriffen oder Änderungen". Drei Bausteine tragen das in der Praxis: ein getrennter Sammler, auf dem administrative Konten der protokollierten Systeme keine Löschrechte besitzen; unveränderlicher Speicher, etwa über S3-Objektspeicher mit aktivierter Object-Lock-Funktion oder ein WORM-fähiges Dateisystem; und eine Hash- oder Signaturkette, bei der jeder neue Protokolleintrag eine Prüfsumme des vorherigen einschließt — eine nachträgliche Änderung an einer beliebigen Stelle bricht die Kette sichtbar.

/06Zeitsynchronisation: die stille Voraussetzung für den Nachweis

Ein Nachweis lebt von der Reihenfolge der Ereignisse. Wenn die Systemuhr der Firewall drei Minuten vor- und die des Hypervisors zwei Minuten nachgeht, lässt sich aus zwei eigentlich zusammengehörenden Einträgen keine belastbare Abfolge mehr rekonstruieren — genau die Abfolge, die eine Incident-Response und den späteren Post-Mortem trägt. OPS.1.1.5.A4 formuliert das als Basis-Anforderung, nicht als Kür: Systemzeit MUSS immer synchron sein.

Praktisch heißt das ein zentraler Zeitserver im eigenen Netz, der sich seinerseits gegen mehrere externe Quellen abgleicht, und alle protokollierenden Systeme — Server, Netzwerkkomponenten, Hypervisor, Endgeräte — zeigen auf diesen einen internen Zeitserver, nicht jedes für sich auf eine eigene externe Quelle. Die Abweichungstoleranz sollte selbst überwacht und protokolliert werden: Ein System, dessen Uhr plötzlich driftet, ist entweder fehlkonfiguriert oder manipuliert — beides ein Befund, den man kennen will, bevor er den nächsten Vorfall unauswertbar macht.

/07Speicherbedarf realistisch abschätzen

Bevor ein Datastore oder ein S3-Vertrag dimensioniert wird, lohnt eine grobe, aber nachvollziehbare Rechnung statt einer Pauschalzahl aus einem Angebot. Die Formel ist einfach: Ereignisse pro Sekunde, multipliziert mit der durchschnittlichen Größe eines Ereignisses, multipliziert mit der Zahl der Tage, für die aufbewahrt wird. Ein Blick auf den laufenden Bestand hilft bei der Kalibrierung dieser Annahmen:

# Wie viel Journal-Speicher belegt ein einzelner Host bereits?
journalctl --disk-usage
# Archivierte Journal-Dateien (Systemd) auf 2 GiB begrenzen
journalctl --vacuum-size=2G
# Grobe Tagesrate eines Log-Verzeichnisses schätzen
du -sh /var/log/

Als Anhaltspunkt, ausdrücklich als Erfahrungswert und nicht als belegte Zahl: Ein Betrieb mit rund 50 Arbeitsplätzen, aktiver Firewall-Protokollierung, Verzeichnisdienst und Endgeräteagenten bewegt sich häufig im Bereich von wenigen Gigabyte Rohprotokoll pro Tag, bevor Komprimierung greift — nach Deduplizierung und Kompression im SIEM meist deutlich weniger. Die tatsächliche Rate hängt stark an der Zahl der Regeln, der Protokolltiefe der Firewall und daran, ob DNS-Abfragen mitprotokolliert werden, die oft den größten Einzelposten stellen. Eine verlässliche Zahl liefert nur eine Messung der eigenen Umgebung über mindestens eine volle Woche, keine pauschale Angabe.

Wer die Aufbewahrungsfrist verdoppelt, verdoppelt in guter Näherung auch den Speicherbedarf — ein Grund mehr, die Frist aus Abschnitt 2 wirklich zu begründen, statt sie „auf Nummer sicher" hoch anzusetzen und dann bei der Kapazität zu sparen.

/08Das Spannungsfeld mit der DSGVO

Ein Großteil der Protokolldaten ist personenbezogen — Benutzernamen, IP-Adressen, Anmeldezeiten lassen sich auf einzelne Mitarbeiter zurückführen. Art. 5 Abs. 1 lit. e DSGVO bindet die Speicherung an den Zweck: personenbezogene Daten dürfen nur so lange in identifizierbarer Form vorgehalten werden, wie es der Zweck erfordert. Eine unbegrenzte „Aufbewahrung auf Vorrat" trägt diesen Zweck nicht automatisch — sie muss begründet sein, genau wie die Frist aus der Durchführungsverordnung.

Als Rechtsgrundlage für Security-Logging kommt in der Praxis meist Art. 6 Abs. 1 lit. f DSGVO in Betracht — das berechtigte Interesse an der Sicherheit der eigenen Systeme, abgewogen gegen die Interessen der betroffenen Mitarbeiter. Löschbegehren nach Art. 17 stoßen dabei regelmäßig auf die Ausnahme in Art. 17 Abs. 3 lit. b: Besteht eine rechtliche Verpflichtung zur Aufbewahrung — etwa aus der Nachweispflicht nach § 30 BSIG —, muss nicht sofort gelöscht werden. Beide Ebenen laufen damit auf dieselbe Anforderung hinaus: eine dokumentierte, begründete Frist statt eines unbegrenzten oder willkürlichen Zeitraums.

In der Praxis braucht das ein Löschkonzept, das beide Seiten bedient: eine kurze Frist mit direktem Personenbezug (Rohlogs), eine längere für aggregierte, sicherheitsrelevante Befunde ohne unmittelbaren Personenbezug, und eine Ausnahme für Daten, die nachweislich zu einem laufenden Vorfall gehören. Wird die Protokollierung an einen Managed-Dienst ausgelagert, kommt die Auftragsverarbeitung dazu: ein AVV mit dem Dienstleister und die dort vereinbarten TOM gehören zur Dokumentation, nicht nur die technische Konfiguration. Wer ohnehin nach ISO/IEC 27001 arbeitet, hat für diese Abwägung meist schon ein Verfahren im ISMS — es lässt sich für die NIS2-Frist wiederverwenden, statt ein zweites parallel aufzusetzen.

/09Wo es hakt — und wann sich das lohnt

Ehrlich: Ein SIEM erzeugt keine Konformität. Es ist eine Voraussetzung, keine Garantie. Drei Fallstricke tauchen in der Praxis immer wieder auf.

Protokollieren ohne Auswertung

Die häufigste Lücke ist nicht die fehlende Technik, sondern das fehlende Verfahren. Ein SIEM, das Alarme erzeugt, die niemand innerhalb einer festgelegten Frist ansieht, erfüllt weder Nummer 3.2.2 der Verordnung („Überwachung … kontinuierlich oder in regelmäßigen Zeitabständen") noch den eigentlichen Zweck. Ohne definierte Zuständigkeit — intern oder als SOC-Dienstleistung — bleibt die Auswertung Zufall.

Speicher wächst schneller als geplant

Wird die Aufbewahrungsfrist nachträglich verlängert, ohne den Speicherbedarf aus Abschnitt 7 neu zu rechnen, füllt sich der Datastore schneller als erwartet — und im schlechtesten Fall überschreiben ältere Regeln genau die Protokolle, die für einen laufenden Vorfall gebraucht würden.

SIEM ohne SOAR bleibt Handarbeit

Ein SIEM erkennt, ein SOAR-Werkzeug automatisiert die Reaktion darauf — beides zu verwechseln führt zu der Annahme, ein Alarm sei bereits eine Antwort. Für kleinere Umgebungen ist das oft kein Problem, weil ein Mensch die wenigen Alarme selbst abarbeitet; bei wachsendem Ereignisvolumen wird die fehlende Automatisierung zum Engpass.

Dafür spricht ein eigener, konsequenter Aufbau

• Sie gehören zu den ausdrücklich gebundenen Anbietern aus Abschnitt 2 oder wollen sich unabhängig davon an deren technischem Standard orientieren.
• Mehrere der sechs Quellen aus Abschnitt 4 fehlen bislang — insbesondere Hypervisor und Fernzugang werden in vielen KMU-Umgebungen bis heute nicht protokolliert.
• Ein Vorfall oder eine Auditankündigung steht bevor und die aktuelle Aufbewahrung reicht nachweislich nicht bis zum relevanten Zeitpunkt zurück.

Dagegen spricht — vorerst

• Es gibt noch kein Verfahren für die Auswertung. Erst die Sammeltechnik aufzubauen und die Auswertung offenzulassen, produziert vor allem Speicherkosten ohne Sicherheitsgewinn.
• Das Löschkonzept aus Abschnitt 8 fehlt noch. Wer zuerst sammelt und die DSGVO-Abwägung nachträglich löst, riskiert, Daten löschen zu müssen, die gerade für einen Nachweis gebraucht würden.

In der Praxis ist beides selten getrennt zu haben: Die Sammeltechnik lohnt sich vor allem zusammen mit der Zuständigkeit für ihre Auswertung — sonst bleibt sie das, was der ehrliche Einstieg dieses Abschnitts benennt.

/10Häufige Fragen