GDPR Logging Requirements 2026: What to Log and What Not To

GDPR forces you into a balancing act: on one side, you must prove security incidents and log every access to personal data without gaps. On the other side, you must not log everything that is technically possible — because every log line containing personal data is itself subject to GDPR. Since the 2025 guidance from the supervisory authorities and the consolidated DSK orientation paper of 2026, the message is clear: anyone who blindly stores “everything for a year” risks a fine — just like anyone who logs nothing at all.

This article summarises what is truly mandatory in 2026, which fields you should avoid, and how to operate an ELK or Loki stack in a GDPR-compliant way. Target audience: IT decision-makers in SMBs who run or are planning a SIEM or central log platform.

What you must log

The obligation to log follows from Art. 32 GDPR (security of processing) in combination with Art. 5(2) (accountability), as well as from the German BSI IT-Grundschutz, sector standards (TISAX, KRITIS) and — increasingly in 2026 — from NIS2. Mandatory in practice:

• Authentication events: successful and failed logins on every system holding personal data, including source IP, username, timestamp and result.
• Privileged actions: sudo, RunAs, role changes, permission modifications, user creation and deletion.
• Access to personal data: read, modify, delete, export — especially for special categories under Art. 9 (health, religion, union membership).
• Security-relevant system events: firewall blocks, IDS/IPS alerts, antivirus hits, configuration changes, patch installation.
• Data transfers: exports, backups, API calls — especially when processors or third-country transfers are involved.
• Deletion events: proof that erasure obligations under Art. 17 were actually fulfilled.

Important: this logging serves security, not behavioural monitoring of employees. That must be documented in your record of processing activities (ROPA) accordingly, and the works council must be involved on co-determined topics.

What you must not log

Equally important is the “must not”. The German DSK has explicitly named several typical violations in 2026:

• Full URLs with query strings containing tokens, session IDs or personal parameters (?email=...&token=...).
• Request bodies of forms where users enter plaintext data (contact, application or medical questionnaires).
• Full mail bodies or attachments in SMTP or MTA logs.
• Keystrokes and mouse movements (keylogging) except in narrowly scoped forensic cases with a clear legal basis.
• Chat or call content without explicit consent and notice.
• Special category data (Art. 9) may only be logged if truly unavoidable — and then strictly pseudonymized or encrypted.

Rule of thumb: log the event (“user X exported record Y”), not the content (“user X exported record Y with diagnosis Z”). Dumping entire HTTP requests including bodies into Elasticsearch out of convenience almost always creates a GDPR problem.

Retention periods 2026 — the pragmatic framework

GDPR itself sets no fixed periods. The principle is storage limitation: as long as necessary, as short as possible. The following values have become established and are accepted by supervisory authorities and auditors:

Log type	Recommended retention	Reason
Security events (auth, firewall, IDS)	90 days	Standard for incident detection and response
SIEM correlation events	6 months	Detect slow-burn attacks
Privileged access (admin, sudo)	12 months	Compliance, BSI Grundschutz, KRITIS
Access to special categories	up to 12 months	Evidence in disputes
Backup logs	30 days after the last related backup	Consistency with backup retention
Application debug logs	7-14 days	Error analysis, no security purpose
Webserver access logs (truncated)	7 days	DSK guidance, IP truncation recommended

Important: these periods must be enforced technically, not just described in a policy. Anyone who promises 90-day retention in a GDPR concept but never deletes old indices will fail in an audit. In Elasticsearch use ILM policies, in Loki set retention periods, and at the filesystem level configure logrotate properly.

Pseudonymization — when personal data is unavoidable

Pseudonymization per Art. 4(5) GDPR is not a substitute for anonymisation, but a recognised safeguard. For logs that means: replace plaintext fields with hashes or tokens, and keep the mapping material separately with stricter access control.

Example of a Logstash pipeline that pseudonymizes IPv4 addresses with HMAC-SHA256 before indexing, and at the same time drops the request body and email field:

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]" ]
  }
}

The key LOG_PSEUDO_KEY lives only in the Vault on your Logstash host, never in the repository and never in the logs themselves. If needed — for a forensic investigation — authorized staff can recompute the pseudonyms from a known IP range without raw IPs ever landing in Elasticsearch. Several German state DPAs explicitly named this approach as best practice in 2026.

Configuring ELK and Loki in practice

For an ELK stack (Elasticsearch 8.17, Logstash 8.17, Kibana) we recommend in 2026:

• Separate indices by purpose and retention: security-*, audit-*, app-debug-*. One ILM policy per purpose with a clear delete phase.
• Role-based access (RBAC) in Kibana — helpdesk should not see auth logs, security should not see app debug logs without cause.
• Field-level security: fields with residual personal context only for an explicit auditor role.
• Enable audit logs of the logging platform itself — who ran which query and when?
• TLS between Beats, Logstash and Elasticsearch is mandatory, not optional.

With Grafana Loki 3.x the logic differs because Loki indexes only labels and stores content compressed. Keep labels free of personal data — never use user=mueller@customer.com as a label, only inside the log line. Set retention_period per tenant, use retention_stream for diverging paths (e.g. 12 months for job=auth, 14 days for job=app), and do not forget the compactor — without it, old chunks are merely marked and not removed.

For both stacks: maintain a central concept document that lists, per log source, the legal basis, purpose, fields, retention and deletion mechanism. Without it, even the technically best solution is worthless in an audit.

Common pitfalls from audits

From our projects and audits in 2025/2026 we keep seeing the same problems: backups of log servers that are never deleted and thus break retention; container debug logs streamed to the log stack via stdout without filtering; webhooks and third-party tools (Sentry, external APMs) that leak personal data outside the EU; admin mailboxes piling up alert mails with full log lines for years.

A practical stress test: completely delete a test user from your system. Does it take less than 90 days until nothing about that user can be found in the logs either? If not, your retention is not enforceable.

Conclusion

GDPR logging in 2026 is manageable if you understand it as a two-dimensional problem: what must be in, and what must not be in. Mandatory logs for authentication, privileged actions and data access; hard taboos around mail bodies, form contents and tracking parameters; technically enforced retention between 7 days and 12 months by log type; consistent pseudonymization in the pipeline, not just in the dashboard. Done properly, you gain not only GDPR compliance but also a noticeably more useful SIEM.

DATAZONE supports SMBs in Neuburg, Ingolstadt and across Bavaria in building GDPR-compliant logging and SIEM architectures — from concept to Linux operations of the ELK or Loki stack and integration with OPNsense firewalls and backup systems. Get in touch at datazone.de/en/kontakt — we also audit existing setups and deliver a prioritised gap list with a clear implementation path.