Data Minimization

Data minimisation is the principle that you collect and keep only the personal data actually needed for a stated purpose, and no more. It is a legal requirement under GDPR-style regimes and, independently of that, the cheapest security control available, because data you never collected cannot be breached, subpoenaed, mishandled by a vendor, or turn up in a training set. The engineering translation is a set of concrete habits. Do not add a field to a form because it might be useful later. Store a derived value where the raw one is not needed — an age band rather than a birth date, a hash rather than an identifier, a country rather than a precise location. Set a retention period per data type at the point the table is designed rather than after an audit asks, and make deletion a scheduled job rather than an intention. Redact before logging: application logs, error trackers and analytics events are where personal data most often escapes a system whose primary database was carefully designed. And apply the same rule to third parties — every field forwarded to an analytics, support or model provider widens the boundary of what has to be disclosed and protected. Minimisation has a natural tension with product analytics and with AI features that benefit from more context, and the honest resolution is not to pretend otherwise but to make the trade-off explicit per field: what decision does this data support, who can see it, and when does it expire. Fields that cannot answer those three questions are the ones to drop.