Data protection by design means building privacy controls into a product from the first design decision, not bolting them on before launch. Article 25 of the GDPR makes it a legal requirement: you must apply data minimisation, purpose limitation and protective defaults by design and by default, and be able to show you did.
What does data protection by design and by default mean under Article 25?
Article 25 of the GDPR (Regulation (EU) 2016/679) sets two linked obligations. Data protection by design means putting appropriate technical and organisational measures into your processing from the outset, so that the data protection principles are built into how a system works. Data protection by default means that, without any action from the user, you only process the personal data necessary for each specific purpose.
In practice “by default” governs how much you collect, how long you keep it, how widely it is shared and how accessible it is. A profile that is private until a user chooses to make it public is the default working correctly. A profile that is public until someone finds the setting to lock it down is not. The same logic applies to retention periods, optional fields and data shared with third parties: the privacy-protective option is the starting state, not the reward for digging through settings.
Article 25 is risk-based. What counts as appropriate depends on the state of the art, the cost of implementation, and the nature, scope, context and purposes of your processing, weighed against the risk to the people whose data you hold. A small team handling low-risk contact data is held to a different standard than one processing health records at scale, but both have to show they considered the question.
Where did privacy by design come from and how does it relate?
Privacy by design is the older idea that Article 25 turned into law. It was developed in the 1990s by Ann Cavoukian, then Information and Privacy Commissioner of Ontario, as a set of principles arguing that privacy should be the default condition of a system and embedded throughout its lifecycle, rather than traded off against functionality. For years it was good practice that no one was obliged to follow.
The GDPR codified that thinking. When people say “privacy by design” in a GDPR context today, they are usually pointing at the same obligation Article 25 calls data protection by design and by default. The wording shifted from “privacy” to “data protection” because that is the language of EU law, but the substance is continuous: anticipate the privacy impact, design to reduce it, and make the protective choice the standard one. The European Data Protection Board’s Guidelines 4/2019 on Article 25 set out how regulators expect this to be applied.
How do you build data protection by design into the product lifecycle?
The practical work is to move the privacy questions earlier, so they shape the design instead of constraining a finished product. Article 25 does not prescribe a method, but the obligation maps onto the stages most product teams already have.
- Discovery and design. Decide what personal data each feature genuinely needs and for what purpose, then design out the rest. Most over-collection is decided here, in a schema or a form, long before any code is written.
- Build. Apply the measures the design called for: encryption in transit and at rest, pseudonymisation where it fits, role-based access so staff only reach the data their job requires, and retention rules that delete data when its purpose ends.
- Test. Use synthetic or anonymised data in test environments rather than copies of live personal data. Check that the privacy-protective defaults actually hold and that access controls do what the design said.
- Release and operate. Confirm default settings are protective at launch, give users clear control over their own data, and review the processing as the product changes. A new integration or analytics feature can quietly undo a default that was correct at launch.
This is also a cross-functional duty, not an engineering one. Product, legal and the people who design the user experience all make decisions that affect privacy, so the questions have to reach them too. Where you have a Data Protection Officer, Article 25 is a natural point to involve them early. Starting late is the expensive path: retrofitting data minimisation or consent into a shipped product usually means reworking schemas and flows that were never built to support them.
When does a feature trigger a DPIA?
A Data Protection Impact Assessment is the formal version of designing privacy in, required under Article 35 of the GDPR. You have to carry one out where a type of processing is likely to result in a high risk to the rights and freedoms of individuals, and you do it before the processing begins, while you can still change the design.
The GDPR names situations that point to high risk, including large-scale processing of special category data such as health, biometric or other sensitive information; systematic and extensive profiling that produces legal or similarly significant effects; systematic monitoring of a publicly accessible area; and the use of new technologies. Supervisory authorities also publish their own lists of operations that require a DPIA. If you are unsure whether a feature crosses the line, the safer course is to screen it: a short assessment that concludes the risk is low is itself useful evidence.
A DPIA describes the processing, assesses whether it is necessary and proportionate, identifies the risks to individuals and sets out the measures to address them. Done at the right moment it is design input, not paperwork: it tells you what to build differently before anything ships.
What are the practical patterns and anti-patterns?
The difference between compliance and exposure usually comes down to specific design choices. The patterns below recur across products that get Article 25 right, and the anti-patterns across those that draw regulator attention.
| Pattern | Anti-pattern |
|---|---|
| Collect the minimum fields a feature needs | Collect everything “in case it’s useful later” |
| Private and opt-in by default; sharing is a choice | Public and opt-out by default; privacy is buried in settings |
| Retention rules that delete data when its purpose ends | Indefinite retention with no deletion path |
| Anonymised or synthetic data in test environments | Live personal data copied into staging and dev |
| Role-based access limited to what each job needs | Broad access because narrowing it is inconvenient |
| Granular, specific, informed consent where consent is the basis | Bundled consent and pre-ticked boxes |
Two anti-patterns deserve particular attention because they tend to slip through. The first is unvetted third-party components: Article 25 reaches the processors and SDKs you build on, so a tracking library or analytics tool that over-collects becomes your problem, not the vendor’s. The second is the default that drifts. A setting that was protective at launch can be quietly reversed by a later feature, which is why defaults belong in your review checklist and not just your launch checklist.
How Atoro helps
Atoro builds and runs GDPR programmes for scaling SaaS companies, which means translating Article 25 into the actual design and engineering decisions your team is making rather than handing over a policy document. We cover this in our GDPR implementation service, provide an outsourced Data Protection Officer through virtual DPO services, and have a focused guide to GDPR compliance for small businesses for earlier-stage teams.
Data protection by design FAQs
What is the difference between data protection by design and privacy by design?
Privacy by design is the original principle, developed by Ann Cavoukian in the 1990s, that privacy should be built into systems by default. Data protection by design is the legal obligation in Article 25 of the GDPR that codified it. In a GDPR context the two terms point at the same requirement.
What does data protection by default mean?
It means that, without any action from the user, your product only processes the personal data necessary for each specific purpose. The privacy-protective option, such as a private profile or a short retention period, is the starting state rather than something a user has to switch on.
Is data protection by design a legal requirement?
Yes. Article 25 of the GDPR (Regulation (EU) 2016/679) requires data protection by design and by default. You must apply appropriate technical and organisational measures from the outset and be able to demonstrate that you did.
When is a DPIA required?
Under Article 35 of the GDPR, a Data Protection Impact Assessment is required where processing is likely to result in a high risk to individuals. Examples include large-scale processing of special category data, systematic monitoring of a public area, extensive profiling with significant effects, and the use of new technologies.
What are the core principles behind data protection by design?
Data minimisation (collect only what you need), purpose limitation (use it only for the purpose you collected it for) and protective defaults are central. Article 25 ties these to measures such as encryption, pseudonymisation and access control applied from the design stage onwards.
When should we start thinking about data protection by design?
At the discovery and design stage, before the data model is fixed. Most over-collection is decided in a schema or a form, so the cheapest time to apply data minimisation is before any code is written. Retrofitting privacy into a shipped product usually means reworking the things it was built on.
Does data protection by design apply to third-party tools and processors?
Yes. Article 25 reaches the processors, SDKs and components you build on. An analytics tool or library that over-collects personal data becomes your responsibility, so third parties should be vetted and you should use only processors who provide sufficient guarantees.
Who is responsible for data protection by design within a company?
It is a cross-functional responsibility. Engineering, product, legal and user-experience teams all make decisions that affect privacy. Where an organisation has a Data Protection Officer, they should be involved early, but accountability for building it in sits across the teams that design and ship the product.