GDPR Article 25: Data Protection by Design and by Default

In one sentence. GDPR Article 25 imposes two parallel obligations on the controller: (1) Data protection by design — implement appropriate technical and organizational measures at the time the means of processing are determined and at the time of the processing itself, integrating data protection into the architecture; (2) Data protection by default — ensure that only personal data necessary for each specific purpose is processed by default, including with respect to volume, retention, accessibility, and disclosure.

Article 25 is where compliance meets engineering. It moves data protection from “we’ll add it later” to “build it in from the start.” The EDPB (Guidelines 4/2019) provides extensive guidance and lists seven practical principles. CNIL has begun citing Article 25 in product design audits — when a product makes privacy-violating defaults the easy path, the violation is structural, not procedural.

For related obligations: Article 32 security of processing, Article 35 DPIA, GDPR Article 6 lawful basis.

Key takeaways

• Article 25(1): privacy by design — appropriate technical and organizational measures at design time AND processing time.
• Article 25(2): privacy by default — minimum necessary data processed by default (volume, retention, accessibility, disclosure).
• Applies to controllers AND processors who design products used by controllers.
• Certification mechanisms under Article 42 may be used to demonstrate compliance with Article 25.
• The EDPB Guidelines 4/2019 define seven foundational principles.

1. Article 25(1) — privacy by design

The controller must implement appropriate technical and organizational measures:

• At the time of determining the means of processing (architecture phase)
• At the time of the processing itself (operational phase)

Considering:

• State of the art
• Cost of implementation
• Nature, scope, context, purposes of processing
• Risks of varying likelihood and severity for rights and freedoms

The intent: data protection isn’t bolted on after the product ships; it’s part of the design language from day one.

2. Article 25(2) — privacy by default

Default settings must process only the personal data necessary for each specific purpose, including:

Dimension	Default position
Amount of data collected	Minimum necessary
Extent of processing	Minimum necessary
Period of storage	Shortest necessary
Accessibility	Least permissive
Disclosure	Least exposed

The user shouldn’t have to take action to protect their privacy — privacy is the default state.

3. The seven EDPB principles (Guidelines 4/2019)

1. Effectiveness — measures must actually achieve their stated goal
2. Risk-based — proportionate to risks to data subjects
3. Holistic — across the full processing lifecycle, not just collection
4. Lifecycle — applies from design through retirement
5. Embedded — integrated into the system, not a separate layer
6. Functionality — both privacy AND functionality, not one or the other
7. Visibility/transparency — measures verifiable by users and regulators

4. Practical patterns

Privacy by design — architecture

• Data minimization at the database level: don’t collect optional fields you don’t need
• Pseudonymization by default: separate identifiers from observations
• Encryption everywhere: at rest, in transit, in backups
• Access logs by design: every read of sensitive data logged
• Time-bound credentials: API tokens with expiration
• Separation of duties: no single role can access + modify + delete

Privacy by default — settings

• Profile visibility: private by default; public is opt-in
• Newsletter subscription: opt-out by default; opt-in to subscribe
• Data sharing with partners: off by default
• Third-party cookies: blocked by default; loaded only after consent
• Geolocation: off by default; permission requested on first use
• Public posts: friends-only by default; public is explicit choice

What the EDPB specifically calls out

• Pre-ticked consent boxes — violates Article 25(2) even before Article 7
• “All friends can see” default — violates default principle
• 12-month retention with no business need — violates minimization

5. Article 25 and software vendors

Vendors that design products used by controllers (SaaS platforms, library authors, consultants) have a derivative obligation:

• The product must enable controllers to implement Article 25
• Privacy-violating defaults shipped to controllers create cascading non-compliance

The CNIL has cited this in audits of compliance software vendors that shipped products with overly broad default permissions.

6. DPIA interaction (Article 35)

DPIAs must demonstrate Article 25 implementation. The DPIA must show:

• Architecture review for privacy-by-design
• Default configuration review for privacy-by-default
• Specific technical measures with their effectiveness assessment

Inadequate Article 25 implementation surfaced in a DPIA triggers the consultation obligation under Article 36 (consult the DPA before processing).

7. Certification (Article 42 / 25(3))

Article 25(3) explicitly mentions that approved certification mechanisms (Article 42) may be used to demonstrate Article 25 compliance. Examples:

• Europrise (European Privacy Seal)
• CNIL Label (France)
• TÜV Privacy (Germany)
• ISO 27701 (privacy information management) — closely aligned

Certification doesn’t replace the obligation but provides evidence in audits.

8. Enforcement

Year	Sanction	Article 25 violation
2019	Bouygues Telecom (CNIL) — €250K	Default configuration leaked customer data
2020	H&M (Hamburg) — €35M	Default employee monitoring excessive
2022	Clearview AI (CNIL) — €20M	No privacy by design in scraping architecture
2023	Multiple SaaS (CNIL) — €50K-€500K	Privacy-violating default settings

Article 83(4)(a) places Article 25 violations at the lower tier — up to €10M or 2% of global annual turnover.

9. Implementation checklist

• ☐ Privacy review embedded in product design process (PRD template includes privacy section)
• ☐ DPO consulted on architectural decisions affecting personal data
• ☐ Data minimization audit on every form / database table
• ☐ Default settings reviewed: minimum necessary across all dimensions
• ☐ Pseudonymization implemented where reasonable
• ☐ Encryption at rest + in transit + in backups
• ☐ Access controls follow least privilege
• ☐ Logs maintained for sensitive data access
• ☐ Retention defaults set to minimum useful period
• ☐ Privacy-by-design checklist used in code reviews

10. Tooling

Legiscope provides a privacy-by-design checklist integrated with the ROPA — every new processing activity gets an Article 25 review with templated questions and DPO sign-off.

For related deep-dives: Article 32 security of processing, Article 35 RGPD AIPD, pseudonymisation, data privacy compliance guide.

Conclusion

Article 25 turns engineering into a privacy obligation. Default settings — what the user gets without taking any action — must be the most privacy-protective. Architecture decisions taken at design time are evaluated as compliance choices. The cost of retrofitting Article 25 into a shipped product is significantly higher than building it in from the start; the EDPB guidelines and increasing CNIL enforcement make this an architectural priority, not a legal one.

FAQ

What does “privacy by design” mean under GDPR Article 25?

Implementing technical and organizational measures to protect personal data from the moment processing is designed, not after the product ships. It includes pseudonymization, encryption, access controls, data minimization at the database level, and log retention.

What is “privacy by default”?

The default settings of a product must process only the personal data necessary for each specific purpose. Users shouldn’t have to take action to protect their privacy — the most privacy-protective configuration is the default.

Does Article 25 apply to software vendors?

Article 25 directly binds the controller. But software vendors that design products used by controllers have a derivative obligation: the product must enable controllers to implement Article 25. Vendors who ship privacy-violating defaults create cascading non-compliance.

How is Article 25 enforced?

Through audits — typically discovered when DPAs review product configurations, default settings, or architecture during inspections. Article 83(4)(a) places Article 25 violations at the lower fine tier — up to €10M or 2% of global annual turnover.

Is ISO 27701 certification enough to prove Article 25 compliance?

It’s strong evidence but not automatic compliance. ISO 27701 covers many Article 25 controls but the DPA still assesses actual implementation. Certification + documented internal audits + DPIA records form the defensible compliance package.