Welche Logs sind DSGVO-konform? Praxisleitfaden

Ein fehlgeschlagener Login, eine geänderte Berechtigung oder ein ungewöhnlicher Datenexport kann der erste Hinweis auf einen Angriff sein. Wer solche Ereignisse nicht protokolliert, erkennt Sicherheitsvorfälle oft zu spät. Doch welche Logs sind DSGVO-konform – und wo wird aus notwendiger Sicherheitsüberwachung eine unzulässige Datensammlung? Für mittelständische Unternehmen liegt die Antwort nicht in möglichst vielen Daten, sondern in einem klar begründeten, kontrollierten Logging.

Logs sind personenbezogene Daten – häufig ohne dass es auffällt

Ein Logeintrag wirkt zunächst technisch: Zeitstempel, IP-Adresse, Benutzerkennung, Systemname und Ereignis. Sobald sich eine Person direkt oder indirekt identifizieren lässt, verarbeitet das Unternehmen personenbezogene Daten. Das trifft beispielsweise auf Benutzerkonten, geschäftliche E-Mail-Adressen, Client-IP-Adressen und Gerätekennungen zu.

Die DSGVO verbietet Sicherheitslogs nicht. Im Gegenteil: Artikel 32 DSGVO verlangt angemessene technische und organisatorische Maßnahmen, um Vertraulichkeit, Integrität und Verfügbarkeit der Verarbeitung sicherzustellen. Ohne nachvollziehbare Protokolle lassen sich viele Angriffe, Fehlkonfigurationen und unberechtigte Zugriffe weder erkennen noch aufklären.

Entscheidend ist die Abwägung: Ein Log muss einen konkreten Sicherheits- oder Betriebszweck erfüllen. Es darf nicht als Vorratsspeicher für jedes Nutzerverhalten dienen. Das entspricht insbesondere den Grundsätzen aus Artikel 5 DSGVO: Zweckbindung, Datenminimierung, Speicherbegrenzung und Integrität.

Welche Logs sind DSGVO-konform?

DSGVO-konform sind Logs nicht wegen ihres Dateiformats oder weil sie auf einem deutschen Server liegen. Konform werden sie durch Zweck, Umfang, Zugriffsschutz, Löschkonzept und transparente Dokumentation. In einer gut geführten Sicherheitsarchitektur gehören vor allem folgende Protokollarten dazu.

Sicherheits- und Authentifizierungslogs

Anmelde- und Abmeldevorgänge, fehlgeschlagene Login-Versuche, Mehrfaktor-Authentifizierungen, Passwort-Resets sowie Konto- oder Rechteänderungen sind regelmäßig erforderlich. Sie helfen, Brute-Force-Angriffe, kompromittierte Konten und unzulässige Administratorzugriffe zu erkennen.

Gespeichert werden sollte, was für die Prüfung erforderlich ist: Benutzerkennung, Zeitpunkt, Zielsystem, Ergebnis und gegebenenfalls Quell-IP. Der Inhalt von Passwörtern oder Zugangstoken gehört niemals in ein Log.

Firewall-, VPN- und Netzwerklogs

Firewall- und VPN-Protokolle dokumentieren Verbindungen, blockierte Zugriffe, auffällige Datenströme und Zugriffe von außen. Für Unternehmen mit Außendienst, Homeoffice oder mehreren Standorten sind diese Daten oft unverzichtbar, um einen Sicherheitsvorfall zeitlich und technisch einzugrenzen.

Die Protokollierung kompletter Kommunikationsinhalte ist dafür in aller Regel nicht nötig. Metadaten wie Quelle, Ziel, Port, Zeit und Entscheidung der Firewall reichen meist aus. Bei Proxy-Logs ist besondere Zurückhaltung geboten: Vollständige URL-Verläufe können weitreichende Rückschlüsse auf Beschäftigte zulassen. Hier muss der Zweck besonders eng gefasst sein.

Endpoint-, Server- und EDR-Logs

Antivirenprogramme, Endpoint Detection and Response Systeme sowie Server erfassen Malware-Funde, verdächtige Prozesse, Systemänderungen und sicherheitsrelevante Ereignisse. Gerade bei Ransomware sind solche Spuren entscheidend. Das Bundesamt für Sicherheit in der Informationstechnik beschreibt die Bedrohungslage in Deutschland weiterhin als angespannt; Ransomware bleibt für Unternehmen eines der größten Betriebsrisiken.

Auch ENISA führt Ransomware in seinem Threat Landscape Report als zentrale Bedrohung. Der praktische Schluss für den Mittelstand: Wer Angriffsindikatoren nicht zentral sichtbar macht, ist im Ernstfall auf Vermutungen angewiesen. Endpoint-Logs sind daher in der Regel gut begründbar, sofern sie auf Sicherheitsereignisse begrenzt und gegen Manipulation geschützt werden.

Backup- und Wiederherstellungsprotokolle

Ein Backup gilt nur dann als belastbar, wenn sich seine Durchführung und Wiederherstellbarkeit nachweisen lassen. Backup-Logs dokumentieren Sicherungsläufe, Fehler, Aufbewahrungsstände, Verschlüsselung und Testwiederherstellungen. Sie enthalten häufig weniger personenbezogene Daten als andere Logarten, können aber Dateinamen oder Benutzerbezüge aufweisen.

Für die Betriebssicherheit sind sie unverzichtbar. Sie belegen zugleich, dass das Unternehmen seine Verfügbarkeit nicht nur verspricht, sondern überprüft. Das ist bei Ausfällen, Datenschutzvorfällen und Kundenanforderungen ein wesentlicher Vorteil.

Rechtsgrundlage: Sicherheit ja, Mitarbeiterkontrolle nein

Für Sicherheitslogging ist häufig Artikel 6 Absatz 1 Buchstabe f DSGVO relevant: das berechtigte Interesse des Unternehmens an der Abwehr, Erkennung und Aufklärung von Sicherheitsvorfällen. Bei Beschäftigtendaten ist zusätzlich § 26 Bundesdatenschutzgesetz zu berücksichtigen. Je nach System und Nutzung können weitere Rechtsgrundlagen oder Vereinbarungen notwendig sein.

Das berechtigte Interesse ist kein Freifahrtschein. Unternehmen müssen dokumentieren, warum ein bestimmtes Log benötigt wird, welche Daten darin enthalten sind, wer darauf zugreifen darf und warum mildere Mittel nicht ausreichen. Bei einer umfangreichen oder besonders eingriffsintensiven Überwachung kann eine Datenschutz-Folgenabschätzung nach Artikel 35 DSGVO erforderlich werden.

Die Grenze ist dort erreicht, wo Logging zur dauerhaften Leistungs- oder Verhaltenskontrolle wird. Ein Systemadministrator darf nachvollziehen, ob ein Nutzerkonto ungewöhnliche Datenmengen exportiert hat. Eine lückenlose Auswertung jeder aufgerufenen Webseite oder jeder Tastatureingabe wäre dagegen regelmäßig unverhältnismäßig.

Aufbewahrungsfristen: So lange wie nötig, nicht so lange wie möglich

Die DSGVO nennt keine feste Frist für Firewall-, Login- oder Serverlogs. Eine pauschale Antwort wie „90 Tage sind immer erlaubt“ ist daher falsch. Die geeignete Frist hängt von Bedrohungslage, Erkennungszeit, Systemkritikalität, vertraglichen Vorgaben und möglichen gesetzlichen Pflichten ab.

Als praxisnaher Ausgangspunkt können sicherheitsrelevante Ereignislogs oft für 30 bis 90 Tage im direkten Zugriff vorgehalten werden. Für kritische Systeme oder zur Aufklärung komplexer Vorfälle kann eine längere, begründete Archivierung erforderlich sein. Dabei sollten Daten nach Ablauf der aktiven Analysephase gelöscht, anonymisiert oder nur noch mit stark eingeschränktem Zugriff aufbewahrt werden.

Wichtig ist ein automatisiertes Löschkonzept. Ein Logserver, der Daten jahrelang weiterwachsen lässt, ist kein Sicherheitsgewinn. Er erhöht das Datenschutzrisiko, die Kosten und die Menge potenziell kompromittierbarer Informationen.

Praxisfall: Das unsichtbare Administratorkonto

In einer anonymisierten Sicherheitsanalyse eines mittelständischen Dienstleisters zeigte sich ein typisches Problem: Die Firewall schrieb zwar Verbindungsdaten, die Windows-Server protokollierten Anmeldungen, doch die Daten lagen verteilt auf mehreren Systemen. Eine zentrale Auswertung gab es nicht.

Bei der Prüfung fielen 14 administrative Konten auf, darunter drei ehemalige Dienstleisterzugänge. Ein Konto hatte sich über Monate hinweg nachts per VPN angemeldet. Es gab keinen Hinweis auf einen bestätigten Angriff, aber auch keinen sauberen Nachweis, wofür der Zugang noch benötigt wurde. Die Konten wurden bereinigt, VPN-Zugriffe mit Mehrfaktor-Authentifizierung abgesichert und sicherheitsrelevante Ereignisse zentral zusammengeführt.

Der entscheidende Punkt: Nicht mehr Logging löste das Problem, sondern besseres Logging. Definierte Ereignisse, klare Zuständigkeiten, kurze Reaktionswege und begrenzte Zugriffsrechte machten aus verstreuten Daten eine belastbare Sicherheitskontrolle.

So wird aus Logdaten eine nachvollziehbare Sicherheitsmaßnahme

Ein tragfähiges Logging-Konzept beginnt nicht mit dem Kauf eines Tools. Zuerst werden die schützenswerten Systeme identifiziert: Domain-Controller, E-Mail, Firewall, VPN, Backup, Dateiablagen, ERP und besonders kritische Endgeräte. Anschließend wird je System festgelegt, welche Ereignisse sicherheitsrelevant sind.

Diese Festlegung gehört in ein Verzeichnis der Verarbeitungstätigkeiten oder in eine ergänzende technische Dokumentation. Darin sollten Zweck, Kategorien personenbezogener Daten, Rechtsgrundlage, Aufbewahrungsfrist, Empfänger, Speicherort und Zugriffsberechtigte nachvollziehbar beschrieben sein. Wird ein externer Managed-Security-Partner eingesetzt, ist in der Regel ein Auftragsverarbeitungsvertrag nach Artikel 28 DSGVO erforderlich.

Ebenso wichtig ist der Speicherort. Logdaten können Angriffswege, Benutzerkennungen und interne Systemstrukturen offenlegen. Sie gehören verschlüsselt übertragen und gespeichert, manipulationsgeschützt abgelegt und nur einem eng definierten Personenkreis zugänglich gemacht. Rollenbasierte Berechtigungen und eine Protokollierung der Zugriffe auf das Logsystem selbst sind dabei sinnvoll.

Der BSI-IT-Grundschutz betont die Bedeutung einer geregelten Protokollierung und Auswertung. Für den Mittelstand bedeutet das nicht, rund um die Uhr auf Dashboards zu starren. Es bedeutet, dass kritische Warnungen zuverlässig ankommen, bewertet werden und eine festgelegte Reaktion auslösen.

Vier Fragen für die Geschäftsleitung

Bevor neue Logs aktiviert oder bestehende Datenbestände erweitert werden, sollten Verantwortliche vier Fragen beantworten:

• Welches konkrete Sicherheits- oder Betriebsrisiko soll dieses Log abdecken?
• Welche personenbezogenen Daten sind dafür tatsächlich erforderlich?
• Wer wertet die Daten aus und wie wird ein Vorfall bearbeitet?
• Wann werden die Daten automatisiert gelöscht oder anonymisiert?

Kann eine dieser Fragen nicht klar beantwortet werden, ist das Logging-Konzept noch nicht belastbar. Das gilt besonders für gewachsene IT-Landschaften, in denen Firewall, Microsoft-Umgebung, Backup und Endgeräte von unterschiedlichen Dienstleistern betreut werden.

Sicherheitslogs sind kein Selbstzweck und keine datenschutzrechtliche Last, die man möglichst klein halten sollte. Richtig geplant geben sie Unternehmen Kontrolle zurück: über Zugriffe, über Auffälligkeiten und über die eigene Reaktionsfähigkeit. Eine unabhängige Sicherheitsanalyse zeigt meist schnell, welche Protokolle fehlen, welche Daten zu lange liegen bleiben und wo aus technischer Komplexität ein vermeidbares Geschäftsrisiko geworden ist.