Logs keep your systems observable, debuggable, and auditable — but they quietly capture personal data along the way. That makes logging one of the easiest ways to drift out of GDPR compliance without noticing. This guide walks through how to keep your logging and monitoring useful while staying on the right side of the regulation.

If you serve European customers, GDPR applies no matter where you are hosted — and logs are one of the most overlooked places personal data piles up.

Is log data personal data under GDPR?

Usually, yes. GDPR’s definition of personal data explicitly includes online identifiers such as IP addresses and cookie IDs (Recital 30), and the Court of Justice confirmed in Breyer v. Germany (2016) that even a dynamic IP address is personal data when you have a realistic means to link it to someone. That pulls everyday log data under two core principles:

• Article 5 — data minimization & storage limitation: collect only the personal data you need, and keep it only as long as you need it.
• Article 32 — security of processing: protect personal data with measures such as encryption and pseudonymization.

So a web-server access log full of IP addresses, or an error trace containing an email, is regulated personal data — not “just logs.”

It helps to think in terms of strong and weak identifiers. Strong identifiers — usernames, emails, phone numbers — point directly to a person. Weak identifiers — IP addresses, user agents, cookies, session IDs — point only indirectly, but combine enough of them and you have a strong identifier, which is exactly what regulators worry about.

Where PII leaks into your logs

PII rarely lands in logs on purpose. The usual culprits:

• Access logs (IP, user agent, requested URL)
• Application logs and a stray console.error(user)
• Error and stack traces that serialize a whole user object
• APM and observability tools — Sentry, Datadog, CloudWatch
• URLs with query parameters (?email=…, reset tokens)
• Request and response bodies captured by middleware
• Third-party log shippers that move all of the above off-site

GDPR logging and monitoring: what you must capture

GDPR also expects you to keep certain records. Article 30 requires records of processing activities, and demonstrating compliance during an audit means showing who accessed personal data, when, and why. Good audit logging captures:

• Data access — identity of the accessor, timestamp, and purpose
• Data changes — creates, updates, and deletes on personal records
• Consent events — when and how consent was given or withdrawn
• Access to the logs themselves — meta-logs, so the audit trail is itself auditable

The tension is obvious: you must record access to personal data without turning the log into another copy of it. Tokenization resolves that.

The fix: tokenize PII with Databunker Pro

Most guides tell you to mask or redact PII in your logs after the fact — brittle, because one missed field leaks. Databunker Pro takes the problem upstream: it replaces personal data in your application with opaque tokens before anything is written, so your code — and therefore your logs — only ever carry a token.

1
2
3
4
5

# Before
2026-05-25 12:01  login ok  user=john@example.com  ip=84.17.55.2

# After — PII tokenized at the source
2026-05-25 12:01  login ok  user=a1b2c3d4-…  ip=f9e8d7c6-…

• Nothing sensitive reaches your logs. Application logs, stack traces, and observability tools see tokens, not identities.
• Breaches and backups stay clean. A leaked log file or an old backup holds tokens that are useless without the vault.
• Reversal is controlled and audited. When support or security genuinely needs the real value, Pro resolves a token through its API under conditional role-based access control (CRBAC), and every lookup is recorded — giving you the Article 30 audit trail for free. See trace profile access and change.

Because tokenization is a recognised form of pseudonymization under Article 4(5), it also counts toward your Article 32 obligations — see pseudonymization vs anonymization.

Right to erasure in logs and backups

When someone exercises the right to be forgotten (Article 17), their personal data must disappear everywhere — logs, archives, and backups, not just the live database. Restoring a six-month-old backup that re-introduces a deleted user is itself a breach. This is the part most logging guides quietly skip.

With Databunker Pro the answer is simple: delete the record in the vault, and every token scattered across your logs and backups becomes inert — it no longer resolves to anything. Erasure turns into one auditable action instead of a hunt across systems. Combine it with the GDPR user request workflow to automate the request end to end.

How long should you keep logs?

GDPR sets no fixed retention period — you keep personal data only as long as the purpose requires, then delete it. In practice, teams settle on tiers:

• Operational / debug logs: roughly 30–90 days
• Security and audit records: typically 12–18 months, documented and justified
• Anything older: archived to cold storage or deleted

Whatever you choose, write it down, apply it to backups and archives as well as live systems, and review it at least annually. Collecting less in the first place makes all of this easier — see data minimization.

Other safeguards

• Encrypt logs in transit and at rest; if you must keep some PII, encrypt those fields specifically.
• Mind data residency. Shipping logs to a US service can raise Schrems II questions; an EU-hosted pipeline — or tokens instead of PII — avoids them.
• Have a lawful basis. Security and fraud logging usually rests on legitimate interest or legal obligation — record which one applies.

Look up the user behind a log entry — safely

Sooner or later someone needs to resolve the real user behind a tokenized log line — a support engineer, a downstream service, or an external auditor. Handing them PII, or a permanent token that works forever, just recreates the problem in a new place: a long-lived reference becomes a correlation key across systems, which is exactly what GDPR’s data-minimization principle pushes against.

Databunker Pro’s shared records solve this cleanly. Instead of exposing the record, you call SharedRecordCreate with the user, the specific fields actually needed, and an expiration (30m, 24h, 7d). Pro returns a single recorduuid you pass to the consumer; they read it with SharedRecordGet until it expires — after which the UUID simply stops resolving, with nothing to clean up.

That keeps log lookups minimal and accountable:

• Time-limited: access ends on its own, so a reference left in a ticket or a downstream log never becomes a permanent backdoor.
• Field-scoped: only the fields you list come back — show a support agent an email, not the whole profile.
• Audited: every create and read is recorded, and an optional partner tag attributes who you shared with — your Article 30 trail again.

See temporary record identity for the broader pattern.

Summary

Logs are personal data, and treating them casually is a common, auditable GDPR gap. Keep retention short, record access for accountability — and most importantly, tokenize PII at the source with Databunker Pro so your logs, traces, and backups never hold real identifiers, and erasure is a single vault-side delete.

Frequently asked questions

Are IP addresses personal data under GDPR? Usually yes — they are “online identifiers,” and even dynamic IPs count when they can reasonably be linked to a person (Breyer, 2016).

How long can I keep logs? As long as the purpose requires. Common practice is 30–90 days for operational logs and 12–18 months for security and audit records, documented and reviewed annually.

Does the right to be forgotten apply to logs and backups? Yes — Article 17 covers all copies, including archives and backups. Tokenizing first makes this a single vault-side delete.

What must I log for GDPR? Enough to show who accessed or changed personal data, when, and why (Article 30) — without copying the personal data itself into the log.

Further reading

For a broader survey of techniques, see how to stay GDPR-compliant with access logs on freeCodeCamp.