GDPR Privacy by Design: Article 25 Requirements, the 7 PbD Principles, and What 'Privacy as Default' Actually Means for SaaS

What Article 25 actually requires

GDPR Article 25 has two distinct, independently enforceable requirements:

Article 25(1) — Data Protection by Design: Controllers must implement appropriate technical and organisational measures designed to implement data-protection principles effectively, at the time of determining the means of processing and at the time of the processing itself.
Article 25(2) — Data Protection by Default: Controllers must ensure that, by default, only personal data that is necessary for each specific purpose of the processing is processed. This applies to the amount of data collected, the extent of its processing, the period of its storage, and its accessibility.

The critical phrase in Art. 25(1) is "at the time of determining the means." This means privacy must be considered when you decide how you're going to build a feature — not retrofitted after launch.

The fines — why Art. 25 matters now

Art. 25 violations fall under the lower tier of GDPR fines — up to €10M or 2% of global annual turnover, whichever is higher. But DPAs are increasingly enforcing Art. 25 directly, not just as an afterthought to other violations.

Real enforcement examples:

Clearview AI (multiple DPAs, 2021–2023): Fined by ICO (£7.5M), CNIL (€20M), Garante (€20M), and others for systematic Art. 25 violations — facial recognition collected without consent, no legitimate purpose, no data minimisation.
Meta/Facebook (Irish DPC, 2022–2023): Multiple Art. 25 violations related to default privacy settings — profiles set to public by default, location data enabled without explicit user action.
Cookie banners (CNIL, noyb campaigns): Hundreds of enforcement actions for pre-ticked analytics consent boxes and no meaningful "reject all" — a direct Art. 25(2) violation.
WhatsApp (DPC Ireland, 2021): €225M fine included Art. 5/12/13 transparency failures — privacy-by-default settings were found to be inadequate for the volume of data shared with Facebook.

Ann Cavoukian's 7 Privacy by Design Principles — GDPR mapped

Privacy by Design was originally developed by Ontario's Information and Privacy Commissioner Ann Cavoukian in the 1990s. EDPB Guidelines 4/2019 explicitly reference these principles as the conceptual foundation for Art. 25. Here's how they map to GDPR obligations:

Principle 1: Proactive not Reactive — Preventative not Remedial

What it means: Privacy risks are identified and addressed before they occur — not after a breach or complaint.

GDPR link: Art. 25(1) — "at the time of determining the means." Art. 35 DPIA requirement for high-risk processing.

In practice: Before launching a new feature that processes personal data, your product team conducts a privacy review. Before choosing a data architecture, privacy risks are modelled. A DPIA is triggered for high-risk processing before development begins.

Principle 2: Privacy as the Default Setting

What it means: Maximum privacy settings are the default. Users don't have to take action to protect their privacy — sharing and disclosure require user action.

GDPR link: Art. 25(2) — explicitly mandated. This principle is the statutory requirement.

In practice: Profile visibility defaults to private. Marketing emails require explicit opt-in. Analytics features are off until enabled. Pre-ticked consent boxes for analytics = Art. 25(2) violation.

Common mistake: Treating "cookie banner" as the only Art. 25(2) obligation. Default settings in your product itself — who can see a user's profile, what data is shared to third parties, what's included in an API response — are all in scope.

Principle 3: Privacy Embedded into Design

What it means: Privacy is a core design requirement, not a security layer added at the end. The system architecture itself reflects privacy principles.

GDPR link: Art. 25(1) + Art. 32 (security). Recital 78 encourages privacy considerations from the planning stage.

In practice: Microservice architecture where each service only has access to the data it needs (least privilege at system level). Data encryption designed into the schema from day one. Retention TTLs built into the data model, not managed manually. Privacy requirements tracked as Jira tickets alongside performance requirements.

Principle 4: Full Functionality — Positive-Sum, Not Zero-Sum

What it means: Privacy and functionality are not in opposition. You don't have to sacrifice features to protect privacy — find solutions that achieve both.

GDPR link: EDPB Guidelines 4/2019 — privacy measures should not impede legitimate processing objectives.

In practice: Using pseudonymised user IDs in analytics instead of real names — you get the same usage insights without direct identification. Using k-anonymity for aggregate reporting — you see population-level trends without individual tracking. Differential privacy for ML training — model improves without memorising individual data points.

Principle 5: End-to-End Security — Full Lifecycle Protection

What it means: Security measures protect personal data throughout its entire lifecycle — from collection through retention, use, disclosure, and deletion.

GDPR link: Art. 32 (security), Art. 5(1)(f) (integrity and confidentiality), Art. 17 (right to erasure).

In practice: Not just encrypting data at rest — also encrypting in transit, protecting keys separately from data, logging all access, automating data deletion at end of retention period, and verifying deletion after exercise of erasure rights.

Principle 6: Visibility and Transparency

What it means: Controllers are open and accountable about how data is processed. Users can see what's being done with their data and trust that it matches what was disclosed.

GDPR link: Art. 12/13/14 (transparency), Art. 5(2) (accountability), Art. 30 (Records of Processing Activities).

In practice: A complete, accurate privacy notice updated when processing changes. A maintained RoPA. Clear API documentation about what data flows where. Honest disclosure of sub-processors, including when they change.

Principle 7: Respect for User Privacy

What it means: User privacy interests are kept paramount. The system is designed to support and enable individual privacy rights.

GDPR link: Art. 15–22 (data subject rights), Art. 7 (consent), Art. 28 (processor obligations), Art. 44–49 (international transfers).

In practice: Technical capability to export user data in a machine-readable format (portability), delete all traces of a user on request (erasure including backups), restrict processing, and correct inaccurate data. Consent withdrawal mechanism that's as prominent as consent-giving.

What Art. 25(2) actually requires for your product defaults

Art. 25(2) is often the most immediately actionable requirement. The EDPB Guidelines 4/2019 give useful guidance on the four dimensions of privacy-as-default:

Amount of data collected: The default should be to collect only data strictly necessary for the purpose. Every additional field must be justifiable.
Extent of processing: Default processing operations should be the minimum necessary. Don't process data for secondary purposes unless users explicitly opt in.
Period of storage: Retention defaults should reflect the minimum necessary. Don't default to "keep forever" — default to deletion after the retention period.
Accessibility: Data should not be accessible to more people or systems than necessary by default. Least privilege should be the default access state.

The technical measures that satisfy Art. 25

EDPB Guidelines 4/2019 list examples of measures that implement Art. 25 effectively. For SaaS companies, the most relevant are:

Data minimisation controls

Form fields limited to what's necessary — no optional "nice to have" fields in mandatory registration flows
API responses that return only requested fields, not entire user objects
Data truncation and masking for support access (staff see partial card numbers, not full PAN)

Pseudonymisation

User analytics using pseudonymous IDs rather than emails or names
Hashed identifiers in logs rather than raw personal data
Internal user IDs in audit logs, with the name→ID mapping stored separately with stricter access controls

Storage limitation

Automated deletion jobs per data type (e.g., session logs deleted after 90 days)
TTL (time-to-live) configurations in databases and caches
Backup retention policies that actually delete old backups

Access controls

Role-based access (not "everyone can see everything" during development and never reviewed)
Separate permissions for production data access
MFA for any access to production personal data
Audit logs of who accessed what data when

Encryption

Encryption at rest: AES-256 minimum (AWS KMS, GCP CMEK, Azure Key Vault)
Encryption in transit: TLS 1.2+ minimum, TLS 1.3 for new systems
End-to-end encryption where users have reasonable expectation of confidentiality

When is a DPIA required? (Art. 35)

Privacy by design should trigger a Data Protection Impact Assessment before processing begins when the processing is likely to result in a high risk. Art. 35(3) specifies three automatic triggers:

Systematic and extensive evaluation of personal aspects through automated processing, including profiling, with decisions that have significant effects
Large-scale processing of special categories (health, biometric, religion, ethnicity, etc.) or criminal conviction data
Systematic monitoring of a publicly accessible area on a large scale

EDPB also identifies 9 criteria where DPIAs are likely required when two or more apply: evaluation/scoring; automated decision with legal/significant effects; systematic monitoring; sensitive data; large-scale data; matching/combining datasets; data about vulnerable subjects; innovative technology; processing preventing exercise of rights/using a service.

For SaaS, common DPIA triggers: AI-powered behavioural analytics, employee monitoring tools, health data processing, profiling for credit/insurance decisions, and biometric authentication.

Practical implementation steps

Add a privacy review gate to your product development process. Before any feature involving personal data goes to sprint planning, it goes through a privacy check: what data is collected, what's the lawful basis, is a DPIA needed, what are the defaults?
Audit your current defaults. Go through every setting in your product and ask: if a user takes no action, how much data is shared with whom? The answer should be "as little as possible."
Implement automated data deletion. Map your data types, document retention periods, and build automated jobs to delete or anonymise data when retention periods expire.
Check your analytics and tracking stack. Is Google Analytics running before cookie consent? Are analytics cookies pre-ticked? Fix these first — they're the most visible and most frequently enforced violations.
Document everything. Art. 5(2) accountability means you must be able to demonstrate compliance. Record your privacy decisions as part of your product documentation.

Generate your GDPR Privacy by Design Assessment

ComplyKit's GDPR Privacy by Design Assessment Generator produces a complete Art. 25 compliance assessment covering all 7 PbD principles, key GDPR technical measures, DPIA trigger analysis, and an implementation roadmap — tailored to your product and processing activity.