Definition · Plain-language
Privacy by design
Privacy by design is the practice of embedding data protection into systems, processes and projects from the very outset, rather than adding it afterwards.
The step most authors miss
Doing CRediT right? Don’t stop at the statement.
A CRediT statement credits you inside one paper. The recognition CRediT was built for happens when those roles are tied to you, persistently. Sign in with your ORCID — free — and claim your CRediT contributions on casrai.org, the home of the standard. They become a verified, portable part of your identity, not a line that disappears into one PDF.
Free: claim your contributions, then export a journal-ready CRediT statement, schema.org structured data, JATS XML, CSV or BibTeX — and preview your public profile. A membership publishes that profile publicly and verifies the journals you serve.
The core idea
Privacy by design holds that privacy protections should be considered and built in from the earliest stages of designing a system, product or project, and should operate by default without the individual having to act. The concept was developed and popularised by Ann Cavoukian, then Information and Privacy Commissioner of Ontario, in the 1990s and 2000s. Its central claim is that privacy is best protected proactively, as an engineering and governance default, rather than reactively after problems emerge. This reframes data protection from a compliance afterthought into a design requirement.
Cavoukian’s seven principles
Cavoukian articulated seven foundational principles: privacy should be proactive not reactive, and preventive not remedial; privacy should be the default setting; privacy should be embedded into design; it should offer full functionality in a positive-sum, not zero-sum, way; it should provide end-to-end security across the whole lifecycle; it should be visible and transparent; and it should remain user-centric, respecting individual privacy. Together these principles describe an attitude rather than a checklist, encouraging designers to treat strong privacy and full functionality as compatible rather than competing goals.
Privacy by design in the GDPR
The GDPR gives the concept legal form in Article 25, titled data protection by design and by default. It requires controllers to implement appropriate technical and organisational measures, such as pseudonymisation and data minimisation, both when determining the means of processing and during the processing itself, and to ensure that by default only the personal data necessary for each purpose is processed. For research teams this means considering data protection when designing studies and data pipelines — choosing what to collect, how to secure it and how to minimise identifiability from the start.
Key facts
At a glance
- Definition: embedding data protection into systems and processes from the outset
- Origin: Ann Cavoukian’s seven foundational principles
- GDPR form: Article 25 — data protection by design and by default
- Stance: proactive and preventive, not reactive
- Default: privacy as the default setting, minimal data by default
- Techniques: pseudonymisation, data minimisation, end-to-end security
Common misconceptions
What people often get wrong
Often heard: Privacy by design just means adding privacy features once a system is built.
Actually: Privacy by design means considering and embedding data protection from the earliest design stage, not bolting it on afterwards. Its defining feature is being proactive and preventive rather than a late addition.
Often heard: Privacy by design forces a trade-off between privacy and functionality.
Actually: A core Cavoukian principle is positive-sum, not zero-sum: strong privacy and full functionality are meant to coexist. The approach rejects the idea that protecting privacy necessarily means sacrificing usefulness.
Often heard: Privacy by design is only a theory and has no legal standing.
Actually: The concept is reflected in law: GDPR Article 25 requires data protection by design and by default, making appropriate technical and organisational measures a legal obligation for controllers, not merely good practice.
Going deeper
