Article 25

Data protection by design and by default

Chapter 4 | Controller and Processor | 📖 4 min read

1. 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.

2. The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons.

3. An approved certification mechanism pursuant to Article 42 may be used as an element to demonstrate compliance with the requirements set out in paragraphs 1 and 2.

Understanding This Article

Article 25 introduces two fundamental concepts that shift data protection from reactive compliance to proactive design: data protection by design and data protection by default. Together, they require privacy to be built into systems and processes from the ground up.

Paragraph 1 - Data Protection by Design:

Controllers must implement data protection measures at two critical stages:

At determination of means: When designing systems, services, or processing operations
At time of processing: During actual processing activities

Measures must:

Implement data protection principles (particularly data minimization) effectively
Integrate necessary safeguards into processing
Consider state of the art (current best practices and technologies)
Balance costs against processing risks
Account for nature, scope, context, and purposes

Pseudonymization is explicitly mentioned as an example measure that separates data from direct identifiers.

Paragraph 2 - Data Protection by Default:

By default (without user action), systems must ensure only necessary personal data is processed regarding four dimensions:

Amount collected: Don't collect data you don't need
Extent of processing: Don't process more than necessary
Storage period: Don't keep data longer than needed
Accessibility: Don't make data accessible to more people than necessary

Critically, personal data should not be made accessible to indefinite numbers of people by default - users must explicitly choose to make data public.

Paragraph 3 - Compliance Demonstration:

Certification mechanisms (Article 42) can demonstrate compliance with these requirements.

Key Points

Data protection must be integrated from design phase through entire processing lifecycle
Technical and organizational measures must implement GDPR principles effectively
By default, only necessary data should be collected, processed, stored, and made accessible
Consider state of the art, costs, nature, scope, context, purposes, and risks
Data should not be made accessible to indefinite numbers of people by default
Pseudonymization is specifically mentioned as an appropriate measure

Practical Application

Privacy by Design Examples:

Example 1 - Social Media Platform:

Bad: Posts are public by default, full profile visible to everyone, location tracking always on
Good: Posts default to friends-only, privacy controls prominent during signup, location tracking opt-in, automatic deletion of old data, built-in encryption

Example 2 - Mobile App Development:

Design phase: Architect app to collect only essential data, use local processing where possible, implement encryption from start
Not bolting on: Building app first, then trying to add privacy features later

Example 3 - HR System:

Design: Separate employee personal data from performance data with access controls
Default: Performance reviews only visible to direct managers and HR, not all staff
Minimization: Don't require nationality if not legally needed, collect only job-relevant information

Privacy by Default Examples:

Amount of Data:

Website registration form asks only for essential fields (email, password), not full address, phone, date of birth unless needed
Mobile app requests only necessary permissions, not blanket access to contacts, location, camera

Extent of Processing:

Email marketing system processes email addresses for campaigns, doesn't automatically profile browsing behavior unless user opts in

Storage Period:

System automatically deletes old logs, abandoned carts, inactive accounts after defined periods
Email automatically deleted from servers after 90 days unless user archives

Accessibility:

Dating app profile defaults to private, user must explicitly choose to make public
Document sharing defaults to specific people, not "anyone with link"
Employee directory shows only work email by default, not home address/phone

Implementation Checklist:

Design Phase:

Conduct privacy impact assessment before building
Map data flows and identify minimization opportunities
Design with least privilege access controls
Build in encryption, pseudonymization, anonymization
Implement secure defaults in code
Design data lifecycle management (automatic deletion)

Default Settings:

Privacy-protective defaults for all settings
Require explicit consent for public sharing
Limit data collection to essential fields
Disable optional features by default
Restrict access to minimum necessary

Testing:

Test that defaults are actually privacy-protective
Verify data minimization works as intended
Audit actual data collected vs. designed collection

Documentation:

Document privacy-by-design decisions
Record default settings rationale
Maintain evidence of design choices

Common Violations:

Dark patterns: Making privacy options hard to find or misleading
Public by default: Social media posts, photos default to public
Over-collection: Requiring unnecessary data for service
Pre-ticked boxes: Consent boxes checked by default
Bolt-on privacy: Adding privacy after system is built