Logs aufbewahren: DSGVO, NIS-2 und ISO 27001 Anforderungen verglichen
Wie lange müssen Logs aufbewahrt werden? DSGVO, NIS-2 und ISO 27001 im Vergleich – mit konkreten Fristen und praxisnahen Umsetzungstipps für KMU-IT.
Logs aufbewahren: DSGVO, NIS-2 und ISO 27001 Anforderungen verglichen
Key Takeaways
- Keine der drei Regelwerke schreibt eine einheitliche Mindestaufbewahrungsfrist für Logs vor — der Zweck und die Risikoeinstufung entscheiden.
- Das Spannungsfeld zwischen DSGVO-Datensparsamkeit und Nachweispflicht aus NIS-2 und ISO 27001 lässt sich durch ein dokumentiertes, kategorisiertes Aufbewahrungskonzept auflösen.
- Praxisempfehlung: 12 Monate für sicherheitsrelevante Logs, davon 90 Tage im schnell abfragbaren Hot-Tier.
- Microsoft 365, Azure Monitor und Wazuh bieten jeweils spezifische Konfigurationsoptionen, um Compliance-Anforderungen technisch durchzusetzen.
Warum die Frage nach der Logaufbewahrung so komplex ist
IT-Verantwortliche in Unternehmen ohne dediziertes Security-Team stehen vor einer typischen Compliance-Falle: Sie wissen, dass sie Logs aufbewahren sollen — aber weder DSGVO, NIS-2 noch ISO 27001 nennen eine einheitliche, gesetzlich festgeschriebene Zahl. Stattdessen formulieren alle drei Regelwerke ihre Anforderungen aus unterschiedlichen Blickwinkeln, die sich auf den ersten Blick widersprechen.
Die DSGVO zielt auf Datensparsamkeit: Personenbezogene Daten sollen so kurz wie möglich gespeichert werden. NIS-2 und ISO 27001 verlangen dagegen, dass sicherheitsrelevante Ereignisse protokolliert und für Forensik, Ermittlungen und Behördennachweise verfügbar gehalten werden. Dieser Widerspruch ist real — und lösbar, sobald man die Anforderungen der einzelnen Regelwerke präzise kennt.
Dieser Artikel schlüsselt auf, was die drei Regelwerke konkret fordern, wo Konflikte entstehen und wie ein praktisch taugliches Aufbewahrungskonzept für KMU technisch umgesetzt werden kann.
Was die DSGVO zu Logs sagt
Logs als personenbezogene Daten
Bevor Aufbewahrungsfristen diskutiert werden, muss eine Grundfrage beantwortet sein: Sind die betreffenden Logs überhaupt personenbezogene Daten im Sinne von Art. 4 Nr. 1 DSGVO?
Die Antwort ist in einem Unternehmenskontext fast immer: Ja. Ein Windows-Sicherheitslog, der Nutzernamen, IP-Adressen und Zeitstempel enthält, ist personenbezogen. Dasselbe gilt für Microsoft-365-Audit-Logs, VPN-Zugangsprotokolle oder Firewall-Logs, die einem konkreten Nutzerkonto zugeordnet werden können.
IP-Adressen alleine sind laut EuGH personenbezogene Daten, sobald der Verantwortliche die Möglichkeit hat, die dahinterstehende Person zu identifizieren — was in einem Unternehmensumfeld mit Active Directory grundsätzlich gegeben ist.
Datensparsamkeit und Zweckbindung
Art. 5 Abs. 1 lit. c DSGVO fordert Datensparsamkeit: Daten müssen dem Zweck angemessen und auf das notwendige Maß beschränkt sein. Art. 5 Abs. 1 lit. e regelt die Speicherbegrenzung: Personenbezogene Daten dürfen nicht länger gespeichert werden, als es für den Verarbeitungszweck erforderlich ist.
Der dokumentierte Zweck ist entscheidend. Für Security-Logs kommen folgende legitime Zwecke in Betracht:
- Erkennung und Untersuchung von Sicherheitsvorfällen
- Nachweis der Systemintegrität gegenüber Aufsichtsbehörden
- Forensische Analyse nach einem Angriff
- Erfüllung gesetzlicher Nachweispflichten (NIS-2, branchenspezifische Regulierung)
Die DSGVO verbietet nicht, Logs aus Sicherheitsgründen aufzubewahren. Sie verlangt, dass der Zweck vorab dokumentiert, verhältnismäßig und im Verzeichnis der Verarbeitungstätigkeiten nach Art. 30 DSGVO erfasst ist.
Praktische Fristen unter der DSGVO
Eine gesetzliche Mindestaufbewahrungsfrist gibt es nicht. In der Praxis haben sich folgende Orientierungswerte etabliert:
- Operative Logs (z. B. Webserver-Access-Logs ohne Security-Kontext): 7–30 Tage
- Sicherheitsrelevante Logs (SIEM-Events, Authentifizierungsprotokolle, Admin-Aktionen): 90–180 Tage
- Audit-Logs für Compliance-Nachweise: bis zu 12 Monate, in begründeten Fällen länger
Wichtig: Die gewählte Frist muss im Löschkonzept dokumentiert und technisch erzwungen sein — eine Policy-Aussage ohne technische Durchsetzung reicht für Auditoren und Aufsichtsbehörden nicht aus.
NIS-2: Protokollierung als gesetzliche Sicherheitspflicht
Wen betrifft NIS-2?
Die NIS-2-Richtlinie (EU 2022/2555), in Deutschland umgesetzt durch das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG), erfasst Unternehmen ab 50 Mitarbeitern oder 10 Mio. Euro Jahresumsatz in kritischen und wichtigen Sektoren. Dazu zählen unter anderem Energie, Transport, Gesundheit, digitale Infrastruktur, Maschinenbau und Teile des öffentlichen Sektors.
Für KMU in diesen Sektoren ist NIS-2 keine optionale Maßnahme, sondern eine gesetzliche Pflicht mit erheblichem Bußgeldrisiko (bis zu 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes für wichtige Einrichtungen).
Konkrete Anforderungen an die Protokollierung
Art. 21 der NIS-2-Richtlinie verpflichtet betroffene Einrichtungen zur Umsetzung geeigneter Sicherheitsmaßnahmen. Protokollierung ist darin ein explizit genanntes Element. Das BSI konkretisiert die Anforderungen im IT-Grundschutz-Kompendium und in der BSI-Technischen Richtlinie.
Kernanforderungen:
- Protokollierung sicherheitsrelevanter Ereignisse auf Netzwerk-, System- und Anwendungsebene
- Schutz der Protokolle vor Manipulation und unberechtigtem Zugriff
- Regelmäßige Auswertung der Protokolle im Rahmen eines aktiven Monitorings
- Aufbewahrung für forensische Untersuchungen im Nachgang eines Vorfalls
Aufbewahrungsdauer: BSI-Empfehlung für NIS-2
Obwohl die Richtlinie selbst keine konkrete Zahl nennt, empfiehlt das BSI im IT-Grundschutz-Kompendium (Baustein OPS.1.1.5, Protokollierung) eine Mindestaufbewahrungsdauer von 12 Monaten für sicherheitsrelevante Protokolldaten.
Diese Empfehlung hat einen sachlichen Hintergrund: Angriffe — insbesondere durch APT-Akteure (Advanced Persistent Threats) — werden im Durchschnitt erst nach Wochen bis Monaten entdeckt. Ohne ausreichend lange Log-Historie ist eine forensische Aufklärung nicht möglich, was behördliche Meldepflichten nach Art. 23 NIS-2 faktisch unlösbar macht.
ISO 27001:2022: Protokollierung als normatives Control
Relevante Controls in Annex A
Die ISO 27001:2022 enthält im Annex A drei direkt relevante Controls:
| Control | Bezeichnung | Kernanforderung |
|---|---|---|
| A.8.15 | Logging | Protokolle erstellen, schützen und aufbewahren |
| A.8.16 | Monitoring Activities | Protokolle auswerten, Anomalien erkennen |
| A.8.17 | Clock Synchronisation | Zeitstempel-Konsistenz über alle Systeme sicherstellen |
Control A.8.15 fordert explizit, dass Protokolle vor Veränderung und unbefugtem Zugriff geschützt werden. Das schließt Write-once-Speicherung, zentrale Log-Aggregation und Integritätsprüfung ein — technische Anforderungen, die auch unter NIS-2 und der DSGVO (Vertraulichkeit und Integrität nach Art. 5 Abs. 1 lit. f) relevant sind.
Keine festgeschriebene Frist — Risikobewertung entscheidet
ISO 27001 ist ein Management-System-Standard. Er schreibt keine konkreten Fristen vor, sondern verlangt, dass die Organisation ihre eigene Risikobeurteilung durchführt und auf dieser Basis Fristen festlegt.
In der Praxis bedeutet das: Eine zertifizierte Organisation muss in ihrer Security Policy dokumentieren, welche Logkategorien wie lange aufbewahrt werden und warum — auf Basis einer nachvollziehbaren Risikoabschätzung. Zertifizierungsauditoren prüfen nicht nur ob Logs vorhanden sind, sondern ob das Aufbewahrungskonzept der tatsächlichen Risikolage des Unternehmens angemessen ist.
Vergleich: DSGVO, NIS-2 und ISO 27001 auf einen Blick
| Kriterium | DSGVO | NIS-2 / BSI | ISO 27001:2022 |
|---|---|---|---|
| Rechtscharakter | EU-Verordnung (direkt anwendbar) | EU-Richtlinie (national umgesetzt) | freiwilliger Standard |
| Konkrete Mindestfrist | keine | 12 Monate (BSI-Empfehlung) | keine (risikobezogen) |
| Maximale Aufbewahrung | nach Zweck begrenzt | nach Verhältnismäßigkeit | nach Risikobeurteilung |
| Primärer Fokus | Datenschutz der betroffenen Personen | Cybersicherheit der Infrastruktur | Informationssicherheits-Management |
| Sanktionen bei Verstoß | bis 4 % des weltweiten Jahresumsatzes | bis 10 Mio. EUR / 2 % Umsatz | Verlust der Zertifizierung |
| Dokumentationspflicht | Verarbeitungsverzeichnis Art. 30 | Nachweis implementierter Maßnahmen | Statement of Applicability |
Die Tabelle macht deutlich: Es gibt keine direkte Kollision zwischen den Regelwerken — aber ohne ein schriftliches, kategorisiertes Aufbewahrungskonzept entstehen Lücken gegenüber allen drei.
Das Spannungsfeld auflösen: Datensparsamkeit vs. Nachweispflicht
Das häufigste Missverständnis in der Praxis lautet: „Wenn wir Logs 12 Monate aufbewahren, verstoßen wir gegen die DSGVO.
Häufige Fragen
Wie lange müssen Security-Logs nach DSGVO aufbewahrt werden?
Die DSGVO nennt keine konkrete Mindestaufbewahrungsfrist für Security-Logs. Entscheidend ist das Zweckbindungsprinzip: Logs dürfen nur so lange gespeichert werden, wie es für den dokumentierten Verarbeitungszweck notwendig ist. In der Praxis gelten 90–180 Tage für operative Logs und bis zu 12 Monate für sicherheitsrelevante Logs als verhältnismäßig, sofern der Zweck im Verarbeitungsverzeichnis nach Art. 30 DSGVO dokumentiert und eine Interessenabwägung nach Art. 6 Abs. 1 lit. f DSGVO durchgeführt wurde.
Welche Logaufbewahrungspflichten gelten unter NIS-2?
NIS-2 (Art. 21 der Richtlinie EU 2022/2555) verpflichtet betroffene Einrichtungen zur Implementierung von Protokollierungsmaßnahmen als Teil der Cybersicherheitspflichten. Das BSI empfiehlt im IT-Grundschutz-Kompendium (Baustein OPS.1.1.5) eine Mindestaufbewahrungsdauer von 12 Monaten für sicherheitsrelevante Ereignisprotokolle. Diese Empfehlung spiegelt die Erfahrung wider, dass Angriffe oft erst Monate nach dem initialen Eindringen entdeckt werden.
Was fordert ISO 27001:2022 konkret zur Protokollierung?
ISO 27001:2022 enthält in Annex A die Controls A.8.15 (Logging), A.8.16 (Monitoring Activities) und A.8.17 (Clock Synchronisation). Die Norm fordert, dass Protokolle erstellt, vor Manipulation geschützt und regelmäßig ausgewertet werden. Konkrete Aufbewahrungsfristen schreibt ISO 27001 nicht vor – diese müssen im Rahmen der organisationsspezifischen Risikobeurteilung festgelegt und im Statement of Applicability dokumentiert werden.