Logging is where data escapes systems

I'm confident that most well-designed systems handle personal data reasonably well at the primary layer. Records live in defined tables, governed by schemas, subject to retention logic that reflects actual business decisions. You can query it, delete from it, and reason about it.

Logging, however, undoes most of that and not through negligence, but through the way observability systems are built and the defaults they ship with. By the time the problem surfaces, the data has already been somewhere you did not intend.

How the second lifecycle starts

When a request arrives, the instinct is to log enough context to debug it later. You start with request IDs and status codes. You add user identifiers because they make support cases easier to trace. You include parts of the request payload because they help reproduce edge cases. An error fires and the full context goes with it - i.e. whatever was in scope at the time. Each step is individually reasonable, and none of them feels like a data protection decision.

But consider what happens downstream. Your observability pipeline picks up those log entries and forwards them to your log management platform. That platform retains them for 90 days by default, or 365, or indefinitely, because no one changed the default at setup. If you are using a platform with a US-based primary region, that data has also crossed a border without a deliberate transfer decision. If you configured log forwarding to a SIEM or an analytics tool, the same data now exists in a third location under its own retention schedule.

You did not decide any of that. You configured a logger. The rest followed from defaults.

The data now exists in parallel. The primary copy follows the lifecycle you designed: structured, deletable, governed by your retention rules. The log copies follow a different one: less structured, retained under operational defaults, spread across systems that were never part of your data model. These two lifecycles diverge over time, and the gap between them is where most real compliance problems originate.

Where it surfaces

The divergence is invisible until the system is required to act on data in a controlled way. Deletion is the clearest test.

A user submits an erasure request. You remove their record from the primary database. Then someone asks whether the data is actually gone. Their email address is in request logs written six months ago. Their user ID appears in error traces across three services. Their session activity sits in a forwarded event stream retained by a third-party platform on a 12-month default. Your log management platform does not support row-level deletion. You open a support ticket and wait, while the clock on your 30-day response obligation runs.

Retention exposes the same failure from a different angle. You apply a 90-day retention rule to your primary database and consider it handled. Your log drain runs on the platform default of 12 months. The same data now has two retention periods, applied independently, with nothing enforcing consistency between them. If you are ever required to demonstrate that data was deleted within the period you documented, you cannot: because the documentation describes your database, not your system.

The decisions that matter

Define a field allowlist before instrumentation begins.

The default behaviour of most logging libraries is to capture everything in scope. That default will produce personal data in logs. The only reliable fix is to decide upfront what a log entry is permitted to contain, not as a filtering exercise after the fact, but as a constraint applied from the start at the library configuration level.

For most systems, the allowlist is short. Timestamps, request IDs, service identifiers, HTTP methods, status codes, response times, structured error codes. User IDs, email addresses, IP addresses in untruncated form, session tokens, and any fragment of user-supplied input do not belong on that list without an explicit documented reason. If a field is not on the allowlist, it does not appear in logs. One decision, applied everywhere, requires no ongoing discipline to maintain.

Replace user identifiers with correlation IDs.

If you need to trace a request across services (and you do) you do not need a user identifier in every log line. Generate a random correlation ID at the edge and propagate it through the call chain. You get full end-to-end traceability without linking any log entry back to an individual. When you need to reconstruct which user a correlation ID maps to, that mapping lives in your primary data store under its own retention and deletion rules. Logs stay operationally useful. The sensitivity classification of your log data drops significantly, and erasure requests stop being a multi-system archaeology exercise.

Treat log levels as data boundaries.

DEBUG logs are for development and should not run in production. When they do, they contain everything: variable state, raw inputs, whatever was convenient to attach at the time. INFO logs should record that something happened, not the content of what happened. ERROR and WARN logs require the most scrutiny because error conditions are precisely where sensitive input is most likely to surface: the payload that triggered a validation failure, the request body that caused a crash. Define what each level is permitted to contain as a written policy and enforce it in code review. Conventions erode under deadline pressure; a reviewable policy does not.

Set retention periods per log destination, not per service.

For each log destination in your system (primary drain, forwarded streams, SIEM integrations, analytics tools) set an explicit retention period tied to a documented purpose. Operational debugging logs rarely need more than 30 days. Security event logs may warrant longer retention, but that requires a purpose and a legal basis, not a default left in place from initial setup. Where your platform does not support automatic deletion at the record level, that is a gap to evaluate during vendor selection, not a constraint to absorb silently.

Map your log management platform as a data processor.

If your logs contain personal data - even incidentally - your log management platform is processing it on your behalf. That requires a Data Processing Agreement, an understanding of where data is stored geographically, visibility into their sub-processor chain, and confirmation that their DPA is compatible with your own customer commitments. For systems operating under sector-specific regulation, the platform's standard click-through DPA will often not be sufficient without negotiation.

Data residency is a specific and common gap here. Most major platforms offer EU regions but do not default to them. Where your logs are actually stored is a configuration question with a legal consequence: an unverified assumption about EU residency is one of the easiest compliance failures to avoid and one of the most frequently missed.

Defaults are the policy

If your system logs full request payloads, retains them on platform defaults, and forwards them without defined boundaries, that is your data processing policy - regardless of what your privacy notice says. The decisions that shape how your logging system actually behaves are made when you configure your first drain, write your first handler, and set a retention period or leave the default in place.

Logging is the most common place a well-designed primary data model breaks down. It does not require a mistake. It requires only that observability was treated as an engineering concern and data lifecycle as someone else's (and that no one owned the overlap).

Why all this? Apart from the legal reasoning, there is one other aspect: the system that runs when no one is paying attention is the system that gets audited. Believe me, I don't audit the flashy new thing - I dig into the legacy system, the untouched piece of kit everyone calls reliable. Because that is where the problems are.