DSGVO-Protokollierung 2026: Was muss ich loggen, was nicht?

Die DSGVO verlangt von Ihnen einen Spagat: Auf der einen Seite muessen Sie Sicherheitsvorfaelle nachweisen und Zugriffe auf personenbezogene Daten luekenlos protokollieren. Auf der anderen Seite duerfen Sie nicht alles mitloggen, was technisch moeglich waere — denn jede Logzeile mit personenbezogenen Daten unterliegt selbst wieder der DSGVO. Seit den Praezisierungen durch die Aufsichtsbehoerden 2025 und der konsolidierten Orientierungshilfe der DSK 2026 ist klar: Wer pauschal “alles fuer ein Jahr” speichert, riskiert ein Bussgeld — ebenso wie der, der gar nichts loggt.

Dieser Artikel fasst zusammen, was 2026 wirklich verpflichtend ist, welche Felder Sie vermeiden sollten und wie Sie eine ELK- oder Loki-Stack-Architektur DSGVO-konform betreiben. Zielgruppe sind IT-Verantwortliche im Mittelstand, die ein eigenes SIEM oder zumindest zentrales Logging betreiben oder einfuehren wollen.

Was Sie zwingend protokollieren muessen

Die Pflicht zur Protokollierung ergibt sich aus Art. 32 DSGVO (Sicherheit der Verarbeitung) in Verbindung mit Art. 5 Abs. 2 (Rechenschaftspflicht) sowie aus BSI IT-Grundschutz, branchenspezifischen Vorgaben (TISAX, KRITIS) und ab 2026 verstaerkt aus NIS2. Konkret unverzichtbar sind:

• Authentifizierungsereignisse: erfolgreiche und fehlgeschlagene Anmeldungen an allen Systemen mit personenbezogenen Daten, inklusive Quell-IP, Benutzername, Zeitstempel und Ergebnis.
• Privilegierte Aktionen: sudo, RunAs, Rollenwechsel, Aenderungen an Berechtigungen, Anlage und Loeschung von Benutzern.
• Zugriffe auf personenbezogene Daten: Lesen, Aendern, Loeschen, Exportieren — besonders bei besonderen Kategorien nach Art. 9 (Gesundheit, Religion, Gewerkschaft).
• Sicherheitsrelevante Systemereignisse: Firewall-Blocks, IDS/IPS-Alarme, Antivirus-Funde, Konfigurationsaenderungen, Patch-Installation.
• Datenuebertragungen: Exporte, Backups, Schnittstellenaufrufe — insbesondere bei Auftragsverarbeitung oder Drittlandtransfers.
• Loeschvorgaenge: Nachweis, dass Loeschpflichten nach Art. 17 tatsaechlich erfuellt wurden.

Wichtig: Die Protokollierung dient hier nicht der Verhaltenskontrolle, sondern der Sicherheit. Das muss in Ihrem Verzeichnis von Verarbeitungstaetigkeiten (VVT) auch genau so dokumentiert sein, und der Betriebsrat ist bei mitbestimmungspflichtigen Aspekten zwingend einzubeziehen.

Was Sie nicht loggen duerfen

Genauso wichtig wie das “Was” ist das “Was nicht”. Die DSK hat 2026 mehrere typische Verstoesse explizit benannt:

• Vollstaendige URLs mit Query-Strings, die Tokens, Session-IDs oder personenbezogene Parameter enthalten (?email=...&token=...).
• Request-Bodies bei Formularen, in denen Nutzer Klartextdaten eingeben (Kontakt-, Bewerbungs- oder Anamneseformulare).
• Volle Mailbodies oder Anhaenge in SMTP- oder MTA-Logs.
• Tastatureingaben und Mausbewegungen (Keylogging) ausser im eng begrenzten forensischen Einzelfall mit Rechtsgrundlage.
• Inhaltliche Chat- oder Telefonprotokolle ohne explizite Einwilligung und Hinweis.
• Daten besonderer Kategorien (Art. 9) duerfen nur protokolliert werden, wenn das wirklich unvermeidbar ist — und dann zwingend pseudonymisiert oder verschluesselt.

Faustregel: Loggen Sie das Ereignis (“Benutzer X hat Datensatz Y exportiert”), nicht den Inhalt (“Benutzer X hat Datensatz Y mit Diagnose Z exportiert”). Wer aus Bequemlichkeit ganze HTTP-Requests inklusive Body in Elasticsearch kippt, hat in der Regel ein DSGVO-Problem.

Aufbewahrungsfristen 2026 — der pragmatische Rahmen

Die DSGVO selbst nennt keine festen Fristen. Stattdessen gilt das Prinzip der Speicherbegrenzung: so lange wie noetig, so kurz wie moeglich. In der Praxis haben sich folgende Werte etabliert, die von Aufsichtsbehoerden und Auditoren akzeptiert werden:

Logtyp	Empfohlene Aufbewahrung	Begruendung
Security-Events (Auth, Firewall, IDS)	90 Tage	Standard fuer Vorfallserkennung und -aufklaerung
SIEM-Korrelations-Events	6 Monate	Erkennung von Slow-Burn-Angriffen
Privilegierte Zugriffe (Admin, sudo)	12 Monate	Compliance, BSI-Grundschutz, KRITIS
Zugriffe auf besondere Kategorien	bis zu 12 Monate	Nachweispflicht im Streitfall
Backup-Logs	30 Tage nach letztem zugehoerigen Backup	Konsistenz mit Backup-Retention
Anwendungs-Debuglogs	7-14 Tage	Fehleranalyse, kein Sicherheitszweck
Webserver-Access-Logs (gekuerzt)	7 Tage	DSK-Empfehlung, IP-Kuerzung empfohlen

Wichtig: Diese Fristen muessen technisch erzwungen werden, nicht nur in einem Konzept stehen. Wer eine 90-Tage-Frist im DSGVO-Konzept beschreibt, aber alte Indices nie loescht, hat im Auditfall ein Problem. Setzen Sie in Elasticsearch ILM-Policies, in Loki retention-Periods und auf Dateisystemebene logrotate sauber auf.

Pseudonymisierung — wenn personenbezogene Daten unvermeidbar sind

Pseudonymisierung nach Art. 4 Nr. 5 DSGVO ist kein Anonymisierungsersatz, aber ein anerkanntes Schutzmittel. Bei Logs heisst das: ersetzen Sie Klartextfelder durch Hashes oder Tokens, und bewahren Sie das Zuordnungsmaterial getrennt und mit strengerem Zugriff auf.

Beispiel fuer eine Logstash-Pipeline, die IPv4-Adressen vor der Indexierung mit HMAC-SHA256 pseudonymisiert und gleichzeitig das letzte Oktett verwirft, falls das Pseudonym im SIEM nicht benoetigt wird:

filter {
  if [client][ip] {
    ruby {
      init => "require 'openssl'; @key = ENV['LOG_PSEUDO_KEY']"
      code => "
        ip = event.get('[client][ip]')
        digest = OpenSSL::HMAC.hexdigest('SHA256', @key, ip)
        event.set('[client][ip_pseudo]', digest[0,16])
        event.remove('[client][ip]')
      "
    }
  }
  mutate {
    remove_field => [ "[http][request][body]", "[user][email]" ]
  }
}

Der Schluessel LOG_PSEUDO_KEY liegt nur im Vault Ihres Logstash-Hosts, nicht im Repository und nicht in den Logs selbst. Bei Bedarf — etwa fuer eine forensische Auswertung — kann der zugriffsberechtigte Personenkreis aus einem bekannten IP-Bereich die Pseudonyme nachrechnen, ohne dass die rohen IPs jemals in Elasticsearch landen. Dieses Vorgehen ist 2026 von mehreren Landesdatenschutzbehoerden ausdruecklich als Best Practice genannt worden.

ELK und Loki praxisnah konfigurieren

Bei einer ELK-Stack-Architektur (Elasticsearch 8.17, Logstash 8.17, Kibana) empfehlen wir 2026:

• Trennen Sie Indices nach Zweck und Aufbewahrung: security-*, audit-*, app-debug-*. Pro Zweck eine ILM-Policy mit klarer delete-Phase.
• Rollenbasierte Zugriffe (RBAC) in Kibana — Helpdesk sieht keine Auth-Logs, Security sieht keine App-Debuglogs ohne Anlass.
• Field-Level-Security: Felder mit Restpersonenbezug nur fuer eine explizite Auditor-Rolle.
• Audit-Logs der Logging-Plattform selbst aktivieren — wer hat wann welche Query gestellt?
• TLS zwischen Beats, Logstash und Elasticsearch ist Pflicht, nicht Option.

Bei Grafana Loki 3.x ist die Logik anders, weil Loki nur Labels indexiert und Inhalte komprimiert speichert. Halten Sie Labels frei von personenbezogenen Daten — niemals user=mueller@kunde.de als Label, sondern als Logline. Setzen Sie retention_period pro Tenant, nutzen Sie retention_stream fuer abweichende Pfade (z. B. 12 Monate fuer job=auth, 14 Tage fuer job=app), und vergessen Sie die Compactor-Konfiguration nicht — ohne ihn werden alte Chunks zwar markiert, aber nicht entfernt.

Bei beiden Stacks gilt: ein zentrales Konzept-Dokument, das pro Logquelle Rechtsgrundlage, Zweck, Felder, Aufbewahrung und Loeschmechanismus benennt. Ohne dieses Dokument ist die technisch beste Loesung im Audit wertlos.

Typische Fallstricke aus Audits

Aus unseren Projekten und Audits 2025/2026 sehen wir immer wieder die gleichen Probleme: Backups der Logserver, die nie geloescht werden und damit die Retention aushebeln; Debuglogs in Containerumgebungen, die ueber stdout ohne Filterung in den Logstack fliessen; Webhooks und Third-Party-Tools (Sentry, externe APMs), die personenbezogene Daten in EU-fremde Regionen abfliessen lassen; Admin-Mailboxen, in denen Alarm-Mails mit kompletten Logzeilen jahrelang liegen.

Ein praktischer Stresstest: Loeschen Sie probehalber einen Testbenutzer komplett aus Ihrem System. Dauert es weniger als 90 Tage, bis auch in den Logs nichts mehr ueber ihn zu finden ist? Falls nein, ist Ihre Retention nicht durchsetzbar implementiert.

Fazit

DSGVO-Logging 2026 ist beherrschbar, wenn man es als zweidimensionales Problem versteht: was muss rein, und was darf nicht rein. Pflicht-Logs fuer Authentifizierung, privilegierte Aktionen und Datenzugriffe; harte Tabus bei Mailbodies, Formularinhalten und Tracking-Parametern; technisch erzwungene Retention zwischen 7 Tagen und 12 Monaten je nach Logtyp; konsequente Pseudonymisierung in der Pipeline, nicht erst im Dashboard. Wer das sauber aufsetzt, bekommt nicht nur DSGVO-Konformitaet, sondern auch ein deutlich nuetzlicheres SIEM.

DATAZONE unterstuetzt mittelstaendische Unternehmen in Neuburg, Ingolstadt und ganz Bayern beim Aufbau DSGVO-konformer Logging- und SIEM-Architekturen — von der Konzeption ueber den Linux-Betrieb des ELK- oder Loki-Stacks bis zur Anbindung von OPNsense-Firewalls und Backup-Systemen. Sprechen Sie uns an unter datazone.de/kontakt — wir auditieren auch bestehende Setups und liefern eine priorisierte Mangelliste mit klarem Umsetzungspfad.