Skip to main content
Bureau of AI
Category: Privacy & Data Protection

Privacy by Design and Default

Also known as: PbD, Data Protection by Design and by Default, Privacy by Design, Privacy by Default
Simply put

Privacy by Design and Default is an approach in which privacy protections are built into products, services, and systems from the earliest stages of their development rather than added afterward. Under the 'by default' aspect, organizations are expected to configure their systems so that the strongest privacy settings apply automatically and only the personal data necessary for a specific purpose is used. It combines a design philosophy with, in some jurisdictions, a legal obligation.

Formal definition

Privacy by Design and Default refers to the practice of embedding data protection measures into the design and operation of processing activities and, by default, limiting the collection, use, retention, and accessibility of personal data to what is necessary for each specified purpose. The concept originated in the 1990s work of Dr. Ann Cavoukian, then Information and Privacy Commissioner of Ontario, who articulated seven foundational Privacy by Design principles as a voluntary framework. It was subsequently given explicit legal force in the EU General Data Protection Regulation (GDPR) and the UK GDPR, where 'data protection by design and by default' is set out as an obligation under Article 25; practitioners should note that outside these frameworks the term may function as a design principle or guidance rather than a binding requirement, and that its specific implementation obligations are scoped to those instruments and their applicable jurisdictions. As commonly defined, 'by design' addresses proactive integration of technical and organizational measures throughout the lifecycle, while 'by default' addresses configuration such that, absent user intervention, processing defaults to the highest level of privacy protection consistent with the stated purpose.

Why it matters

Privacy by Design and Default reframes data protection as an upstream engineering and governance concern rather than a compliance patch applied late in a system's lifecycle. When privacy measures are embedded from the earliest design stages, organizations reduce the likelihood of costly retrofits, minimize the volume of personal data exposed to potential misuse or breach, and are better positioned to demonstrate accountability. In frameworks such as the EU GDPR and the UK GDPR, this is more than good practice: 'data protection by design and by default' is set out as an explicit legal obligation under Article 25, meaning that in-scope organizations can face regulatory scrutiny for failing to build in appropriate technical and organizational measures.

The 'by default' dimension carries particular weight because it shifts the burden away from the individual. Rather than requiring users to hunt for and enable privacy protections, systems must be configured so that the most privacy-protective settings apply automatically, and so that only the personal data necessary for each specified purpose is collected and used. This directly counters common design patterns in which broad data collection is switched on by default and left to the user to disable.

For practitioners, the concept matters because it links a design philosophy—originating in the voluntary framework articulated in the 1990s by Dr. Ann Cavoukian, then Information and Privacy Commissioner of Ontario—to concrete, jurisdiction-specific legal duties. Its practical force depends heavily on context: within GDPR and UK GDPR it functions as a binding requirement, while in other jurisdictions or sectors it may operate as guidance or a design principle rather than an enforceable obligation. Treating it uniformly across all contexts is a frequent source of error.

Who it's relevant to

Data protection officers and privacy leads
For those accountable for privacy compliance, Privacy by Design and Default is central to demonstrating accountability. Under the GDPR and UK GDPR, they must ensure that data protection by design and by default is operationalized as an Article 25 obligation, translating the principle into documented technical and organizational measures across in-scope processing activities.
Product managers and system designers
Because the concept demands that privacy be embedded from the earliest development stages, product and design teams are directly responsible for architecture and default configuration decisions. They must ensure that systems default to the highest privacy protection and that data collection is limited to what is necessary for each specific purpose, rather than treating privacy as a later add-on.
Engineering and development teams
Developers implement the technical measures that give the design philosophy effect throughout the processing lifecycle. Their configuration choices determine whether, absent user intervention, a system defaults to privacy-protective behavior and limits access to and retention of personal data as the framework expects.
Legal and compliance professionals
Legal teams must scope the obligation correctly to jurisdiction. Within the EU GDPR and UK GDPR, data protection by design and by default is a binding requirement under Article 25; in other contexts it may function as guidance or a voluntary design principle. Distinguishing these situations is essential to accurate risk assessment and advice.

Inside PbD

Privacy by Design (PbD)
An approach that embeds privacy considerations into the design and architecture of systems, processes, and business practices from the outset, rather than adding them retroactively. The concept originated in the 1990s through the work of Dr. Ann Cavoukian, then Information and Privacy Commissioner of Ontario, who articulated seven foundational principles for PbD.
Privacy by Default
A related requirement that, by default, only personal data necessary for each specific purpose of processing is processed. This typically concerns default configuration settings so that systems minimize data collection, retention, and accessibility unless a user or controller affirmatively broadens them.
Legal basis (Article 25 GDPR / UK GDPR)
In the EU and UK context, data protection by design and by default is set out as an explicit legal obligation in Article 25 of the GDPR and the UK GDPR, applying to controllers. As commonly understood, it requires appropriate technical and organizational measures determined with reference to the state of the art, cost, and the nature and risks of processing. Its precise scope outside these jurisdictions varies.
Data minimization
A core component under which the amount of personal data collected, the extent of processing, the retention period, and accessibility are limited to what is necessary for the stated purpose.
Technical and organizational measures
The combination of engineering controls (for example, pseudonymization, access controls, encryption) and organizational controls (policies, roles, training) used to give effect to privacy protections. As commonly framed, these should be proportionate to the risks presented by the processing.
Lifecycle integration
The principle that privacy protections are considered across the full lifecycle of a system or processing activity, from initial design through deployment, operation, and decommissioning, rather than at a single checkpoint.

Common questions

Answers to the questions practitioners most commonly ask about PbD.

Is 'privacy by design' just another way of saying 'data security'?
No. Data security is one component, but privacy by design is broader. As commonly defined, it addresses the full lifecycle of personal data handling—including data minimization, purpose limitation, transparency, and default settings that protect individuals—not only the technical safeguards that protect data against unauthorized access. Security controls can be strong while a system still collects more data than necessary or configures sharing defaults in a privacy-invasive way, which the concept is intended to prevent. Treating the two as synonymous typically causes teams to overlook the design and default-configuration obligations that go beyond confidentiality.
Does implementing privacy by design guarantee compliance or eliminate privacy risk?
No. Privacy by design is a set of measures that reduce and manage privacy risk; it does not eliminate it, and it is not a compliance guarantee on its own. Embedding privacy considerations into design and defaults supports obligations, but organizations still typically need documentation, records of processing, lawful bases, individual rights handling, and ongoing monitoring. Professionals frequently err by treating a one-time design decision as permanent assurance, whereas privacy risk can re-emerge as systems, data uses, or processing purposes change over time.
Where does the legal obligation for privacy by design and by default come from?
In the EU and UK context, the obligation is set out explicitly in Article 25 of the GDPR (and the corresponding provision of the UK GDPR), often labeled 'data protection by design and by default.' The underlying concept predates that legal codification: it originated in the 1990s work of Dr. Ann Cavoukian, then the Information & Privacy Commissioner of Ontario, who articulated the seven foundational Privacy by Design principles. It is worth distinguishing the voluntary conceptual framework from the binding legal duty—the former informed the latter, but the specific enforceable requirements are those in the applicable statute for a given jurisdiction. Organizations outside the scope of the GDPR/UK GDPR may face different or no directly equivalent legal mandates.
How does 'by default' differ from 'by design' in practice?
As commonly framed, 'by design' concerns building privacy considerations into systems, processes, and architectures from the outset, while 'by default' concerns the out-of-the-box configuration a person encounters without taking any action. In practice, 'by default' typically means that, absent user intervention, only personal data necessary for each specific purpose is processed, and settings favor the more privacy-protective option. A frequent implementation error is designing privacy-protective features but then shipping them switched off, which satisfies the design element while undermining the default element.
At what stage of a project should privacy by design be applied?
The concept, as commonly understood, calls for privacy to be considered from the earliest stages—during requirements gathering and system design—rather than added after a system is built. Applying it late tends to force costly retrofitting and may leave data flows or default settings that are difficult to change. In many frameworks, this early consideration is documented through a data protection impact assessment or similar risk assessment where processing is likely to be high risk, though the specific triggers and required documentation depend on the applicable regime.
How can an organization demonstrate that privacy by design has been applied?
Demonstration typically rests on documentation rather than the design intent alone. In many frameworks this includes records showing that privacy risks were assessed, that data minimization and purpose limitation were considered in design choices, that default configurations were set to protect individuals, and that decisions were reviewed as the system changed. Impact assessments, design records, and configuration evidence commonly support accountability. The specific artifacts expected depend on the applicable legal regime, so organizations should confirm what their governing authority requires rather than assuming a single universal standard.
Who is responsible for implementing privacy by design across the lines of defense?
Responsibility is usually shared. In many governance models, the first line—product, engineering, and data teams that build and operate systems—embeds privacy into design and defaults, while a second-line function such as a privacy office, data protection officer, or risk function sets standards, advises, and challenges. Third-line functions such as internal audit provide independent assurance that the measures are in place and effective. A common error is treating privacy by design as solely the privacy team's task, when the operative design and default decisions are typically made by the teams building the system.

Common misconceptions

Privacy by Design and Privacy by Default are the same requirement.
They are distinct though complementary. Privacy by Design concerns embedding privacy into system design from the outset, while Privacy by Default concerns ensuring that default settings limit processing to what is necessary. In the EU/UK context both are addressed within Article 25 GDPR / UK GDPR but describe different obligations.
Privacy by Design is a purely voluntary best practice with no legal force.
While the concept originated as a set of foundational principles articulated by Dr. Ann Cavoukian in the 1990s, in the EU and UK it is an explicit legal obligation under Article 25 GDPR / UK GDPR for controllers. Its legal status differs by jurisdiction, so practitioners should confirm the applicable framework rather than assume it is either universally binding or universally optional.
Implementing Privacy by Design and Default eliminates privacy risk.
These measures are intended to reduce and manage privacy risk, not remove it. They lower residual risk through proportionate technical and organizational controls but do not guarantee the absence of privacy harms.

Best practices

Embed privacy requirements at the earliest design stage of a system or processing activity rather than treating them as a later add-on.
Configure default settings so that only personal data necessary for each specific purpose is processed, and require affirmative action to broaden collection, retention, or access.
Where the EU or UK GDPR applies, document how Article 25 obligations are met, including the technical and organizational measures selected and their proportionality to the processing risks.
Apply data minimization across the lifecycle by limiting the volume of data collected, the extent of processing, retention periods, and accessibility to what is necessary.
Select and layer technical controls (such as pseudonymization, encryption, and access controls) alongside organizational controls (policies, roles, and training) proportionate to identified risks.
Confirm the applicable legal framework and its jurisdictional scope before assuming a given obligation applies, since the legal status of Privacy by Design and Default varies across jurisdictions.