GDPR-Compliant Logging:
What You Can and Can't Log
Most application logs are quietly non-compliant. Here's the practical developer guide to fixing that without killing your ability to debug.
Every time your application writes a line to a log file, it's potentially creating a GDPR record. IP addresses, email addresses, user IDs, session tokens — all of it is personal data under EU law. Most development teams don't think about this until an audit, a breach, or a subject access request lands in their inbox.
This guide gives you a practical, developer-focused breakdown of GDPR's logging requirements — what you can log lawfully, what you need to strip out or pseudonymise, how long you can keep it, and what to do when things go wrong.
Why Logs Are a GDPR Problem
GDPR defines personal data as any information relating to an identified or identifiable natural person. In practice, this means your logs almost certainly contain personal data:
The Legal Basis for Logging
You can't log personal data without a lawful basis. For most application logs, developers rely on one of two:
Legitimate Interests (Article 6(1)(f)) — the most commonly used basis for operational and security logging. To rely on it you must pass a three-part test: the interest must be legitimate (security monitoring is), necessary (you can't achieve it without the data), and balanced against the individual's rights (which means using minimum data, short retention, and no unexpected uses).
Legal Obligation (Article 6(1)(c)) — applies when you're required by law to keep audit logs. Financial services, healthcare, and critical infrastructure sectors often have statutory logging requirements that override GDPR's data minimisation principle.
Consent Is Not the Right Basis for Logging
Many developers assume they can rely on user consent to log personal data. In practice, consent is almost never valid for operational logging — users cannot meaningfully refuse logging that's integral to the service, making any consent non-freely-given and therefore invalid under GDPR.
The Data Minimisation Principle in Practice
Article 5(1)(c) requires you to collect only data that is "adequate, relevant and limited to what is necessary." Applied to logging, this means asking one question before every log line: do I actually need this field to achieve my operational purpose?
In most cases, you don't need the full email to log a failed login — you need to know that a login failed, from which IP, at what time. The specific email only matters if you're doing per-user rate limiting or fraud detection, in which case you should log a hash of the email, not the plaintext.
| What You're Logging | What to Log Instead | Rationale |
|---|---|---|
| alice@example.com | sha256(email) or user_id | Identifies the account without exposing the address |
| 192.168.0.105 | 192.168.0.0/24 or hash | Preserves subnet-level info for geo/security without individual identification |
| Bearer eyJhbGci... | [JWT_REDACTED] | A valid JWT is functionally a credential — never log it |
| POST /users {"name":"Alice","dob":"1990-01-01"} | POST /users {fields: ["name","dob"]} | Log the structure, not the values |
| SQL: SELECT * FROM users WHERE email='alice@...' | SQL: SELECT * FROM users WHERE email=? | Log parameterised form, strip bind values |
Log Retention: How Long Is Too Long?
GDPR's storage limitation principle (Article 5(1)(e)) requires personal data to be kept no longer than necessary. There's no single prescribed retention period — it depends on your purpose — but here are defensible positions most DPAs accept:
Sharing Logs with Third Parties
When you share logs with a third party — a support vendor, a monitoring SaaS, an AI assistant — that party becomes either a data processor (if they act on your instructions) or a data controller (if they use the data for their own purposes). Either way, you need:
- A Data Processing Agreement (DPA) with any processor who handles your logs
- To ensure that processor has adequate safeguards if they're outside the EEA (Standard Contractual Clauses or equivalent)
- To only share logs with personal data redacted when sharing for debugging purposes — the support team doesn't need real email addresses to fix a bug
AI Assistants as Unintended Processors
When you paste a log containing personal data into ChatGPT, Claude, or Gemini, you're sharing that data with a third-party processor — without a DPA, without a lawful basis for that specific transfer, and potentially to a recipient outside the EEA. This is a GDPR violation regardless of how helpful the debugging response is. Always sanitise logs before sharing with any AI tool.
Handling Subject Access Requests for Log Data
Under GDPR Article 15, individuals can request all personal data you hold about them — including log data. This catches many teams off guard. If your logs contain email addresses or user IDs that link back to individuals, you must be able to search and retrieve that data, provide it in a portable format within 30 days, and delete it on request (subject to legitimate grounds for retention).
The practical implication: if you can't search your logs by user ID or hashed identifier, you either need to build that capability, or stop storing identifiable log data at all. The latter is often the simpler engineering decision.
Practical Implementation Checklist
Sanitise Before You Share
Remove emails, IPs, JWTs and API keys from logs in seconds — free, client-side, nothing uploaded.
Open Log Sanitizer — Free →FAQ
Are application logs subject to GDPR? +
Yes. Any log that contains data identifying or linkable to a living individual — IP addresses, emails, user IDs — is personal data under GDPR and subject to all its requirements including lawful basis, data minimisation, retention limits, and subject access rights.
How long can I retain logs under GDPR? +
There's no fixed period — it must be proportionate to your purpose. 30–90 days is defensible for access logs, 12 months for security logs. Anything longer requires a specific documented rationale. Regulatory obligations can justify extended retention but must be documented.
Is logging an IP address a GDPR violation? +
Not inherently — but it requires a lawful basis (usually legitimate interests for security), disclosure in your privacy policy, and a defined retention period. The CJEU confirmed IP addresses are personal data even when dynamic, in Breyer v Germany.
Can I paste logs into ChatGPT under GDPR? +
Not if they contain personal data and you don't have a DPA with OpenAI covering that use. Even with a DPA, best practice is to sanitise first — the AI doesn't need real personal data to help debug a problem.