Treat logs as a data store that can hold personal data. First log less, then replace identifiers with internal IDs, then mask what remains at the logger, and finally restrict access and set a deletion period. Doing these in order removes most of the risk before you reach the expensive controls.
Step one: do not log it
The cheapest control is never writing the value. OWASP says not to log anything unless it is legally sanctioned, and to remove, mask, hash or encrypt items such as session IDs, access tokens, passwords, connection strings, keys and payment card data. It also asks for care with file paths, internal network names and non-sensitive personal data, and suggests considering pseudonymization.
Go through your log statements and ask of each field whether anyone has ever queried it. If not, drop it.
Step two: use internal IDs
Instead of an email address, log u_48213. Your support team can look up the person in the user system, where access is controlled and deletion requests are handled. The log line stays useful without becoming a copy of your customer table.
OWASP's vocabulary guidance makes a related point about IP addresses: they can become personal data, so weigh the value of each field against its privacy impact.
Step three: mask at the logger
People will still write something sensitive by accident. Add a filter in the shared logging wrapper that:
- drops fields with known risky names such as password, token, authorization and secret
- masks patterns such as card numbers
- limits the size of free text fields
Do this in code, close to the source. A scrubber that runs later in the pipeline protects the central store but not the local file or the copy in a crash dump.
Step four: control access and time
- Restrict who can search production logs and review that list.
- Record searches and exports.
- Give personal data containing logs a short, defined retention.
- Make sure your deletion process can reach logs, or document why the logs hold no identifiable data.
Step five: handle requests and incidents
If a person asks for their data to be deleted, you need to know whether logs are in scope. The honest answer depends on what the logs contain, which is why the earlier steps matter. If you have kept only internal IDs, document that and explain how the ID maps back, and when the mapping is deleted.
Test with a canary
Create a test account with a distinctive fake name and email, use the product, then search every log store for those strings. Anything you find is a leak to fix. Repeat after major releases.
Quick check
Is hashing an email enough?
Often not. An unsalted hash of a guessable value can be reversed by trying candidates. Prefer a random internal ID.
Should security logs hold usernames?
They usually need an actor identifier. Use an internal ID and keep the mapping under tighter control.
Sources
Related: what never to log.
Last reviewed: 19 October 2026.
