Privacy by Design and Privacy by Default are not aspirational concepts or optional best practices under the GDPR. They are binding legal obligations set out in Article 25 that require organisations to embed data protection into the architecture of their systems, products, services, and business processes. For many businesses, compliance with Article 25 is one of the clearest indicators regulators use to assess whether data protection is being taken seriously at an organisational level.
This page explains what Privacy by Design and Privacy by Default mean in practice, how Article 25 operates within the wider GDPR framework, and what businesses are expected to do to demonstrate compliance. It also explores how these obligations apply across the lifecycle of products and services, from early design decisions through to decommissioning, and why failures under Article 25 increasingly sit at the heart of regulatory enforcement.
The Legal Framework of Article 25 GDPR
Article 25 of the GDPR establishes two closely related but distinct obligations: data protection by design and data protection by default. These obligations apply to all controllers and to all processing of personal data, regardless of the size of the organisation or the technology involved.
Article 25(1) requires controllers to implement appropriate technical and organisational measures designed to integrate data protection principles into processing activities. This obligation applies both when determining the means of processing and during the processing itself. Article 25(2) requires controllers to ensure that, by default, only personal data that is necessary for a specific purpose is processed. Article 25(3) provides that certification mechanisms may be used as a means of demonstrating compliance.
These obligations must be interpreted in light of Recital 78 of the GDPR, which emphasises that controllers should adopt internal policies and technical measures that meet data protection principles and protect the rights of individuals. Article 25 also sits alongside the general accountability obligation in Article 24, requiring controllers not only to comply, but to be able to demonstrate compliance.
Privacy by Design: A Proactive Legal Obligation
Privacy by Design is the requirement to embed data protection into the design and development of processing activities, rather than adding it after systems or products are already in use. It requires organisations to consider privacy and data protection at the earliest stages of decision-making, including when new systems are designed, new products are developed, or existing processes are materially changed.
This obligation applies at the moment when decisions are made about how personal data will be processed. Once core architectural choices have been made, it is often difficult or costly to retrofit safeguards. Regulators therefore expect data protection considerations to be integrated into early planning, procurement, and design phases, and to be maintained throughout the lifecycle of the processing.
Privacy by Design is not a single technical measure. It is an approach that requires organisations to embed the data protection principles set out in Article 5 of the GDPR into how processing operates in practice. This includes lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity, confidentiality, and accountability. The obligation is continuous and evolves as processing evolves.
Privacy by Default: Limiting Processing through Default Settings
Privacy by Default complements Privacy by Design by focusing on the configuration and operation of systems. It requires organisations to ensure that, by default, only the personal data necessary for a specific purpose is processed. This obligation applies to the amount of data collected, the extent of processing, the length of time data is retained, and how accessible data is by default.
In practical terms, Privacy by Default requires organisations to design systems so that unnecessary processing does not occur unless a deliberate and justified choice is made to change defaults. This does not mean that all processing must be switched off by default. Rather, it requires proportionate default settings that reflect the specific purpose of the processing and the risks to individuals.
Defaults play a significant role in shaping behaviour, particularly in digital products and online services. Regulators are increasingly concerned with default settings that expose personal data more widely than necessary, retain data indefinitely without justification, or enable secondary uses that are not aligned with original purposes. Privacy by Default requires organisations to actively resist these patterns.
A Risk-Based and Contextual Obligation
Article 25 does not mandate identical measures for all organisations or processing activities. Instead, it adopts a risk-based approach. Controllers must take into account the nature, scope, context, and purposes of the processing, as well as the likelihood and severity of risks to individuals’ rights and freedoms. They must also consider the state of the art and the cost of implementation.
This means that what is appropriate for a low-risk internal processing activity may not be sufficient for a large-scale consumer-facing platform or a system involving profiling, artificial intelligence, or automated decision-making. Regulators do not expect unrealistic or disproportionate measures, but they do expect organisations to justify why the measures they have chosen are appropriate in light of the risks involved.
Cost considerations are relevant, but they are not decisive. Organisations cannot rely on cost alone to justify weak protections where risks to individuals are high. Equally, the “state of the art” evolves over time, meaning that measures considered sufficient at one point may need to be revisited as technology and expectations change.
Implementing Data Protection Principles through Design and Default
Privacy by Design and Privacy by Default operate by embedding the data protection principles into the technical and organisational fabric of processing.
Designing for lawfulness, fairness, and transparency requires organisations to build lawful basis decisions into systems and workflows, rather than treating them as documentation exercises that sit outside operational reality. Transparency should be supported through system functionality, such as meaningful user interfaces, layered information, and traceable processing logic.
Purpose limitation must be reflected in system architecture. This includes preventing function creep by restricting internal access to data, separating datasets where appropriate, and ensuring that changes in purpose trigger reassessment rather than silent expansion of use.
Data minimisation is a central theme of Article 25. Systems should be designed to collect and process only the data genuinely needed for a defined purpose. Optional fields, staged data collection, and clear retention logic are all indicators regulators look for when assessing compliance.
Accuracy and storage limitation should also be supported by design. This may include built-in correction mechanisms, automated retention and deletion workflows, and controls that prevent data being retained indefinitely without justification.
Technical and Organisational Measures under Article 25
Compliance with Article 25 requires both technical and organisational measures. Technical measures may include pseudonymisation, encryption, role-based access controls, secure logging, and system configurations that enforce restrictive defaults. Privacy-enhancing technologies can play a role, but they are not sufficient on their own.
Organisational measures are equally important. These include governance frameworks that assign responsibility for privacy decisions, internal policies that guide design and development, training programmes that ensure relevant teams understand their obligations, and approval processes that integrate data protection checks into project lifecycles.
Regulators consistently emphasise that policies without technical implementation, or technical controls without governance and oversight, are insufficient. Article 25 requires effective measures, not merely formal ones.
Applying Privacy by Design Across the Data Lifecycle
Privacy by Design applies across the entire lifecycle of processing. It begins during concept and planning stages, continues through development and testing, applies during deployment and operation, and remains relevant during changes, updates, and eventual decommissioning.
During procurement, organisations must assess whether vendors and systems can support compliance with Article 25. Selecting tools that cannot be configured to support data minimisation or appropriate defaults creates risk that cannot be transferred to suppliers.
During development and testing, organisations should ensure that test environments do not rely on live personal data without safeguards, and that access controls and logging are in place before systems go live.
During operation, organisations must monitor whether design assumptions remain valid. Changes in functionality, user base, or regulatory expectations may require updates to technical and organisational measures.
At the end of a system’s lifecycle, Privacy by Design requires data to be securely deleted or anonymised, and access to be terminated.
The Relationship Between Article 25 and Data Protection Impact Assessments
Data protection impact assessments and Privacy by Design serve different but related purposes. A data protection impact assessment is a structured risk assessment required for certain high-risk processing activities. Privacy by Design is an ongoing obligation to implement safeguards that address identified risks.
In practice, a data protection impact assessment often acts as a diagnostic tool that informs design decisions. Where risks are identified, Article 25 requires those risks to be mitigated through concrete technical and organisational measures. Conducting an assessment without implementing design changes is unlikely to satisfy regulatory expectations.
Controllers, Processors, and Shared Responsibility
Article 25 places responsibility squarely on controllers. Controllers cannot shift their obligations to processors or technology suppliers. However, processors and vendors play a critical role in enabling compliance.
Controllers are expected to select processors that offer systems and services capable of supporting data protection by design and default. Contractual arrangements should reflect these expectations, including obligations on suppliers to maintain state-of-the-art measures and to inform controllers of relevant changes.
Regulators increasingly scrutinise situations where controllers rely on products that inherently undermine compliance with Article 25, particularly in areas such as online tracking, profiling, and artificial intelligence.
Enforcement Trends and Regulatory Focus
Supervisory authorities increasingly treat Article 25 as a foundational obligation. Failures under Article 25 often underpin findings of non-compliance with multiple GDPR principles. Regulators have criticised organisations that rely on privacy policies and documentation while ignoring structural design flaws in systems and products.
There is also growing attention on default settings, user interface design, and the role of so-called dark patterns. Where design choices steer users toward unnecessary data sharing, regulators may view this as a failure of Privacy by Default.
In some jurisdictions, supervisory authorities and courts have also begun to explore the link between failures under Article 25 and claims for non-material damage, reflecting the broader regulatory significance of these obligations.
Common Failures in Practice
Common shortcomings include treating privacy as a post-launch compliance exercise, failing to involve privacy expertise in product and system design, relying on policies rather than enforceable controls, and neglecting to revisit design assumptions as products evolve.
Another frequent issue is the misalignment of default settings with stated purposes, particularly where systems are configured for maximum data collection rather than necessity.
The Business and Strategic Value of Privacy by Design and Default
Beyond legal compliance, effective Privacy by Design and Privacy by Default reduce remediation costs, strengthen resilience to regulatory scrutiny, and support trust with customers, users, and business partners. Organisations that embed privacy into design often experience fewer last-minute compliance crises and greater operational clarity around data use.
In procurement and partnership contexts, demonstrable compliance with Article 25 can also operate as a competitive differentiator.
How We Advise on Article 25 Compliance
We advise organisations on embedding Privacy by Design and Privacy by Default into their governance, product development, and system architecture. Our work includes design and maturity assessments, review of products and services, integration of data protection impact assessments into development processes, vendor and contractual support, and assistance in responding to regulatory investigations.
Our focus is on translating legal obligations into practical, defensible measures that work in real operational environments.
Conclusion
Privacy by Design and Privacy by Default sit at the core of the GDPR’s preventative and risk-based approach to data protection. Article 25 requires organisations to move beyond reactive compliance and to embed privacy into how they design and operate.