Personally Identifiable Information in Logs: A Cleanup Playbook
PII (personally identifiable information) in application logs refers to personal data about users or customers that is captured in log entries, including names, email addresses, phone numbers, IP addresses, location data, payment information, and behavioral data that can identify individuals. Logging PII creates compliance obligations under GDPR, CCPA, and other privacy regulations, expands the data subject rights obligations (right to erasure, right of access), and creates security risk if log storage is compromised. Minimizing PII in logs requires auditing existing log content and implementing filtering in the log pipeline.
Written by Yashveer Singh, founder of Yashveer Labs.
What you need to know
- Most SaaS applications accidentally log personal data through request body logging, error message logging, and analytics event logging. An audit of a typical web application log will find user email addresses, names, and behavioral data within the first 10 minutes of searching.
- GDPR's right to erasure applies to data in logs. An application that cannot delete a user's email from application logs when the user requests erasure has a compliance gap.
- An allowlist approach to logging (log only explicitly approved fields) is more reliable than a blocklist approach (remove known sensitive fields). New fields are sensitive by default until approved.
- Log retention periods should be defined per log type. Security logs can warrant longer retention; application debugging logs typically do not need to be kept beyond 30 days.
- The highest-risk log content is in request body logging, error stack traces (which often include user input), and application-layer analytics that track user behavior with identifiers.
The core argument
The PII-in-logs problem is almost always accidental rather than intentional. Engineers add request body logging for debugging, an error handler logs the full request context including user-provided content, a new feature logs analytics events that include user identifiers. Each individual decision seems reasonable; the cumulative result is a log system that contains more personal data than the privacy policy describes and more than compliance requires.
The cleanup requires three separate interventions: an audit of what is currently in the logs, a remediation of the existing log content (or at minimum, a rotation policy that removes it over time), and a prevention mechanism that stops new PII from entering the logging pipeline. The audit phase is often the most uncomfortable: it reveals the scope of the problem, and the scope is usually larger than expected. In my experience reviewing application logs for compliance, the typical startup web application has user email addresses in authentication logs, user names and input in error stack traces, and full request bodies (including personal data in form submissions) in debug logs. Each of these has a compliance implication under GDPR and CCPA.
The prevention mechanism is the most important long-term intervention. A cleanup that does not prevent new PII from entering the logs will need to be repeated. The most reliable prevention is a logging middleware that filters fields at the source: log each request and response with a set of approved fields, redact everything else. This middleware runs on every request and ensures that new fields added to request or response objects do not automatically appear in logs unless explicitly approved.
Common mistakes
- Enabling request body logging without field filtering. Full request body logging captures passwords, payment card data, personal information in form submissions, and user-provided content. The fix is selective body logging: log specific fields that are known to be safe (request method, URL, status code, duration) rather than the full body.
- Including personal data in error messages. Error messages that read "User john@example.com failed authentication at 14:32:01" contain email addresses that appear in error logs. Error messages should use user IDs (non-identifying internal identifiers) rather than email addresses or names.
- Not applying retention policies to existing log archives. Setting a 30-day retention policy for new logs without deleting existing archives means that years of personal data may remain in storage. Define the retention policy and apply it retroactively to existing archives as part of the cleanup.
- Logging analytics events with user identifiers in server logs. Analytics events that track user behavior (page views, feature usage, workflow completions) with user email addresses or names in server logs create a detailed personal data profile in log form. Use pseudonymous identifiers (user IDs) for analytics events in server logs and reserve email addresses for communications systems.
- Not documenting what data is logged for privacy policy compliance. A privacy policy that does not accurately describe the personal data collected in logs is a compliance gap. The data retention section of the privacy policy should describe what types of personal data appear in logs and for how long they are retained.
Where to start
- Audit a sample of recent application logs for PII. Export 24 hours of application logs and search for patterns matching email addresses, phone number formats, and known PII field names. The search results reveal the current PII exposure and identify which log sources are the highest-priority cleanup targets.
- Implement a logging middleware that filters sensitive field names. Create a list of field names that should never appear in logs (email, password, credit_card_number, phone, social_security_number). Add a middleware that strips these fields from all log entries at the source. Deploy and verify that the removed fields no longer appear in new logs.
- Define and implement log retention policies by log type. Define the retention period for each log type (authentication logs, application debug logs, security audit logs). Configure the log storage system to enforce automatic deletion at the defined period. Document the retention periods in the data retention policy.
Related reading
Frequently asked
The reason my name is on this page
My name is on this page because I wrote what is on this page. Yashveer Singh. Full stack developer. Founder of Yashveer Labs. The portfolio is on the homepage. The projects are live. The code is real. The work is provable. If you have read this far, you already know whether the voice matches the standard you are looking for. The next move is yours.
Posts that line up with this one.
- Security, Auth, and Compliance
How to Sell to Enterprise Without a Full Compliance Stack
You do not need SOC 2 Type II and HIPAA certification before your first enterprise conversation. Here is what you actually need and how to close the deals while you build toward the rest.
- Security, Auth, and Compliance
Incident Response for Startups: A Playbook
A startup does not need an enterprise incident response program. It needs a simple, documented process that prevents the chaos that happens when something breaks at 2am and nobody knows who does what.
- Security, Auth, and Compliance
Insecure Direct Object References: The Bug Founders Underestimate
IDOR vulnerabilities let attackers access other users' data by changing an ID in a URL or API request. They are simple to introduce and expensive to miss. Here is how to find and prevent them.
- Security, Auth, and Compliance
ISO 27001 for Engineering Founders: A Practical Reading
ISO 27001 looks like a compliance bureaucracy but reads like an operational checklist for running a secure organization. Here is what engineering founders actually need to understand before starting the certification process.