What Is Privacy by Design?

Privacy by design holds that privacy should be built into systems from the outset rather than added afterwards. It is now a legal requirement in several regimes rather than a best practice, and it is the privacy equivalent of threat modelling: cheap at design, expensive at launch, nearly impossible after.

The practical translation is a set of questions asked early enough that the answers can still change the architecture.

The questions that do the work

What personal data does this genuinely need, and what are we collecting because it might be useful later? Could this work with less identifiable data — aggregated, pseudonymised, or not collected at all? Who will be able to see it, and is that the smallest set? How long must we keep it, and what deletes it? How will we honour access, correction and deletion requests? And what is the default — does the privacy-protective option require the user to act?

That last question is where legal requirements are increasingly explicit. Where a service offers privacy settings, the most protective must frequently be the default, with no user intervention required.

Data minimisation is the highest-leverage decision

Data you never collected cannot be breached, cannot be requested, cannot be mis-shared and does not need retention rules. Every other control is managing a risk that minimisation would have removed.

The obstacle is cultural rather than technical. Product and analytics teams want optionality, and collecting a field costs nothing visible today. Making minimisation a design question with a named owner is what converts it from a principle into a decision.

Assessments as the forcing function

Privacy impact assessments are where this becomes concrete, and in several regimes they are mandatory before deploying systems processing personal data — in Alberta, submitted to the Commissioner before implementation rather than filed afterwards.

The forcing function works when the assessment happens early enough to influence the design. An assessment completed the week before launch documents decisions rather than shaping them, which is compliance theatre with a genuine cost attached.

Defaults are where the principle becomes concrete

Of the seven principles usually cited, the one with the clearest practical test is privacy as the default setting. If a user must take action to obtain the protective configuration, the design has failed the principle regardless of how well the options are documented.

This now has legal force in several regimes rather than being advisory, and it lands on product engineering rather than on the privacy function — which is why it is so often discovered late. The team that writes the privacy notice is rarely the team that sets the default toggle state.

The check is simple enough to build into design review: for every setting affecting personal data, what happens if the user never touches it? Where the answer is the less protective option, that is the finding.

Where to start

Take the next feature that touches personal data and ask the minimisation question before anything is built: what could we not collect and still deliver this? It costs an hour and it removes obligations permanently.

See Quebec Law 25 and Alberta HIA. GuardsArm supports compliance auditing.