Privacy by design: what it is and how to apply it

«Privacy by design» is one of those phrases you read everywhere and rarely understand. It is often treated as a document to attach to a project, a box to tick before going live. In reality it is not a piece of paperwork: it is the way software is conceived and built from the very first line, so that it protects people’s data without anyone having to remember to do so afterwards.

What the GDPR actually says

The principle is written plainly in Article 25 of the GDPR, which speaks of «data protection by design and by default». These are two distinct things. Protection by design concerns the choices made while the system is being built. Protection by default concerns how the system behaves the moment it is switched on, before anyone touches a single setting.

The law does not mandate a specific technology. It asks for an outcome: that data protection be built into the system, proportionate to the risks, and not bolted on afterwards as a patch. It is a difference of substance, not of form. A well-designed system does not have to chase compliance: it already has it inside.

It is not a document, it is an architecture

The most common mistake is to reduce privacy by design to a file. A report is written, filed, and the building goes on exactly as before. But a PDF protects no data. What protects data are the technical decisions: what information is collected, where it is stored, who can see it, how long it stays, what happens when it is no longer needed. These decisions are made at design time, and changing them later costs far more than getting them right at the start.

The principles, turned into concrete choices

Privacy by design becomes useful only when it stops being a slogan and turns into a series of choices. Translated into practice, the principles sound like this.

• Minimisation. You collect only the data genuinely needed to deliver the service. A field you do not collect does not need protecting, cannot be lost in a breach, does not need keeping. The safest piece of data is the one that does not exist.
• Protection by default. The initial settings are the most protective ones: no optional processing switched on by default, visibility kept to a minimum, consent asked for only where it is needed and never pre-ticked.
• Storage limitation. Every piece of data has an expiry. You decide from the start when information must be deleted or anonymised, and you automate it, instead of hoarding forever.
• Least access. Each person sees only what their task requires. An administrative role does not imply access to everything: permissions are granular and checked on every request.
• Built-in security. Encryption of sensitive data, passwords never in clear text, logs that do not record full personal information. Security is not a module added at the end, it is part of how the system is written.
• Transparency. Whoever uses the service can know which data is processed and why, in a readable form, not buried in twenty pages of terms.

Privacy by default: the contact form example

A simple case makes the point better than any definition: a contact form. The version built without thinking collects first name, last name, phone, company, and maybe adds an analytics tool that profiles whoever fills it in. The version designed with privacy by design asks only for what is needed to reply, protects the form from spam without tracking anyone, and keeps the request for as long as it takes to handle it, not forever.

# Data collected by the form: only the minimum needed to reply
email      # to get back to the person
message    # the request itself
# No mandatory name, no phone number, no profiling.

# Retention: the request does not stay forever
retention = 12 months  ->  then automatic deletion

Neither version breaks the law in any obvious way. But only the second builds protection into the system, instead of leaving it to the goodwill of whoever runs it. That is the difference Article 25 asks you to make.

Why it pays off, not just why it is required

Building this way is not a cost imposed by regulation. It is a better system, on every count that matters.

• Less risk. Less data collected and kept means less damage when something goes wrong. A breach hurts less when there is little to steal.
• More trust. A service that asks only for the essentials, and says so clearly, is one people trust more.
• Lower costs. Building data protection in during development costs a fraction of what it costs to rework a system already in production to bring it into line.
• Simpler compliance. When the right choices are already in the system, proving you respect the GDPR becomes a formality, not an emergency.

When a further step is needed: the DPIA

For processing that may carry a high risk to people, the GDPR requires an impact assessment, the DPIA. It is not mandatory for every project, but when it is needed it must be done before building, not after. That is exactly where privacy by design shows its worth: it lets you spot the risks while fixing them is cheap, on paper, rather than on a system already running.

Where to start

Privacy by design does not require exotic tools. It requires asking the right questions at the start of the project, and writing the answers into the code, not only into a document.

• Map the data: what information enters the system, where it comes from and why it is needed.
• Remove the superfluous: every field that does not serve a clear purpose has to go.
• Set the deadlines: for each piece of data, decide how long it is kept and automate its deletion.
• Close the access: minimum permissions, checked on every operation, not granted once and forgotten.
• Document the choices: not instead of making them, but so you can prove them.

In the end, privacy by design is not a certificate to hang on the wall. It is a way of building: start from the question «do I really need this piece of data?» and let the answer drive the architecture. That is how this site is built, and it is the approach I bring to every project: data protection not as a constraint to endure at the end, but as the starting point.

For how these principles become concrete technical choices, from the form to the CSP to the logs, in a real website:

Privacy and security by design, in practice: the choices behind a real website