Data minimisation as a schema and logging discipline

What it is

Data minimisation is the engineering habit of storing only the personal data a feature needs, at the coarsest precision that serves the purpose, for no longer than the purpose lasts. It shows up in three places: the schema (which columns exist and how precise they are), the logs (which fields are emitted), and the derived stores (analytics, search indexes, caches) that copy from both. NIST SP 800-122 frames the later task as identifying PII in a system and deciding what level of protection is appropriate for each instance; minimisation is the step before that, which avoids creating the instance at all. The OWASP Logging Cheat Sheet lists data that should not be recorded directly in logs but removed, masked, hashed or encrypted, among them session identification values, access tokens, passwords, payment card data and sensitive personal data.

Why it matters

Every stored field is a liability with running costs: it has to be protected, exported on request, deleted at the end of its retention, and explained after an incident. A field that was never stored costs nothing. Logs are the usual leak path because they are written by every layer, copied to several systems and read by more people than the database is.

How to apply

• Ask per column at schema review: which feature reads it, at what precision, for how long? Store the year of birth when only an age bracket is used, a region instead of a full address, a boolean "has phone number" when only the fact matters.
• Split rarely needed sensitive columns into their own table with stricter access, so that the common joins never touch them.
• Log by allowlist: the structured-logging helper accepts named fields and drops everything else; a free-text message never receives a request body or a user object dumped with %r or JSON.stringify.
• Replace identifiers in logs with stable pseudonyms (a keyed hash) where correlation is needed and with nothing where it is not.
• Give derived stores the same rules: the analytics event schema lists allowed fields and rejects unknown ones at ingest.
• Tag columns and log fields with a classification (personal, sensitive, none) in the schema definition, so that later tooling for export, deletion and review can find them.

Pitfalls

Minimisation decided at design time erodes through "temporary" debug logging left in place, JSON columns that accept any key, and third-party SDKs that collect on their own. Coarsened data can still identify in combination (year of birth plus region plus gender); coarsening is a reduction, not anonymisation. A field removed from the schema still exists in old backups and in the log archive until those expire.