Fiche 41/54 Part 5 — Operational Obligations & Sanctions Advanced Reviewed 2026-08-23

Data Protection by Design & by Default (Art. 25)

Article 25 imposes two proactive obligations: integrating technical safeguards from early system architecture (by Design) and configuring the most protective settings by default without requiring user

Open in interactive reader

⚖️ Architectural Mandate 📋 EDPB Guidelines 4/2019

Data Protection by Design & by Default (Art. 25)

⚡ In 30 seconds

Under Article 25, data protection cannot be an afterthought. Data protection by design (Art. 25.1) requires controllers to implement technical and organisational measures (e.g. pseudonymisation) at the time of system determination and processing. Data protection by default (Art. 25.2) requires that by default, only personal data necessary for each specific purpose are processed.

By Design (Architecture)

Proactive integration from the earliest conceptual design phase: field-level encryption, data segregation, automated pseudonymisation, audit logs.

By Default (Configuration)

Strict baseline settings: public profiles disabled by default, minimal data collection, non-essential tracking disabled, shortest retention applied.

⚡ Key Takeaways

By default settings ensure data is not made accessible without the individual's intervention to an indefinite number of persons.
State of the art benchmark: architectures must evolve with emerging cryptographic and privacy-enhancing technologies.
Failure to build privacy into software pipelines constitutes an actionable breach of Article 25.

⚠️ Common Pitfall

Using pre-checked profile visibility toggles that broadcast user location or contact lists by default.

🛠️ In Practice

Add explicit privacy verification criteria to developer acceptance criteria and QA testing pipelines.

⚖️ Official Sources: Art. 25 GDPR · Recital 78 · EDPB Guidelines 4/2019 on Article 25 ✓ Legal review: 23 August 2026