To keep personal data out of logs, log only what an investigation or audit needs, replace direct identifiers with stable pseudonymous IDs, mask or drop sensitive fields before they reach storage, restrict who can read logs, and expire them on a schedule. Logs are data stores and deserve the same care as databases.
How personal data gets in
Nobody plans to log it. It slips in through:
- Request bodies and query strings dumped for debugging.
- Error messages that include the failing record.
- Usernames typed into password fields.
- Email addresses used as account IDs.
- IP addresses and device identifiers, which may count as personal data in some jurisdictions.
- Third party SDKs that log their own payloads.
The OWASP Logging Cheat Sheet has two lines worth quoting. It suggests pseudonymization where identity is not required, and says to "Never log data unless it is legally sanctioned." It also lists things to remove, mask, hash or encrypt before logging: session identifiers, access tokens, passwords, keys, connection strings and payment card data.
Five habits
1. Minimize at the source. Decide field by field whether the log needs it. A user ID answers most security questions. The email address rarely adds anything.
2. Pseudonymize. Log a stable ID that maps to the person in a separate, access controlled system. Investigators can look up the person when they must. Everyone else sees an ID.
3. Redact in the pipeline. Source code is not always under your control. A collector stage can delete unlisted attributes and mask patterns. OpenTelemetry's collector, for example, offers a redaction processor that deletes attributes not on an allowed list and masks values matching blocked patterns, as covered in OpenTelemetry collector redaction.
4. Control access. Role based access to logs, reviewed periodically, with access to logs itself logged.
5. Expire. Set retention by purpose. Security events may need longer. Debug payloads should vanish quickly. See log tiers and retention.
A tension to manage honestly
Security wants logs long and detailed. Privacy wants them short and thin. The workable middle is rich security events with pseudonymous IDs, short life for anything verbose, and a documented rationale. Involve your privacy lead early and write the reasoning down.
Subject requests and deletion
If a person asks you to delete their data, you need to know where it lives. Logs full of direct identifiers make that hard. Pseudonymous IDs make it tractable, because you can delete the mapping. Check with counsel how your obligations apply to logs and backups. This post is general information, not legal advice.
A quick scan
Search a day of production logs for email address patterns, phone number patterns and long digit strings. The first run is usually humbling. Fix the top three sources.
Quick check
Is an IP address personal data?
In some legal regimes it can be. Treat it as potentially personal, log it when you need it for security, and keep it only as long as justified.
Does hashing an email make it anonymous?
Not necessarily. Hashes of guessable values can be reversed by trying candidates. Use a keyed hash or a random ID with a protected mapping.
Sources
Last reviewed: 19 October 2026.
