Privacy by Design

An architectural principle that requires privacy protections to be embedded into the design of systems and processes from the very beginning — not added as an afterthought or a compliance checkbox.

What is it?

Privacy by Design (PbD) is the idea that privacy should be a core architectural requirement, not a feature bolted on at the end. It was developed by Ann Cavoukian, then Information and Privacy Commissioner of Ontario, in the 1990s and later adopted as a legal requirement under GDPR Article 25 and Swiss nDSG Article 22.¹

The principle challenges a common pattern in software development: build the feature first, then figure out how to make it compliant. PbD inverts this. You design for privacy before you write the first line of code, the same way you design for security, performance, or accessibility.

In practice, this means that every architectural decision — what data to collect, where to store it, how long to keep it, who can access it — should default to the most privacy-protective option. The user shouldn’t have to opt out of data collection. They should have to opt in.²

In plain terms

Privacy by Design is like building a house with locks on the doors from the start, rather than installing them after a break-in. The house is designed so that privacy is the default state — curtains come pre-installed, not sold as optional extras.

At a glance

The seven foundational principles (click to expand)
graph TD
    A[Privacy by Design] --> B[Proactive not Reactive]
    A --> C[Privacy as Default]
    A --> D[Embedded into Design]
    A --> E[Full Functionality]
    A --> F[End-to-End Security]
    A --> G[Visibility & Transparency]
    A --> H[User-Centric]
    style A fill:#4a9ede,color:#fff
Key: Cavoukian’s seven principles form the foundation. They move from mindset (proactive) through architecture (embedded, default, full-lifecycle) to user experience (transparency, user-centricity).

How does it work?

The seven foundational principles

Ann Cavoukian defined seven principles that operationalise PbD. Each translates directly into architectural and design decisions.¹

1. Proactive not reactive — preventative not remedial

Anticipate privacy risks before they occur. Don’t wait for a breach or a complaint to act.

Think of it like...

A doctor who recommends exercise and diet changes is proactive. A doctor who only treats heart attacks is reactive. PbD is preventive medicine for data.

2. Privacy as the default setting

The strictest privacy settings should apply automatically, without user action. If a user creates an account, their profile should be private by default, not public.

Developer rule of thumb

If the user does nothing, the maximum privacy should be in effect. Every relaxation of privacy requires an explicit, informed choice.

3. Privacy embedded into design

Privacy is not an add-on module. It’s woven into the architecture, the data model, the API design, and the business logic.

4. Full functionality — positive-sum, not zero-sum

Privacy and functionality are not opposites. A well-designed system can protect privacy and deliver full functionality. Don’t frame privacy as a trade-off.³

5. End-to-end security — full lifecycle protection

Data must be protected from the moment it’s collected to the moment it’s deleted. This covers encryption in transit, encryption at rest, access controls, and automated deletion.

6. Visibility and transparency

Users and regulators should be able to verify that privacy protections are actually in place. Open documentation, audit logs, and clear privacy notices serve this principle.

7. Respect for user privacy — keep it user-centric

Design with the user’s interests in mind, not your own convenience. Offer granular controls, understandable explanations, and meaningful choices.

From principles to architecture

PbD Principle	Architectural pattern
Privacy as default	Opt-in data collection, no tracking without consent
Embedded into design	Privacy-aware data models (separate PII from analytics)
End-to-end security	Encryption at rest and in transit, field-level encryption for sensitive data
Data minimisation	Schema design that only includes necessary fields
Purpose separation	Separate databases or schemas per processing purpose
Retention by design	TTL (time-to-live) on records, automated deletion jobs
Right to erasure	Soft-delete with hard-delete scheduler, cascading deletion across services

For example: designing a user profile system

Without PbD: Collect name, email, phone, address, date of birth, photo, and location at signup. Store everything in one table. Keep it forever. Profile is public by default.

With PbD:

Collect only email at signup (minimisation)

Profile is private by default (privacy as default)

Additional fields are opt-in with clear purpose statements

PII stored in a separate, encrypted table from usage analytics (embedded into design)

90-day retention on analytics, user-controlled retention on profile data (lifecycle)

One-click data export and deletion (user-centric)

Audit log of all data access (transparency)