Privacy by design for normal people: design for minimisation, not for excuses

When a company starts collecting data about users, the first question is usually: "What are we allowed to collect?" That is a legal question and it is the right one to ask. But it is not the only question, and it is often not the most important one.

The second question - "What do we actually need in order to operate?" - gets asked far less often. Yet it determines how complex and how risky the system will be two years from now. A useful first step is mapping which data flows exist before adding any controls.

Surplus data is not a neutral asset

A common assumption: more data means more options, so collect everything and figure it out later. In practice, every extra data type is:

• one more storage location that has to be secured;
• one more dependency in the schema that has to be maintained;
• one more point of exposure in a breach or incident;
• one more thing that has to be explained to regulators or affected users.

Data collected "just in case" does not disappear. It is stored, it has access paths, it lives in backups, it can be requested or stolen. The operational debt from unnecessary data is just as real as the technical debt from unnecessary code.

What privacy by design means in practice

The term comes from Anne Cavoukian's work in the nineties and sounds academic. Stripped of the formalism, it comes down to a simple principle: decisions about data are made at the design stage, not after something has already gone wrong.

In practice this means a specific set of questions asked before the first line of code is written or the first user-facing form is built:

1. What data is needed for this feature to work?
2. How long is it needed?
3. Who inside the company needs access to it, and why?
4. What happens to the data when a user leaves?
5. What is the minimum set of data that delivers the required result?

Getting answers to these questions before development begins costs far less than reworking the data schema eighteen months later.

Minimisation as an engineering decision

Data minimisation is often seen as a constraint - something that gets in the way of building features. In practice it works the other way: a system that holds less sensitive data is simpler in architecture, simpler to audit, simpler to maintain.

Things that become easier when you hold less data:

• The database schema does not grow into a tangle without discernible structure.
• Access controls are easier to describe and enforce: fewer tables, fewer roles, fewer exceptions.
• Incident response time is shorter: you know exactly what is stored and where.
• Onboarding new employees is easier: they see precisely the data their work requires.

This is not theory. It is the difference between systems that are easy to maintain and systems that nobody wants to touch.

Justification instead of design

The opposite approach is to collect everything and then explain it. Explain to users what yet another consent checkbox means. Explain to regulators why data that is no longer needed is still being retained. Explain to yourself why an incident exposed more data than it needed to.

That is an expensive strategy - not only financially. It consumes team time, undermines user trust, and creates reputational risks that are hard to price in advance.

Three questions before you ship

Before launching any new feature or integration that touches user data, I recommend asking three questions:

1. What data are we collecting as part of this change, and why does each field exist?
2. Are there fields we could drop without losing the functionality?
3. What will happen to this data in a year - will it still be needed?

If there are no clear answers, the data design is not finished yet - even if the code is already ready to deploy.