VOCABULARY / ENTRY
Privacy by Design
privacy-by-design
Make privacy protection the default mode of operation for systems and business processes, embedded at design time rather than bolted on afterwards: if a person does nothing, their personal data stays protected; by default only the data necessary for the stated purpose is processed; and the purpose is explained at the point of collection and not extended beyond it.
Recognizing it
- The default state is the most protective reasonable option, with no action required from the user
- The purpose is stated where data is collected, and only the data needed for that purpose is collected
- Entry points to inspect, withdraw, and adjust data processing are as easy to reach as the features themselves
Concept boundary
It is a philosophy that runs through the design process, not a checklist of consent banners or privacy switches; more toggles do not mean protected by default. It is also not the same as security: security is about keeping data from unauthorized access, while privacy by design also asks whether data should be collected at all, how much, and for what. Cavoukian explicitly treats "privacy versus security" as a false dichotomy to avoid; both should hold. It is related to but not identical with GDPR Article 25 "data protection by design and by default": that is a legal obligation on controllers, whereas this entry describes a design orientation.
When to consider it
- The product needs personal data such as location, contacts, or activity records to provide its features
- Defining the default settings and first-run flow of a new feature
- The product serves markets governed by regulations such as the GDPR and must show that data protection was considered at design time
When to be cautious
- Treating a consent dialog added before launch as having implemented privacy by design
- Using "privacy" as a reason to push every data-processing judgment and its labor onto the user, item by item
- Substituting a passed security audit for scrutiny of whether collection is necessary and what it is for
Tradeoff
Protective defaults and data minimization can reduce the data available for personalization, analytics, and growth, and some features will need to be switched on by the user; Cavoukian argues for positive-sum rather than zero-sum, but each specific feature still has to justify whether its data needs are genuinely necessary.
Conditional rules · Editorial advice
Related entries
Making exit harder than entry directly contradicts the principle that withdrawing should be as easy as giving, turning privacy by design into the obstruction anti-pattern.
Purposes not stated at the point of collection and fees that appear late are both "late disclosures" that undermine informed decisions.
Protective defaults reduce how often users must be interrupted by permission requests; the remaining requests should appear when genuinely needed and explain why.
Sources and what they support
Lists the seven foundational principles: "privacy as the default setting" requires that privacy remains intact when the person does nothing, "privacy embedded into design" rejects bolting it on afterwards, and "positive-sum, not zero-sum" treats privacy versus security as a false dichotomy. The original is an IPC Ontario document published in 2009 and revised in 2011; this check used the copy hosted by SFU.
Retrieved: 2026-09-15 · Archived 2026-09-01Article 25(2) requires controllers to ensure that, by default, only personal data necessary for each specific purpose are processed, covering the amount collected, the extent of processing, the storage period, and accessibility; supports this entry's default-setting rule and data-minimization recommendation.
Retrieved: 2026-09-15Principle 2.2.1 restricts transferred data to what is necessary for the user's goals; 2.10.1 and 2.10.2 require stating the purpose when accessing data and not using it for other purposes; 2.12.3 says checking, withdrawing consent, or opting out should be as easy as giving consent; 1.1.1 argues for privacy-protective defaults to reduce "privacy labour".
Retrieved: 2026-09-15 · Archived 2026-09-20Definitions reference these sources. Digital specimens, selection advice, relationships, and recipes are editorial work and have not been validated through user research.
Type extensions and implementation notes
No operable specimen yet; the illustration is editorial. When applied to a product, still verify that each default really is the most protective reasonable option, that collection points state their purpose, and that the withdrawal path has no more steps than the opt-in path; regulatory compliance must be assessed separately by legal professionals.
{
"values": [
"Protected by default",
"Data minimization",
"Purpose transparency"
],
"tension": "Protective defaults versus data-driven features and growth",
"questions": [
"If the user does nothing, what data is collected, and for what?",
"Is turning this data collection off as easy as turning it on?"
]
}Open the Agent JSON file for this entryThis file repeats every field of this entry verbatim and adds its sources, archive status, and editorial scope.