Privacy by Design: The GDPR Obligation Most Organisations Are Getting Wrong
Article 25, Privacy by Default, and What Enforcement Cases Actually Show
Privacy by design. Every compliance policy references it. Almost no one can describe what it requires in concrete terms, or what a DPA investigator is actually checking when they open an enforcement case.
By January 2026, cumulative GDPR fines since May 2018 had reached €7.1 billion, with data breach notification failures contributing significantly (DLA Piper GDPR Fines and Data Breach Survey, January 2026). Violations of this provision feature in some of the largest individual penalties on record, and the Future of Privacy Forum's enforcement analysis found that it is regularly cited alongside Article 5 principle violations and Article 32 security failures.
What I see, working with organisations on their data protection programs, is that privacy by design tends to exist in the policy and nowhere else. It appears in the DPIA. It is referenced in the privacy notice. The actual system: the architecture, the consent flow, the retention logic, the access controls. Untouched. That is exactly the gap regulators are trained to find. For the broader GDPR compliance picture, see our GDPR compliance guide. This article is specifically about what that obligation requires and how to actually satisfy it.
What Article 25 GDPR Actually Says
TL;DRTL;DR Article 25 GDPR imposes two obligations on every data controller. First, appropriate technical and organisational measures must be implemented by design, at the time of determining the means of processing and at the time of processing itself, to give effect to data protection principles and protect data subjects' rights. Second, the controller must ensure that by default only personal data necessary for each specific purpose is processed. Both obligations are ongoing, not one-time assessments.
The provision is short. It is also one of the most consistently misread in the entire Regulation. The typical misreading goes like this: privacy by design means we need to think about privacy when we design the system. That sounds like reasonable practice. It is not what the article says.
The first paragraph of the article ties the obligation to two specific moments: when you decide how you will process data, and when you are actually processing it. Both. Not one. That means building privacy in before launch is necessary but not sufficient. The measures need to keep working. If the architecture degrades or the retention logic stops running correctly, that is a live compliance failure under this provision, not a historical one.
The EDPB Guidelines 4/2019, adopted in October 2020, are the authoritative source for what compliance looks like in practice. Three things they confirm explicitly: the obligation applies to all controllers, regardless of size; measures must be effective, not merely documented; and controllers must regularly review whether the measures they chose are still working. That last point matters. Documenting that you considered privacy is not the same as implementing measures that protect it. One produces a paper trail. The other produces a compliant system.
Appropriateness is assessed against four factors: state of the art, implementation cost, the nature and scope of the processing, and the risk level. These factors calibrate the obligation, they do not reduce it. A small organisation does not have to implement what a large financial institution would implement. It does have to implement something proportionate to its own risk profile. "We are too small to worry about this" is not a compliant position. It has never been.
Privacy by Default: the Separate Legal Obligation
TL;DRTL;DR Article 25(2) requires controllers to ensure that by default only personal data necessary for each specific purpose is processed. This applies to the amount of data collected, the extent of processing, the storage period, and accessibility. A system that gives users an "accept all" button by default, or that collects data beyond what the stated purpose requires, fails this obligation regardless of whether a privacy notice exists.
Privacy by default gets conflated with privacy by design constantly. They are separate obligations. The design obligation is about architecture. The default obligation is about operational settings: what the system does when the user takes no action.
The default state of any system, absent any action from the user, must be the most privacy-protective option available. Not the most convenient for the controller. Not the option that drives the highest conversion rate on the consent banner. The most protective. That requirement touches consent interfaces, product settings, data collection logic, retention defaults, and access controls.
What privacy by default demands in practice
- Cookie consent interfaces must not pre-tick boxes or present accept-all as the default. The EDPB and national DPAs have made this point consistently.
- Product sign-up flows must not collect fields that are not strictly necessary for the service unless the user actively opts in.
- Newsletter subscriptions, profile visibility, location sharing, and marketing preferences must all default to off.
- Data retention must default to the shortest period justified by the processing purpose. Retaining data indefinitely because deletion has not been configured is a failure of privacy by default.
- Access controls must default to least privilege. Access to personal data should not be available to roles that do not require it for the stated purpose.
The Sambla Group case is worth reading carefully. A Swedish DPA issued a fine specifically under this provision in 2025. Two things drove the penalty: measures were missing from the system outset, and once the organisation identified unsafe processes, it took years to resolve them. That second element is important. Finding a privacy-by-default failure and sitting on it is treated as significantly more serious than not finding it at all.
The Seven Foundational Principles of Privacy by Design
TL;DRTL;DR Ann Cavoukian's seven principles, now embedded in GDPR's privacy by design framework, define what the obligation looks like in operational terms. The EDPB Guidelines confirm that effective implementation of Article 25 requires these principles to be translated into specific technical and organisational measures. Principles alone, without corresponding measures, do not satisfy the obligation.
Ann Cavoukian developed privacy by design in the 1990s. She was the Information and Privacy Commissioner of Ontario, and she built it as a practical framework, not a theoretical one. International data protection authorities adopted it in a 2010 resolution. The GDPR then made it legally binding, incorporating it directly into the regulation. That shift matters. What was once a framework organisations could choose to follow is now an obligation they cannot choose to ignore. The EDPB Guidelines use Cavoukian's seven principles to specify what that obligation looks like in practice.
| Principle | What it requires in practice |
|---|---|
| Proactive, not reactive | Anticipate and prevent privacy risks before they materialise. This means conducting privacy reviews before a product launches, not after a complaint arrives. |
| Privacy as the default setting | The most protective settings apply unless the user actively changes them. Covered separately under Article 25(2). |
| Privacy embedded into design | Privacy controls are core architecture, not bolt-on features. Pseudonymisation, encryption, and access control are designed into the system, not added in response to a DPIA. |
| Full functionality: positive-sum | Privacy and functionality are not traded against each other. A system that works well and protects data is the target, not a compromise between them. |
| End-to-end security | Protection applies across the full data lifecycle, from collection through use, storage, and deletion. A system that encrypts data at rest but transmits it unencrypted does not meet this standard. |
| Visibility and transparency | Users and regulators can verify what the system does with personal data. Documentation, audit logs, and accessible privacy information put this principle into practice. A well-maintained trust center is one practical way to demonstrate this transparency to customers and regulators. |
| Respect for user privacy | The system is designed to serve the data subject's interests. Default settings reflect those interests rather than the controller's data appetite. |
What Enforcement Cases Reveal
TL;DRTL;DR Article 25 violations appear in some of the highest GDPR fines. The Future of Privacy Forum's enforcement analysis found that Article 25 is frequently applied alongside Article 5 principle violations and Article 32 security failures. Regulators look at whether controllers can demonstrate that privacy was embedded before processing began, not just whether policies reference the concept.
The enforcement record here is consistent enough to read as a pattern. Regulators are not hunting for perfect systems. They are looking for a documented process: did you identify the risks before you started? Select proportionate measures? Build them in? Review them after? If you cannot demonstrate all four of those things, you have a problem. Not a potential one. An actual one.
Three enforcement patterns to understand
- 1.Default settings as the primary breach. Amazon's €746 million fine in 2021 involved, among other failures, a consent mechanism that did not reflect privacy-protective defaults. The system was designed to make accepting data processing the path of least resistance. This is the clearest failure mode under the default obligation.
- 2.Architecture decisions that could not be corrected after the fact. Where data collection is built into a system without a legal basis, and the system would require fundamental redesign to remove it, regulators treat this as a design-stage failure rather than an operational error. The cost of redesign is not a mitigating factor.
- 3.Known failures left unresolved. The Sambla Group case is instructive: the fine reflected not just the absence of appropriate measures but the multi-year gap between identifying the problem and resolving it. The obligation is a continuing one. A controller that identifies a privacy-by-design failure and does not act on it faces greater enforcement risk than one that catches and fixes the issue promptly.
Source: Future of Privacy Forum, Unlocking Data Protection by Design and by Default: Lessons from the Enforcement of Article 25 GDPR | DLA Piper GDPR Fines and Data Breach Survey, January 2026
How to Implement Privacy by Design in Practice
TL;DRTL;DR Implementation requires four sequential steps: (1) before development begins, define what data the processing actually requires; (2) during development, build privacy controls into the architecture; (3) at launch, audit every default setting; (4) on an ongoing basis, review whether the measures still work. Each step is described below.
A privacy by design policy does not satisfy this legal obligation. It is evidence that you thought about it. That is not the same as meeting it. What satisfies it are decisions made at four specific points in the product lifecycle, starting before any code is written and continuing after the product goes live.
Before processing begins
Start with a specific question: what personal data does this processing actually need? Not what would be useful. Not what the system currently happens to collect. What it needs. This analysis belongs at the specification stage, not in the DPIA that gets written six months later. Every field in a data collection form, every variable in an analytics pipeline, every attribute in a user profile: documented purpose or it does not exist.
Then identify the applicable risks and the measures that address them. For high-risk processing, that is what the DPIA is for. Lower-risk activities need proportionately lighter analysis, but not no analysis.
During development
Privacy controls belong in the architecture, not in the policy folder. Pseudonymisation means structural separation at the schema level. Organisations subject to UK GDPR requirements face the same obligation under the UK's retained version of Article 25, not a setting someone could theoretically enable. Retention means automated deletion pipelines with defined triggers, not a quarterly review cycle that everyone knows will not run. Access controls mean permissions enforced at the application layer. A policy that says access is restricted does not restrict access. The technical measure does.
For organisations deploying third-party tools and SaaS products: that obligation extends to how you configure those tools. Connecting a CRM to an analytics platform without reviewing what data gets shared, and on what basis, is not consistent with privacy by design. That is a configuration decision with legal consequences. For more on managing data protection obligations across vendor relationships, see our GDPR vendor management guide.
At launch: the default settings audit
Before launch: go through every user-facing setting and every backend process and ask one question. What happens if the user does nothing? That is your default. Under the default obligation, it must be the most privacy-protective option. Run through it for consent interfaces, marketing preferences, data sharing toggles, profile visibility, notification settings. Every one of them.
The launch audit is also the moment to compare what the system actually collects against the minimisation analysis done at the specification stage. In practice, they rarely match. Product development adds features. Features bring new data fields. By the time you reach launch, the system usually collects more than was in the original plan, and nobody has gone back to check whether the additional collection is justified.
Ongoing: effectiveness review
The obligation does not end at launch. Regular review of whether the chosen measures are still effective is not optional. A retention pipeline built at launch often breaks silently when a new data category is introduced six months in. An access control model designed for three people rarely scales correctly when the organisation grows. Both are compliance failures under this provision, regardless of whether the original implementation was correct at the time. For a practical framework for documenting and reviewing your processing activities, see our ROPA guide.
Whisperly's GDPR compliance platform supports the ongoing review cycle by maintaining a structured record of processing activities, linking DPIAs to the relevant processing activities, and tracking the technical and organisational measures documented at the assessment stage. Book a demo to see how it works in practice.
Privacy by design documentation is reviewed as part of a broader GDPR compliance audit. For the full 12-area checklist regulators examine, see our GDPR audit readiness guide.
Further Reading on Whisperly
Questions & Answers
What is privacy by design under GDPR?+
Privacy by design is the legal obligation under Article 25 GDPR to build data protection into processing from the outset, not bolt it on afterwards. Controllers must implement appropriate technical and organisational measures before processing begins, and keep reviewing whether those measures are still working throughout the lifecycle. The separate obligation under Article 25(2), privacy by default, requires that the system's default state, absent any user action, is the most privacy-protective option available. For the broader GDPR compliance context, see our GDPR compliance guide.
Who does the privacy by design obligation apply to?+
The obligation under Article 25 applies to every data controller, regardless of size or the complexity of their processing operations. The EDPB Guidelines 4/2019 confirm explicitly that it applies to all controllers irrespective of size. The proportionality principle means that the measures required are scaled to the risk, not that small organisations are exempt.
Does having a DPIA satisfy the Article 25 obligation?+
No. A DPIA documents the risk analysis that should inform design decisions. It does not constitute implementation. The DPIA identifies the risks and the measures that would address them. The regulation requires that those measures are then actually built into the system.
What does privacy by default mean in practice?+
Privacy by default means the system's default state, with no action from the user, must be the most privacy-protective available. In practice: consent checkboxes start unticked; sign-up forms do not request data the service does not use; retention defaults to the shortest period the purpose justifies; marketing and sharing preferences start off; access to personal data is limited by default to the roles that need it.
How do regulators assess compliance with Article 25?+
The Future of Privacy Forum's enforcement analysis found that violations of this provision tend to appear alongside Article 5 principle failures. Regulators look at whether controllers can demonstrate that privacy was embedded before processing began, not just whether policies reference the concept. When regulators see a design-stage failure, they tend to look wider, not stop at the initial finding.
Written by
Marta Lukovic
Marta Luković is an Attorney at Law specialising in Data Protection, IT Law, and AI Law. She advises companies across Southeast Europe on GDPR compliance, cross-border data transfers, and regulatory risk management. Recognised for her practical, commercially aware approach to privacy law, she works closely with technology companies navigating complex regulatory environments across multiple jurisdictions.
Reviewed by: Tijana Zunic, Attorney at Law, AI Law and Data Protection Specialist