By Daniel de Almeida Afonso · Last updated: October 12, 2026
Privacy by design means building privacy protection into a product, system or process from the first design decision, instead of adding it after launch. Ann Cavoukian, then Ontario's Information and Privacy Commissioner, set the idea out in seven foundational principles, and Article 25 of the GDPR turned it into a legal duty called data protection by design and by default.
Under Article 25, a controller must build safeguards into its processing and must configure systems so that, by default, only the personal data needed for each purpose is processed. A breach of Article 25 falls in the lower GDPR fine tier: up to €10 million or 2% of worldwide annual turnover for an undertaking, whichever is higher. This guide explains the concept, the seven principles and the law behind them. For the Article 25 how-to and the enforcement cases, use our privacy by design GDPR implementation guide.
What is privacy by design?
Privacy by design is an approach in which privacy is a requirement of the design, not a feature or a policy added at the end. A team that follows it asks "what is the least personal data this product needs?" before it builds.
A privacy control that is part of the architecture keeps working when people forget about it. A control added later depends on someone remembering to apply it.
Three terms are often mixed up:
- Privacy by design is the overall approach and the seven principles behind it.
- Data protection by design and by default is the GDPR's name for the legal duty in Article 25. This phrase is what the regulation actually uses.
- Privacy by default is one part of the approach: the out-of-the-box settings must be the privacy-protective ones.
Where privacy by design came from
The idea predates the GDPR by more than twenty years.
- Mid-1990s. Cavoukian's office in Ontario worked on privacy-enhancing technologies. Secondary sources date the formal roots to a 1995 joint report with the Dutch data protection authority and a Dutch research organization.
- 2010. The 32nd International Conference of Data Protection and Privacy Commissioners, held in Jerusalem in October 2010, adopted a resolution on privacy by design. It recognized the concept as an essential component of fundamental privacy protection and encouraged organizations to adopt the foundational principles.
- 2012. In March 2012 the US Federal Trade Commission's final report on consumer privacy told companies to build privacy protections in at every stage of developing their products.
- 2016 to 2018. The GDPR was adopted in 2016 and has applied since May 2018. Article 25 made "data protection by design and by default" binding on controllers in the EU.
- 2020. The European Data Protection Board adopted version 2.0 of its Guidelines 4/2019 on Article 25 on 20 October 2020, after a public consultation on version 1.0 from November 2019.
- 2023. ISO published ISO 31700-1, a standard on privacy by design for consumer goods and services. More on it below.
The seven foundational principles
Cavoukian's seven principles are the part of privacy by design most people quote. The names below follow the Information and Privacy Commissioner of Ontario's own headings.
- Proactive not reactive; preventative not remedial. Anticipate, identify and prevent privacy-invasive events before they happen. Do not wait for a breach or a complaint.
- Privacy as the default setting. Build the maximum degree of privacy into the default settings of any system or business practice. If a person does nothing, their data stays protected.
- Privacy embedded into design. Privacy belongs in the architecture of the system and in business practices, not in a layer added later.
- Full functionality: positive-sum, not zero-sum. Treat privacy and other goals, such as security and usability, as things to achieve together. Reject the assumption that every gain in privacy is a loss elsewhere.
- End-to-end security: full lifecycle protection. Protect personal data from the moment it is collected until it is securely destroyed.
- Visibility and transparency: keep it open. Make practices open and verifiable, so that users and others can check that you do what you say.
- Respect for user privacy: keep it user-centric. Put the individual first: strong defaults, clear notice and easy-to-use controls.
The principles are a design philosophy, not a legal checklist. Article 25 does not list them, and meeting all seven does not by itself prove GDPR compliance. Principle 2 is "default," which is why people treat "design" and "default" as one thing. The law separates them, as the next section shows.
Privacy by design vs privacy by default
Both duties sit in the same article, but in different paragraphs, and they ask different questions. Design is about how you build and run the processing. Default is about what the system does when nobody has touched a setting.
| Privacy by design (Article 25(1)) | Privacy by default (Article 25(2)) | |
|---|---|---|
| Question it answers | Have we built data protection principles into the processing? | Does the system process only what is necessary until the person decides otherwise? |
| When it applies | When you decide how the processing will work, and again while it runs | Whenever a setting, form or feature has a starting value |
| What it covers | Technical and organisational measures that implement the principles, such as data minimisation | Four dimensions: amount of data collected, extent of processing, storage period and accessibility |
| Typical example | Pseudonymising data early; running a risk assessment before launch | A profile that starts private; location tracking that starts off; optional form fields left optional |
| What a reviewer checks | Whether the measures are effective for the risks | Whether people have to act before more data is processed |
Choose design first if you are building something new, because it shapes the data model. Choose default first if you already run a product, because reviewing starting values is fast and visible. In practice you need both.
One detail in Article 25(2) is easy to miss. It says that by default, personal data must not be made accessible, without the individual's intervention, to an indefinite number of people. A social profile that is public until the user changes it is the textbook failure.
What Article 25 and recital 78 actually say
The legal text is short. The full regulation is on EUR-Lex.
Article 25(1) requires the controller, both when it decides the means of processing and during the processing itself, to implement appropriate technical and organisational measures, such as pseudonymisation. These measures must be designed to implement the data protection principles, such as data minimisation, effectively, and to integrate the necessary safeguards into the processing. The article ties "appropriate" to four factors: the state of the art, the cost of implementation, the nature, scope, context and purposes of the processing, and the risks to people's rights and freedoms.
Article 25(2) is the default rule. Only personal data necessary for each specific purpose may be processed, and the duty applies to the amount collected, the extent of processing, the storage period and accessibility.
Article 25(3) says an approved certification mechanism under Article 42 may be used as one element to show compliance.
Recital 78 explains the thinking. It calls for internal policies and measures that reflect design and default, and it gives examples: minimising personal data, pseudonymising it as soon as possible, being transparent about its functions, letting people monitor the processing and letting the controller create and improve security features. It adds that producers of products, services and applications should be encouraged to take the right to data protection into account, and that the principles should be considered in public tenders.
Three further points come from the EDPB's Guidelines 4/2019:
- The duty applies to all controllers, irrespective of size and of how complex the processing is.
- It applies to systems that already existed, not only new ones. Controllers must review the effectiveness of their measures regularly.
- Processors and producers are not directly addressed by Article 25. The controller, however, is responsible for the processing its processors carry out, and the EDPB recommends that controllers require vendors to show how their products support compliance.
On enforcement, the guidelines say supervisory authorities may use their Article 58 powers, from warnings and reprimands to fines. They also say the measures a controller took under Articles 25 and 32 are a factor when deciding the size of a fine for other breaches, under Article 83(2)(d). Article 83(4)(a) places Article 25 in the lower tier, with a ceiling of €10 million or 2% of worldwide annual turnover. For decided cases and what regulators looked for, see the implementation guide, which covers them in depth. For the wider law, see our explainer on what the GDPR is.
How privacy by design differs from privacy engineering and security by design
These three are related, and teams mix them up.
- Privacy by design is the approach and the principles. It sets the goal: privacy built in, from the start, as the default.
- Privacy engineering is the technical practice of delivering that goal: choosing architectures, data flows and controls such as pseudonymisation, access control and deletion routines. Our privacy engineering best practices guide goes into the methods.
- Security by design applies the same "build it in" logic to confidentiality, integrity and availability. It protects data from misuse by others. Privacy by design also asks whether you should hold the data at all and how it is used by you. See security by design for the security side.
Put simply, privacy by design is the "what and why" and privacy engineering is the "how." This split is a practical framing, not a legal definition. Article 25 covers both technical and organisational measures, so training, governance and vendor oversight count as much as encryption.
Other laws and standards that point the same way
Not every privacy law uses the phrase, and it is worth being precise.
- GDPR (EU). Article 25, as above.
- LGPD (Brazil). The law does not use the words "privacy by design" or "data protection by design." Article 46, paragraph 2, does require that the security, technical and administrative measures in that article are observed from the conception phase of a product or service until its execution. That is the same idea under another name.
- ISO 31700-1:2023. This is the first international standard on privacy by design for consumer goods and services. ISO describes it as setting high-level requirements for building privacy into consumer products across their lifecycle, including the data the consumer processes. It does not prescribe specific methodologies or technologies. The text is paid, so we cannot summarise its clauses here.
- United States. There is no general federal privacy by design rule. The FTC has recommended the approach, as noted above, but recommendation is different from obligation.
We have not listed other jurisdictions, because several web summaries credit newer laws with privacy by design duties without quoting the text. If a specific law matters to you, read its operative articles.
Short practical steps
Six steps cover the first month. The implementation guide develops each of them for the GDPR.
- Write down the purpose first. For each feature that touches personal data, state the purpose in one sentence before design starts. Anything that does not serve that purpose does not go in.
- Assess risk early. Run a DPIA for processing that is likely to be high risk, and a lighter review for the rest, before you build. The EDPB's own advice is to assess risk before buying or developing any new system.
- Collect less. Remove fields you cannot justify. Our guide to AI data minimization shows how the same test applies to model training and prompts.
- Set the defaults. Make profiles private, tracking off, optional fields optional and retention periods short. Make the settings easy to find and change.
- Protect and limit. Pseudonymise as soon as you no longer need direct identification, encrypt where appropriate, and give access only to people who need it.
- Keep evidence and review. Record why you chose each measure. Re-check older systems too, because Article 25 does not exempt them.
Limits and criticism
Critics argue that the seven principles are high-level and hard to turn into engineering requirements, and that without law or audit behind them, they remain voluntary. That is part of why Article 25 matters: it adds the words "appropriate," "effective" and "state of the art," which regulators can test. Treat the principles as a way to think, and the legal text as the way you will be judged.
Frequently asked questions
Is privacy by design a legal requirement?
Under the GDPR, yes, in the form of data protection by design and by default in Article 25. The seven principles themselves are not law. Outside the EU the answer depends on the jurisdiction, and many laws only recommend the approach or require related security measures.
What are the 7 principles of privacy by design?
They are: proactive not reactive; privacy as the default setting; privacy embedded into design; full functionality, positive-sum not zero-sum; end-to-end security and full lifecycle protection; visibility and transparency; and respect for user privacy. Ann Cavoukian developed them while she was Ontario's Information and Privacy Commissioner.
What is the difference between privacy by design and privacy by default?
Design is about how you build and run processing, so that the data protection principles work effectively. Default is about the starting settings, so that only data necessary for each purpose is processed unless the person chooses otherwise. In the GDPR they are Article 25(1) and Article 25(2).
Does privacy by design apply to small businesses?
Yes. The EDPB states that the obligation applies to all controllers irrespective of size and of the complexity of the processing. What changes with size is the measures that count as appropriate, because the cost of implementation and the risk of the processing are part of the test.
Is privacy by design the same as privacy engineering?
No. Privacy by design is the approach and its principles. Privacy engineering is the technical work of putting it into practice.
What is the fine for breaching Article 25?
Article 83(4) sets the ceiling for breaches of Article 25 at €10 million or, for an undertaking, 2% of total worldwide annual turnover, whichever is higher. Regulators also weigh the measures a controller took under Articles 25 and 32 when they decide fines for other breaches.
Where do I start if I have an existing product?
Review defaults and data collection first, because they are quick to check, then run a risk assessment on the highest-risk processing.
The short version
Privacy by design is a mindset with a legal anchor. Cavoukian's seven principles tell you what good looks like. Article 25 of the GDPR tells you what you owe: effective measures built into the processing, and defaults that process only what is necessary. Secure Privacy is a consent and privacy compliance platform built on the same logic: collect less, default to the protective setting and keep proof. To put the law into practice, read the implementation guide next.
