Data Minimization

Signup forms used to be long. A service that needed a name and an email would also ask for date of birth, gender, home address and job title. Ask the people who built the form why, and the answer was always some version of the same thing: we might need it later, and we're asking once anyway.

In planning meetings that reasoning passed without resistance. "Let's take gender too, marketing may want to segment on it someday" had nothing to argue against, because collecting a field looked free. Three years on, the member table at a company like that held half a dozen columns no query had ever read.

The cost showed up all at once on the day of an incident. A breach that could have leaked only email addresses leaks dates of birth and home addresses along with them, and fields nobody ever used widen the harm the affected people have to deal with afterward. A leaked email address costs someone a wave of spam; a leaked date of birth and address feed identity fraud that follows them for years. Data minimization inverts the question that produced those columns. Instead of asking whether a field may be collected, it asks what stops working without it — and a field with no answer doesn't get collected at all.

Start by attaching a purpose to each field and deleting the fields that no purpose will attach to. There are four steps.

1. Write the purposes first. Account identification, billing, handling support requests — each reason the service touches personal data, written as a sentence. Start from a field and a purpose can be invented to justify it, so the direction is deliberately reversed.
2. List what each purpose needs. Billing pulls in card details and a billing address. Account identification ends at an email address. Written out this way, the list is usually shorter than the form that already exists, and the gap between the two is the work.
3. Drop every field no purpose claimed. Look past the signup form at the records the server writes and the values sent to analytics tools. Removing a field from the form alone leaves it accumulating out of sight.
4. Attach a retention period to what survives. How long you hold a field is part of how much you collect, and a field with no expiry set stays forever by default.

When a field can't be dropped outright, reduce its precision instead. Take an age bracket rather than a date of birth, a city and district rather than exact coordinates, a truncated address rather than the full one in access logs. Looking at usage patterns by age group doesn't need "March 12, 1994" — "thirties" carries the same analysis while carrying much less power to identify one person if it leaks.

It applies at every point where personal data enters the company or leaves it. Five places come up most in practice.

1. Signup and checkout forms. The line between required and optional consent items is drawn by this principle. Marking a field required when the service works fine without it stays a problem even with consent collected.
2. Analytics event design. Recording which button was clicked and attaching the user's email address to the event is a common habit. Personally identifiable information (PII) is any value that can pin down one person, and once it has followed an event into a third-party tool it is far harder to pull back.
3. Server logs. Dumping whole request bodies to trace an error sweeps phone numbers and addresses in with them, so choosing what to record is an engineering decision too.
4. Fields handed to outside parties. What goes to a data processor is limited to what that work needs, and a vendor assessment is where you check the actual list against the intended one.
5. Public documents. The privacy policy states the collected fields outright. A field with no defensible purpose produces no sentence to write there, which is why writing the policy is often what finally removes it.

"What's the purpose of this field? Give me one line I can put in the privacy policy verbatim."

If the purpose can't be written as a sentence, the field shouldn't be collected.

"Could we take an age bracket instead of a full date of birth?"

Keep the analysis, lower the identifying power.

"Don't put the whole email on the event — send the account number."

Cut the path that carries personal data into the analytics tool.

Pagedeck revisited its signup form when it started selling to companies. Grace was working through a security review that required submitting the list of collected fields, and that review surfaced the fact that company size and job title had never been used. Both had gone in two years earlier because sales asked to have them on hand.

Mia checked the query history before deleting either one. Only after confirming that no query read those columns did she remove them from the form and clear the values already stored. When Ravi later said job title would help with enterprise analysis, the team decided to ask the specific accounts that mattered rather than reinstate the field. Collecting from everyone to serve a few is exactly the shape they had just undone. The form went from eleven fields to six, and the signup completion rate went up slightly as a side effect nobody had planned for.

People read minimization as a rule against analysis. Anyone working with data feels safer keeping everything, since there's no telling which question arrives next and a deleted field can't be recovered. But what the principle blocks is purposeless collection, not purposeful collection. State that you intend to look at usage patterns by age group and you can collect what that needs.

Ignoring it brings two consequences. One is that a breach releases more fields than it had to. The other is that nobody can answer a right to erasure request with confidence, because fields collected without a purpose are rarely tracked as they get copied around. Delete the row in the member table and the same person's values are still sitting in the analytics tool and in last month's backup. Fewer fields collected at the start means fewer places to chase on the day the request arrives.