Privacy by Design: a practical guide for product teams
The 7 foundational principles, GDPR Art. 25 requirements, and concrete implementation steps for building data protection into your product from day one.
Privacy by Design is a legal requirement under GDPR Art. 25, not just a best practice. Data protection must be considered from the earliest stage of designing a system or process — not retrofitted after launch.
What is Privacy by Design?
Privacy by Design (PbD) is a framework created by Ann Cavoukian (former Ontario Privacy Commissioner) in the 1990s. It established the principle that privacy should be engineered into systems and processes from the start — not treated as an afterthought or compliance checkbox.
The framework was codified as a legal obligation under GDPR Art. 25 as “Data Protection by Design and by Default.” The principle requires controllers to implement appropriate technical and organisational measures — at the time of system design and at the time of processing — to ensure data protection obligations are met from the outset.
In practical terms, this means privacy decisions must be made during architecture discussions, schema design, API specification, and feature planning — not discovered during a legal review after launch.
GDPR Art. 25GDPR Recital 78UK GDPR Art. 25Brazil LGPD Art. 46India DPDP s.8(4)The 7 foundational principles of Privacy by Design
Ann Cavoukian’s original framework established seven principles that underpin the Privacy by Design approach. GDPR Art. 25 and Recital 78 reflect these principles directly.
- 1Proactive not reactiveAddress privacy risks before they occur, not after. Design systems that prevent breaches rather than responding to them.
- 2Privacy as the defaultData protection settings must be on by default. Users should not have to take action to protect their privacy; the strictest setting applies automatically.
- 3Privacy embedded into designPrivacy is not a bolt-on. It must be integrated into the architecture and design of systems from the start — not added at the end.
- 4Full functionalityPrivacy does not require trade-offs with functionality. A Privacy by Design approach seeks win-win outcomes, not zero-sum compromises.
- 5End-to-end lifecycle securityData must be protected throughout its entire lifecycle — from collection to deletion. Secure destruction of data is as important as secure collection.
- 6Visibility and transparencyData practices must be transparent to users and verifiable by regulators. Privacy policies and notices must accurately describe what happens.
- 7Respect for user privacyThe system must be designed to serve the individual user's interests, not just the organisation's. User-centric design, clear consent, and data subject rights must be built in.
GDPR Art. 25 — what it actually requires
Article 25 imposes two distinct but complementary obligations on controllers. Both apply regardless of size — there is no SME exemption.
At the time of determining the means of processing and at the time of processing itself, implement appropriate technical and organisational measures (e.g. pseudonymisation, data minimisation) designed to implement data protection principles effectively.
This means privacy decisions must be made during system design — not retrofitted. The measures must be proportionate to the risks, taking into account the state of the art, the cost of implementation, and the nature and purposes of processing.
Ensure that by default, only personal data necessary for each specific purpose is processed. This obligation applies to the amount of data collected, the extent of processing, the period of storage, and the accessibility of data.
Default settings must be privacy-preserving. Users must actively choose to share more data — the system must not make broad data sharing the path of least resistance.
Violations of Art. 25 fall under Art. 83(4)(a) GDPR: fines of up to €10,000,000 or 2% of global annual turnover, whichever is higher. The UK ICO and multiple EU DPAs have issued enforcement decisions and reprimands citing Art. 25 failures specifically.
Practical implementation for product teams
The following six practices translate Privacy by Design from principle into engineering decisions that can be adopted in sprints and release processes.
Only collect fields you will actually use. Don't add optional fields "in case they're useful later."
Art. 5(1)(c) GDPRUse separate identifiers in logs and analytics. Encrypt personal data at rest and in transit.
Art. 25(1), Art. 32 GDPRLimit who can see personal data. Use least-privilege access. Log all access.
Art. 25(1) GDPRBuild automatic deletion or anonymisation into your system. Don't retain data indefinitely because you haven't decided on retention.
Art. 5(1)(e) GDPRConduct a DPIA for any feature that involves high-risk processing. Build DPIA review into your release checklist.
Art. 35 GDPRMarketing emails off by default, tracking off by default, public profile off by default. Users opt in, not out.
Art. 25(2) GDPRPrivacy Impact Assessments (DPIAs)
A DPIA (Data Protection Impact Assessment) under Art. 35 GDPR is mandatory when processing is likely to result in a high risk to individuals — for example: large-scale processing of special category data, systematic monitoring of public areas, or profiling with significant effects on individuals.
Even when not mandatory, a DPIA is best practice for any new feature involving personal data. Building DPIA review into your standard release checklist is the simplest way to operationalise Privacy by Design at the team level.
Frequently asked questions
Is Privacy by Design a legal requirement?
Yes, under GDPR Art. 25. Data Protection by Design and by Default is a mandatory obligation for controllers. Violations can attract fines of up to €10M or 2% of global annual turnover under Art. 83(4)(a) GDPR. The UK ICO and EU DPAs have issued enforcement decisions citing Art. 25 failures.
What is data minimisation?
Data minimisation (Art. 5(1)(c) GDPR) requires that personal data collected is adequate, relevant, and limited to what is necessary for the specified purpose. In practice: only collect fields you will use, don't retain data longer than needed, and regularly review whether stored data is still necessary.
When is a DPIA required?
A DPIA (Data Protection Impact Assessment) is mandatory under Art. 35 GDPR when processing is likely to result in high risk — including systematic profiling, large-scale processing of special category data, and systematic monitoring of public spaces. The EDPB has published a list of processing operations requiring a mandatory DPIA (Guidelines 09/2022).
Does Privacy by Design apply outside the EU?
The concept has been adopted beyond GDPR. UK GDPR Art. 25 is identical. Brazil's LGPD Art. 46 requires "appropriate technical and administrative measures." India's DPDP Act s.8(4) requires data fiduciaries to implement reasonable security safeguards. The principle of building privacy in from the start is now a global standard.
What is the difference between Privacy by Design and Privacy by Default?
Privacy by Design (Art. 25(1)) requires privacy to be embedded into the technical design of systems from the start. Privacy by Default (Art. 25(2)) requires that default settings expose the minimum amount of personal data — users must opt in to share more, not opt out of sharing less. Both are required by GDPR Art. 25; they are complementary obligations.
Related privacy law guides
Find out which privacy laws apply to your business
Answer 13 questions and get a personalised privacy law checklist with statutory citations — including data protection by design obligations for every applicable law.
Start free assessment →