Privacy by Design
Follow topic LLM context A cited markdown file you can paste into your AI assistant (ChatGPT, Claude, a RAG or project knowledge base) to ground it in this topic. Contains: the overview, key law text, case law, enforcement and guidance for this topic. Everything links back to its source on overview.legal — legal information, not advice.Embedding data protection into system design from the outset
Overview
24 sources · Jul 23, 2026Legal Framework
The primary governing provision is Article 25 GDPR, which imposes two distinct but related obligations: data protection by design (paragraph 1) and data protection by default (paragraph 2). The controller must implement appropriate technical and organisational measures at two stages — both when determining the means of processing and during the processing itself. The article requires a contextual, risk-based assessment:
"Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation"
— GDPR Art. 25(1)
Paragraph 2 adds the by default dimension: by default, only data necessary for each specific purpose may be processed. This applies to the amount collected, the extent of processing, the storage period, and accessibility. The default setting must ensure that personal data are not made accessible to an indefinite number of persons without the individual's intervention.
Recital 78 elaborates on these measures, listing minimisation, pseudonymisation, transparency, and enabling data-subject monitoring as concrete examples. Article 47(2)(d) reinforces that data protection by design and by default must be embedded in binding corporate rules for international transfers.
Key Developments
The CJEU's December 2025 judgment in X v Russmedia Digital SRL confirms that Article 25 is not merely aspirational but operational. The Court restated the provision verbatim and then applied it to an online marketplace operator, holding that:
"Article 25(1) of the GDPR requires that the controller must, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures that are designed to implement data-protection principles in an effective manner and to integrate the necessary safeguards into the processing"
— CJEU, X v Russmedia Digital, ¶89
This signals that controllers cannot defer data-protection considerations to a post-hoc compliance layer; the design phase is where the obligation bites. The Court further tied Article 25(2) to accessibility controls, emphasising that default settings must prevent unrestricted exposure of personal data.
At the enforcement level, the Italian Garante fined the Calabrian Regional Agency €50,000 for a remote-work system that failed to embed privacy safeguards by design, while the Spanish AEPD addressed failures in identity verification design in its DIGI Telecom decision. The EDPB's Guidelines 01/2021 connect Article 25 to breach preparedness, noting that by-design analysis should feed into a controller's personal data breach handbook, ensuring faster incident response.
Status of the Debate
Privacy by Design is actively litigated but doctrinally unsettled at the margins. The core obligation — that controllers must embed data-protection principles from the design stage — is firmly established in the GDPR text and confirmed by the CJEU in Russmedia. What remains contested is the threshold of appropriateness: how much technical or organisational effort is "appropriate" given state-of-the-art, cost, and risk. Courts and DPAs diverge on whether generic measures suffice or whether controllers must demonstrate specific, documented design choices for each processing operation. No court split is formally on record, but the WAMCA proceedings against Google illustrate that collective actions increasingly target design-level failures — excessive data collection, cross-service bundling, and tracking-by-default — as Article 25 breaches. What would resolve the open question is a CJEU reference explicitly addressing the proportionality calculus under Article 25(1) and the standard of proof for compliance.
Practical Guidance
- Document design decisions at the outset. Article 25(1) requires measures at the time of determining processing means. Maintain a design-phase record showing which data-protection principles were considered, what measures were chosen, and why alternatives were rejected. This documentation is your primary defence.
- Configure default settings restrictively. Article 25(2) demands that by default only necessary data are processed. Audit every system for default data collection scope, retention period, and access permissions — each must be set to the minimum necessary for the stated purpose.
- Involve the DPO early in system design. Recital 78 and the Article 29 Working Party framework require that the DPO be engaged before design decisions are locked in, not after deployment.
- Use certification as evidence. Article 25(3) expressly permits approved certification mechanisms under Article 42 to demonstrate compliance — pursue relevant certifications where available to shift the burden of proof.
- Integrate by-design analysis into breach response. The EDPB recommends that design-phase analysis feed directly into a personal data breach handbook, ensuring that when incidents occur, the organisation can respond swiftly with pre-mapped risks and mitigation paths.