Privacy by Design: Build Privacy In From the Start

in the same way as the concept of Secure by design covers thinking about the security of a system at the earliest opportunity, Privacy by design does the same.

Some things have to be considered from the beginning because retrofitting them later is expensive, inconvenient, or simply doesn’t work very well.

If an organisation designs an application that collects every piece of information it possibly can, keeps that information indefinitely, shares it with dozens of other systems and only later asks how to make the arrangement “private”, it is already starting from the wrong position.

Privacy by Design means considering privacy from the beginning of a system’s design rather than trying to add it afterwards.

What is Privacy by Design?

Privacy by Design means incorporating privacy considerations into the architecture, design, development and operation of systems and processes.

Instead of asking “How do we make this system comply with privacy requirements?”, you should ask “How should we design this system so that it respects privacy by default?”

This can apply to:

  • Websites
  • Mobile applications
  • Cloud services
  • Databases
  • APIs
  • Identity systems
  • Customer-management systems
  • CCTV systems
  • IoT devices
  • AI systems
  • HR systems
  • Marketing platforms
  • Physical security systems
  • Business processes

The important point is that privacy isn’t treated as an optional feature – It is a design requirement.

Why Does Privacy by Design Matter?

It is tempting to think of privacy as something that mainly concerns lawyers, compliance teams and privacy policies. It isn’t.

Many privacy problems are actually design problems.

Consider an application that needs to know a customer’s age.

A poorly designed system might collect:

Customer name
Address
Date of birth
National Insurance number
Telephone number
Email address
Passport number
IP address
Device information
Location

But perhaps the application only needs to determine whether the customer is over 18.

A privacy-focused design might instead store:

Customer ID
Age verified: YES

The second system has considerably less sensitive information available to lose, steal, misuse or accidentally disclose.

This is an important principle:

The best way to protect information you don’t need is not to collect it.

Data Minimisation

One of the most important ideas behind Privacy by Design is data minimisation.

  • If you don’t need a piece of personal information, don’t collect it.
  • If you need it temporarily, don’t necessarily store it permanently.
  • If you need to store it, consider whether you need the original value or whether a less sensitive representation is sufficient.

For example, imagine a system that needs to know which country a customer is located in.

It might be possible to store:

Location: London, United Kingdom

rather than:

Exact GPS location:
51.500889, -0.142944

The first approach provides the application with what it needs without creating an unnecessarily precise record.

Data minimisation therefore asks – What information do we actually need to achieve the purpose?

Purpose Limitation

Privacy by Design also means deciding why information is being collected. This is purpose limitation.

Suppose an online retailer collects a customer’s telephone number to arrange delivery.

That doesn’t automatically mean the marketing department should be able to use the same number for promotional calls.

The original purpose was to arrange a delivery time, not for marketing.

The fact that an organisation possesses information doesn’t necessarily mean that every part of the organisation should be able to use it for every purpose.

Good privacy design therefore considers:

  • Why is the data being collected?
  • What will it be used for?
  • Who needs access?
  • Will it be shared?
  • How long will it be retained?
  • Could the purpose change later?

Privacy by Default

Privacy by Design is closely related to another important principle – Privacy by Default.

Privacy by default means that the system should start with the most privacy-preserving reasonable settings rather than expecting the user to configure them.

For example, imagine a new social-media application.

A privacy-poor default might be:

Profile visibility: Everyone
Location sharing: ON
Contact synchronisation: ON
Personalised advertising: ON
Activity tracking: ON

A more privacy-conscious design might start with:

Profile visibility: Limited
Location sharing: OFF
Contact synchronisation: OFF
Personalised advertising: OFF
Activity tracking: Minimal

The user can still choose to enable features where appropriate, but the important distinction is that privacy isn’t dependent on the user knowing which settings they need to change.

Privacy and Least Privilege

There is a strong relationship between Privacy by Design and that of Least Privilege.

Least Privilege asks – What access does this person, application or system actually need?

Privacy asks a similar question about personal information – What information does this person, application or system actually need?

  • A delivery system doesn’t necessarily need access to payment information.
  • A marketing system doesn’t necessarily need access to a customer’s full address.
  • A finance system doesn’t necessarily need access to everything about the customer’s activity.

Privacy therefore benefits from applying least privilege to data access.

Privacy and Data Retention

Another important design question is How long should we keep this information?

Organisations often accumulate information simply because nobody has designed a process for removing it. A privacy-conscious system might define retention periods from the beginning:

The exact retention period depends on the purpose and applicable legal or regulatory requirements.

The important principle is that “we might need it someday” is NOT a privacy design strategy.

Privacy and Access Control

Privacy isn’t achieved simply by putting information into a database and protecting the database with a password. The system should determine who needs access to what information.

An IT administrator might need to maintain the system without routinely being able to view all of the personal information stored within it.

This leads to another useful principle:

People should have access to the information they need to perform their role, not automatically to everything the system contains.

Anonymisation and Pseudonymisation

Privacy by Design can also involve reducing the sensitivity of information.

Anonymisation – Here, information is transformed so that individuals can no longer reasonably be identified.

For example:

John Smith → anonymous statistical record

Pseudonymisation – All Identifying information is replaced with another identifier.

For example:

John Smith → Customer ID: 482731

The identifying information may still exist elsewhere, meaning pseudonymisation does not make information completely anonymous.

Nevertheless, separating identity from operational data can reduce unnecessary exposure.

Encryption by Design

Encryption is another important part of privacy-conscious architecture.

Sensitive personal information should be protected at all times, and this fact should be considered during architectural design rather than added after deployment.

However, encryption isn’t a complete privacy solution. A perfectly encrypted database doesn’t help much if:

  • Too many employees can decrypt it
  • Applications expose the information unnecessarily
  • Data is retained forever
  • The organisation collects far more information than necessary
  • The information is used for purposes the individual didn’t expect

Privacy requires a broader approach.

Transparency by Design

Privacy also involves allowing people to understand what happens to their information.

A system should make it possible to answer questions such as:

  • What information is being collected?
  • Why is it being collected?
  • Who can access it?
  • How is it being used?
  • How long will it be retained?
  • Is it shared with other organisations?
  • How can it be corrected?
  • How can it be deleted where applicable?

This doesn’t necessarily mean presenting users with a 40-page privacy policy and expecting them to read it. Good design can make important information understandable at the point where it matters.

A user should be able to understand why the information is being requested before making the decision to allow it or not.

Privacy and User Control

Where appropriate, users should have meaningful control over their information.

This might include mechanisms to:

  • View information held about them
  • Correct inaccurate information
  • Change privacy settings
  • Withdraw consent where applicable
  • Request deletion where applicable
  • Export their information
  • Control optional data collection

The important word is meaningful.

A system that technically provides a privacy setting but hides it behind six layers of menus isn’t particularly privacy-friendly.

Privacy Shouldn’t Depend on Perfect Users

One of the most important lessons from Privacy by Design is that we shouldn’t expect users to understand the technical consequences of every decision.

Good privacy design therefore considers human behaviour. It shouldn’t assume that users will:

  • Read every privacy policy
  • Understand technical terminology
  • Configure every security setting
  • Recognise unnecessary data collection
  • Understand the consequences of sharing information

Privacy by Design and GDPR

Privacy by Design has particular significance in the UK and Europe because data protection law explicitly addresses the concept.

The UK GDPR (General Data Protection Regulation) contains the principle of data protection by design and by default.

This means organisations should consider appropriate technical and organisational measures when designing processing activities rather than waiting until after systems have been implemented.

Privacy by Design therefore isn’t merely a nice architectural philosophy – For organisations processing personal data, it can form part of their legal and regulatory responsibilities.

Privacy by Design vs Secure by Design

These concepts are closely related but aren’t identical.

  • Secure by Design primarily asks – How do we design the system so that it is resistant to attacks and failures?
  • Privacy by Design primarily asks – How do we design the system so that personal information is handled appropriately and individuals’ privacy is respected?

Security protects information, and Privacy considers whether the information should be collected, how it should be used, who should have access to it, and when it should be removed.

You need both.

The Seven Principles of Privacy by Design

Privacy by Design is commonly associated with seven foundational principles:

  1. Proactive, not reactive — anticipate privacy risks rather than responding after something goes wrong.
  2. Privacy as the default — users shouldn’t have to take action to obtain reasonable privacy.
  3. Privacy embedded into design — privacy should be part of the architecture rather than an add-on.
  4. Full functionality — privacy shouldn’t automatically mean sacrificing legitimate functionality.
  5. End-to-end security — protect information throughout its entire lifecycle.
  6. Visibility and transparency — make privacy practices understandable and verifiable.
  7. Respect for the user — keep the individual’s interests and expectations at the centre of the design.

These principles provide a useful way of thinking about privacy during system design.

In Summary

Privacy by Design means building privacy into systems, applications and processes from the beginning.

The key ideas are:

  • Minimise data collection
  • Define clear purposes
  • Use privacy-friendly defaults
  • Apply least privilege to personal information
  • Restrict access
  • Protect information throughout its lifecycle
  • Define retention and deletion
  • Provide transparency
  • Give users meaningful control
  • Consider privacy before development begins

The relationship with Secure by Design is particularly important.

  • Secure by Design asks how we protect the system and its information.
  • Privacy by Design asks whether we should collect the information in the first place, how it should be used, and how we can respect the people represented by that information.

The best privacy control is often the simplest one:

Don’t collect information you don’t need.