GDPR Art.25: Data Protection by Design and by Default
What This Control Requires
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, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.
In Plain Language
Retrofitting privacy into a system that wasn't designed for it is expensive, painful, and rarely works well. Article 25 says: build it in from the start. Every new system, product, or feature should have data protection baked into its architecture from day one, not patched on after launch when a regulator comes knocking.
The "by default" side is equally important. Your systems should ship with the strictest privacy settings out of the box. Only collect what's necessary. Don't make profiles public unless someone actively chooses that. Default to opt-out for marketing. Minimise retention periods. Users shouldn't have to hunt through settings menus to protect their privacy - privacy should be the starting position.
Taken together, these two requirements mean you need to embed the GDPR's core principles - lawfulness, purpose limitation, data minimisation, accuracy, storage limitation, integrity, and confidentiality - into how you actually build and configure things. The EDPB has published detailed guidance on what this looks like in practice, so it's a concrete, enforceable obligation rather than a vague aspiration.
How to Implement
Weave data protection into your project management and development lifecycle. Require privacy impact assessments at the design stage of every new system, product, feature, or processing activity. Build privacy checklists and review gates into your project milestones. Make sure product, engineering, and business teams all understand what Article 25 expects of them - this isn't just a DPO concern.
Build technical measures that embed privacy principles into your architecture. Pseudonymisation and anonymisation capabilities, privacy-preserving default configurations, granular consent management in the UI, automated data retention and deletion, least-privilege access controls, and data minimisation at the schema and API level. Think about what data you actually need before you design the database, not after.
Set every system and product to privacy-protective defaults. Minimum data collection with optional fields clearly marked. Privacy settings at their most restrictive. Profiles set to private. Marketing set to opt-in. Data sharing disabled. Let users loosen these settings if they want to, but make privacy the starting point.
Create reusable privacy design patterns for common scenarios - user registration, consent collection, data export, account deletion, age verification. Make them easy for development teams to find and use. Requiring these patterns in relevant projects is far more effective than writing another policy document nobody reads.
Document your design decisions for accountability. Record the privacy considerations you assessed at each design stage, what measures you implemented, your rationale, and any trade-offs you weighed. Keep these records alongside your project documentation. Periodically review live systems to confirm that the privacy-by-design measures are actually working as intended.
Evidence Your Auditor Will Request
- Privacy impact assessment templates and completed assessments for new projects
- System design documentation showing integration of data protection measures
- Evidence of privacy-protective default configurations in systems and products
- Privacy design patterns library and evidence of adoption by development teams
- Project management framework showing privacy review gates at key milestones
Common Mistakes
- Data protection considered only after system design is complete, making changes costly and difficult
- Default settings favour data collection and sharing rather than privacy protection
- No formal process for assessing data protection implications during system design
- Privacy features deprioritised in favour of business features in development roadmaps
- Consent mechanisms designed to encourage maximum opt-in rather than genuinely informed choice
Related Controls Across Frameworks
Frequently Asked Questions
Does 'by design' mean every system must be custom-built for privacy?
What does 'state of the art' mean in this context?
Does data protection by default mean we cannot collect any optional data?
Track GDPR compliance in one place
AuditFront helps you manage every GDPR control, collect evidence, and stay audit-ready.
Start Free Assessment