Privacy by Design: Minimization, Defaults & Architecture

Privacy by Design

Privacy by design is Article 25 of GDPR — "data protection by design and by default" — and it's the only part of privacy regulation that is unambiguously an engineering discipline. The premise is simple: privacy protections built into a system's architecture cost very little, and protections bolted on afterward cost enormously and work less well.

The single most effective practice needs no framework at all: don't collect it. Data you don't hold requires no encryption, no access control, no retention policy, no deletion mechanism, no breach notification, no line in the data inventory, and no answer when a regulator asks why you have it. Every field you decline to collect eliminates every downstream obligation attached to it simultaneously. Nothing else in privacy engineering has that return.

The rest is architectural: keeping identifiers separate from the data they identify, computing on aggregates rather than individuals, storing derivations rather than raw values, and choosing defaults that protect rather than expose.

TL;DR

Minimize. The cheapest privacy control is not collecting the field.
Purpose limitation: data collected for one purpose may not be reused for another without a basis.
Privacy-protective defaults — the out-of-box setting is the private one. This is legally required.
Separate identity from data so the data store alone can't identify anyone.
Store derivations, not raw values — an age band instead of a birthdate, a region instead of coordinates.
Process locally where possible — on-device beats sending to a server.
Threat model for privacy (LINDDUN), not just for security — the adversary may be you.
Review at design time. A DPIA is hours before building and a rewrite after.

Core Concepts

The seven principles

Ann Cavoukian's original formulation, which Article 25 codified:

Principle 4 is the one worth taking seriously as an engineer: the framing that privacy trades off against utility is usually a failure of imagination. Most systems can achieve their actual purpose on far less data than they collect.

Data minimization

The is_adult pattern generalizes well. If the requirement is a boolean check, store the boolean rather than the input — you satisfy the requirement, and a breach exposes a flag instead of a birthdate that can be combined with other quasi-identifiers.

Purpose limitation

The engineering implication is that the purpose should travel with the data. Tagging datasets and columns with their collection purpose lets you enforce at query time — an analytics job reading columns collected under "order fulfilment" for a marketing purpose is a violation the schema can flag.

This is where machine learning training data most often goes wrong: a model trained on support conversations collected for "providing support" is a new purpose, and one that regulators have taken an increasing interest in.

Privacy-protective defaults

This is a legal requirement, not a design preference. "Users can turn it off" is not compliance — the default itself must be the protective one, because the overwhelming majority of users never change a default.

Architectural patterns

Separate identity from data

This pattern pays off repeatedly: it shrinks the blast radius, it makes deletion nearly trivial for the largest data stores, and it lets you grant analytics access to the application database without granting access to anyone's identity.

Store derivations, not raw values

Coarsening at collection is irreversible and free. Coarsening later doesn't help, because the precise value was already stored, backed up, and replicated.

Process locally

Privacy-enhancing technologies

These have moved from research into production — Apple and Google both deploy differential privacy at scale, and private set intersection underpins several ad-measurement products. They're worth knowing about and are not where most teams should start; minimization and separation of identity deliver more, sooner, for far less complexity.

Privacy threat modeling

Security threat modeling asks "how could an attacker get in?" Privacy threat modeling asks "how could this system harm the people in it?" — and the adversary is often the system's own operator.

LINDDUN is the standard framework:

The value of the exercise is that it surfaces harms a security review never would — a feature can be perfectly secure and still expose someone's identity to people they were hiding from.

The design review

Question 6 is the one that changes designs. Asked at the whiteboard, it routinely halves the collected fields. Asked after launch, it's a migration.

Best Practices

Justify every field, individually

At design review, each field on a form or in a schema gets a stated use. "We might need it later" is not a use. This single practice removes more data — and therefore more obligation — than any technical control.

Derive at collection and discard the input

Coarsen precise values as they arrive: age band from birthdate, region from coordinates, band from salary. Once the precise value has been stored, it's in backups and replicas and coarsening later is cosmetic.

Separate identity from behavior

A small, tightly controlled identity store keyed to opaque IDs used everywhere else. The blast radius of a breach in the large data stores drops to opaque identifiers, deletion becomes a single row, and analytics access stops implying access to identities.

Make the protective option the default

Private profiles, analytics off, location while-using, sharing opt-in. Article 25(2) requires it, and it's also the setting most users would choose if they engaged with the decision, which most don't.

Tag data with its collection purpose

In the schema, alongside its classification. It makes purpose limitation enforceable — a query joining marketing data to support data collected under a different purpose becomes something tooling can flag rather than something nobody notices.

Do the privacy review before the architecture is settled

An hour at design time versus a migration afterward. Make it a gate on any feature touching personal data, alongside the architecture review, and record the outcome as a DPIA.

Process on-device where the capability exists

Modern phones and browsers can do a great deal locally — classification, search, transcription, even inference. Sending only the result rather than the raw input removes the data from scope entirely, which is stronger than any protection you could apply to it on a server.

Revisit collection periodically

Systems accumulate fields nobody reads. An annual review comparing collected fields against actual usage in code and queries reliably finds columns to drop, and dropping a column removes every obligation attached to it at once.

Common Mistakes

Collecting "just in case"

Privacy as a settings page

Repurposing data silently

Storing precision you don't need

Security review without a privacy review

Treating privacy as legal's problem

FAQ

Isn't this just compliance with extra steps?

Compliance is the floor and this is the design discipline that makes meeting it cheap. A system built with minimization, separated identity, and defined retention satisfies most of GDPR almost incidentally — deletion works, access requests are answerable, and the breach blast radius is small. A system built without them needs a project per requirement.

Doesn't minimization hurt the product?

Occasionally, and far less often than assumed. Most collected fields are never read — an audit of actual usage against collected columns nearly always finds a large fraction unused. Where data genuinely drives value, the question is granularity and identifiability rather than collection: an age band usually serves as well as a birthdate, and aggregate metrics usually serve as well as per-user rows.

What is differential privacy, practically?

A mathematical guarantee that the output of an analysis reveals essentially nothing about whether any single individual was in the input, achieved by adding calibrated noise. It's deployed at scale by Apple, Google, and the US Census Bureau. The tradeoff is accuracy: strong guarantees need enough noise to matter on small datasets, so it works best for aggregate statistics over large populations. It's not a substitute for minimization.

How do we do this in an existing system?

Incrementally, and start with the audit: which fields do we collect, and which does any code actually read? Drop the unused ones — that's the cheapest win available. Then set retention periods on what remains, coarsen precision where you can, and separate identity from data for new subsystems. Retrofitting the identity split across an existing system is a large project, so apply it going forward rather than as a migration.

When is a DPIA mandatory?

When processing is likely to result in a high risk to individuals: large-scale systematic monitoring, systematic profiling with significant effects, special-category data at scale, or new technologies applied to personal data. Supervisory authorities publish lists of processing that always requires one. Practically, doing a lightweight version for any feature touching personal data is cheap and means the mandatory ones aren't a novel exercise.

Does on-device processing remove all obligation?

It removes the obligation for data that never leaves the device — which is a genuine and large reduction. What remains: whatever is transmitted (results, telemetry, crash reports) is still personal data if it relates to an identifiable person, and data stored on the device is still yours to protect if your app controls it. It's a strong architectural move, not an exemption.