Key takeaway: Logs are the least governed data store in most organisations — widely readable, long retained, and replicated to several platforms. Personal data reaching them inherits all of those properties.
How It Gets There
The mechanism is almost always the same. An engineer debugging an integration logs the entire request or response object because they do not know yet which field matters. It works, the bug is fixed, and the line stays.
That object contains everything the request contained: name, address, date of birth, payment details, authentication token. It is now written on every call, forever.
Other routes are equally routine. Exception handlers that dump local variables include whatever was in scope. Access logs record full URLs, and a URL with a query string carrying an email address or a token puts credentials in a file. ORM debug output logs bound parameters, which is the actual data. Third-party SDKs log request bodies at debug level, and someone enabled debug globally during an incident.
Why Logs Are Worse Than Databases
A database holding personal data has a schema, an owner, an access policy, an encryption configuration and a retention rule. Logs typically have none of those in comparable form.
| Property | Application database | Log platform |
|---|---|---|
| Documented schema | Yes | No |
| Access restricted | Yes | Broad, often engineering-wide |
| Field-level encryption | Common | Rare |
| Retention enforced | Yes | Often longest-available |
| Appears in data inventory | Yes | Frequently omitted |
| Deletion by subject | Supported | Rarely possible |
The access breadth is the immediate risk. Log platforms are deliberately searchable by many people, so personal data in logs is personal data available to everyone with a dashboard account — a population far larger than those authorised for the source system.
Deletion is the compliance failure. A subject deletion request that clears the database but not eighteen months of logs is incomplete, and log platforms generally offer no per-record deletion at all.
Preventing Rather Than Cleaning
Redaction at the ingestion layer is the only control that works reliably, because it does not depend on every developer remembering.
Use structured logging with an explicit field allowlist. Logging a named set of fields rather than an object means new fields do not silently appear in output. This is the single highest-value change available.
Add pattern-based redaction in the pipeline as a safety net for common formats — card numbers, national identifiers, email addresses, bearer tokens. Patterns are imperfect and catch the accidents that slip past discipline.
Mark sensitive fields in the type system where the language permits, so a wrapper type must be explicitly unwrapped before it can be printed. That turns an accidental disclosure into a deliberate one.
Keep debug logging out of production entirely, and if it must be enabled temporarily, bound it by time automatically rather than by intention.
Handling What Already Exists
Search existing logs for known patterns before assuming they are clean — the results are usually worse than expected. Shorten retention on log streams containing personal data, since retention is the variable that converts a small exposure into a large one. Restrict access to those streams specifically rather than to the platform as a whole. And record log platforms in the data inventory, because a store nobody has documented cannot be governed.
The Bottom Line
Log named fields rather than objects, redact by pattern at ingestion as a backstop, keep debug logging out of production, and include log platforms in your data inventory with retention short enough that an accident does not become a multi-year liability.
