GDPR Compliant Log Retention on Linux: Implementing Deadlines Technically

1. GDPR and server logs: what counts as personal data

GDPR log retention starts with an often underestimated observation: practically every server log on a Linux system contains personal data. IP addresses count as personal data under the consistent view of courts and supervisory authorities, as soon as the operator is theoretically able to establish identifiability with reasonable effort, for instance via the provider. That means web server logs, SSH logs and application logs fully fall under the GDPR regime.

For GDPR log retention this concretely means: storage, processing and eventual deletion of these logs must follow a legal basis under Article 6 GDPR, usually the legitimate interest in IT security and error analysis. This legal basis does not carry indefinitely, only for a retention period appropriate to the purpose. Unlimited retention "just in case" contradicts the storage limitation principle in Article 5(1)(e) GDPR.

Important for the technical implementation of GDPR log retention is the distinction between operational logs for debugging and monitoring on one hand, and security relevant logs for incident response on the other. Both categories typically have different, individually justifiable retention periods, which should be mapped separately in the logrotate and retention configuration.

2. Legal bases and retention periods for access logs

The GDPR itself does not name a concrete number of days for GDPR log retention of server access logs. Instead, the principle applies that the period must be measured against the actual purpose. In practice, and according to guidance from German supervisory authorities, seven to fourteen days has become common for pure web server access logs, unless a concrete security incident justifies longer retention.

For security relevant logs such as auditd records, failed login attempts or firewall logs, a longer period of several months up to a year is regularly justifiable, because the legitimate interest in investigating security incidents justifies more extensive retention. What is decisive for any GDPR log retention is to set these periods in advance, document them, and then enforce them technically and consistently, instead of letting logs grow indefinitely.

#!/usr/bin/env bash
# Audit current log retention across common Linux log sources
set -euo pipefail

echo "== Nginx/Apache access log rotation config =="
grep -A2 "access.log" /etc/logrotate.d/nginx 2>/dev/null || echo "No explicit rotation found"

echo "== journald retention policy =="
grep -E '^(MaxRetentionSec|SystemMaxUse)' /etc/systemd/journald.conf

echo "== Oldest log entries currently on disk =="
find /var/log -name "*.log*" -printf '%T+ %p\n' 2>/dev/null | sort | head -5

3. Implementing logrotate and retention policies technically

The simplest technical foundation for GDPR log retention on Linux is logrotate, because it combines rotation, compression and automatic deletion after a defined number of cycles in a single configuration file. The decisive parameter is maxage, which enforces, independent of file size, that log files are actually deleted after a fixed number of days rather than simply being rotated indefinitely.

A common configuration mistake in GDPR log retention is setting rotate without maxage. The number under rotate only specifies the number of retained rotation files, not the time span. With very low log volume, rotation over twenty cycles could theoretically hold months or years of data without this being obvious at first glance. maxage reliably closes this gap.

# /etc/logrotate.d/nginx-dsgvo
# GDPR compliant retention: rotate daily, delete after 14 days regardless of count

/var/log/nginx/access.log {
    daily
    rotate 14
    maxage 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        systemctl reload nginx > /dev/null 2>&1 || true
    endscript
}

# Security relevant logs: longer retention justified by legitimate interest
/var/log/auth.log {
    weekly
    rotate 26
    maxage 180
    compress
    delaycompress
    missingok
}

4. Pseudonymization and IP truncation in logs

A central technical building block of any GDPR log retention is pseudonymizing IP addresses directly when the log is written, instead of storing them in plain text for the entire retention period. The most common method is IP truncation: for IPv4 the last octet is removed, for IPv6 the last 80 bits. This method is explicitly recognized by German supervisory authorities as a privacy friendly practice.

Alternatively, cryptographic pseudonymization with a secret salt and hash function can be used when analysis purposes require unique but not directly attributable recognition of the same IP across multiple log entries, for instance to detect brute force patterns. For GDPR log retention the rule is: the earlier in the processing pipeline pseudonymization happens, the lower the risk that unpseudonymized raw data accidentally remains beyond the regular period.

#!/usr/bin/env bash
# Anonymize IPv4 last octet and IPv6 last 80 bits in an existing access log
set -euo pipefail

INPUT="/var/log/nginx/access.log"
OUTPUT="/var/log/nginx/access-anonymized.log"

awk '{
  ip = $1
  if (ip ~ /^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$/) {
    n = split(ip, octets, ".")
    ip = octets[1] "." octets[2] "." octets[3] ".0"
  } else if (ip ~ /:/) {
    split(ip, groups, ":")
    ip = groups[1] ":" groups[2] ":" groups[3] "::0"
  }
  $1 = ip
  print
}' "$INPUT" > "$OUTPUT"

echo "Anonymized log written to $OUTPUT"

5. Securing centralized logging with rsyslog/journald

Once logs are collected centrally, for instance via rsyslog to a central log server, GDPR log retention becomes additionally complex because transmission and access control on the central system must also be considered. Encrypted transmission via TLS between the source system and the log server is mandatory as soon as personal data leaves the local system, because otherwise an additional risk of unauthorized access arises.

Access control on centrally collected logs must follow the principle of data minimization: only people with an actual operational need, for instance incident response owners, should have access to unpseudonymized raw data. A four eyes principle, or at least a logged access control on the central log server, significantly supports the accountability of GDPR log retention toward the supervisory authority.

6. Deletion concepts and automated log destruction

A written deletion concept is essential for solid GDPR log retention and should record for every log category: which log type, which retention period, which legal basis, which technical deletion mechanism and who is responsible for deletion. The technical implementation should be automated, because manual deletion is experience shows forgotten once the original occasion fades from memory.

# ansible/roles/gdpr-log-retention/tasks/main.yml
# Enforce documented GDPR retention periods per log category

- name: Deploy retention config for standard access logs (14 days)
  template:
    src: logrotate-access.j2
    dest: /etc/logrotate.d/access-dsgvo
  vars:
    max_age_days: 14

- name: Deploy retention config for security relevant logs (180 days)
  template:
    src: logrotate-security.j2
    dest: /etc/logrotate.d/security-dsgvo
  vars:
    max_age_days: 180

- name: Verify no log file exceeds the documented retention window
  find:
    paths: /var/log
    age: 190d
    recurse: yes
  register: overdue_logs

- name: Alert if logs beyond documented retention are found
  debug:
    msg: "GDPR retention violation: {{ overdue_logs.files | map(attribute='path') | list }}"
  when: overdue_logs.matched > 0

7. Right of access: making relevant log entries findable

Article 15 GDPR grants data subjects a right of access to stored personal data, which also applies to log entries, unless identifiability has been sufficiently mitigated through pseudonymization. For GDPR log retention this means a server operator must theoretically be able to locate log entries for a specific IP address within a reasonable time frame.

In practice this requirement is largely mitigated by the short retention period itself: if raw data is only kept for fourteen days and pseudonymized or deleted afterward, the scope of possible access requests is significantly reduced. Central search tools such as journalctl with a time filter, or grep across rotated but not yet deleted logs, are sufficient for most practical access requests within that period.

8. Documentation obligations and the record of processing

Article 30 GDPR requires a record of processing activities, in which GDPR log retention also belongs as its own processing activity. The entry should include the purpose of processing, categories of affected data, retention period, legal basis and technical and organizational measures such as encryption and access control.

{
  "processing_activity": "Server access logging (web server, SSH, application)",
  "purpose": "IT security, error analysis, abuse detection",
  "legal_basis": "Art. 6(1)(f) GDPR (legitimate interest)",
  "categories_of_data": ["IP address", "timestamp", "requested URL", "user agent"],
  "retention_period": {
    "standard_access_logs": "14 days, then deletion",
    "security_relevant_logs": "180 days, then deletion"
  },
  "technical_measures": ["IP truncation on write", "TLS transmission to central log server", "automated deletion via logrotate maxage"],
  "responsible": "IT operations",
  "last_reviewed": "2026-07-30"
}

9. Retention periods compared

The table below maps common log types to typical GDPR log retention, as derived from practice and guidance from supervisory authorities.

The last row of the table shows an important exception: not every longer retention violates GDPR log retention, when a separate statutory retention obligation applies, such as for tax relevant data. What matters is keeping these categories technically and organizationally clearly separated from ordinary short term access logs.

10. Summary

Legally sound GDPR log retention on Linux starts with recognizing that IP addresses and other log contents are personal data, followed by clearly defined, documented retention periods per log category. logrotate with the maxage parameter enforces these periods technically and reliably, while IP truncation or cryptographic pseudonymization reduces risk during the retention period itself.

Centralized logging additionally requires encrypted transmission and restrictive access control, while a written deletion concept and an up to date record of processing entry satisfy accountability toward the supervisory authority. Anyone combining these elements operates GDPR log retention that remains forensically useful without taking on unnecessary legal risk from excessive storage.

11. FAQ: GDPR Compliant Log Retention on Linux