Privacy by Design

Privacy by design is the principle that data protection should be built into systems and processes from the outset — not bolted on as an afterthought. GDPR Article 25 makes this a legal requirement, not merely a best practice. This guide explains what the obligation means in concrete terms and how organisations can implement it.

What GDPR Article 25 Requires

GDPR Article 25 creates two distinct obligations:

Privacy by design (Article 25(1)): Controllers must implement appropriate technical and organisational measures — both at the time of determining the means of processing and at the time of processing itself — to implement data protection principles (such as data minimisation) in an effective manner and to integrate the necessary safeguards into the processing to meet GDPR requirements and protect data subjects' rights.

Privacy by default (Article 25(2)): Controllers must implement appropriate technical and organisational measures to ensure that, by default, only personal data which are necessary for each specific purpose of processing are processed. This applies to the amount of data collected, the extent of processing, the storage period, and the accessibility of the data. By default, personal data must not be made accessible to an indefinite number of people without the individual's intervention.

Both obligations apply at design time — before systems are built and deployed — and cannot be satisfied retrospectively by patching privacy issues into existing systems.

The Seven Foundational Principles of Privacy by Design

Privacy by design as a framework was developed by Dr Ann Cavoukian (Ontario Information and Privacy Commissioner) in the 1990s and adopted by GDPR as its underlying conceptual basis. The seven principles are:

1. Proactive not reactive; preventive not remedial. Privacy is anticipated and prevented before the fact, not remedied after. This principle requires organisations to think about privacy risks before they become incidents, not in response to them.

2. Privacy as the default setting. Individuals should receive the highest level of privacy protection without having to take action. Opt-in, not opt-out, is the baseline where choices are involved. The most privacy-protective settings apply automatically.

3. Privacy embedded into design. Privacy is a core component of system design, not an add-on. Security architecture, data models, user interfaces and processes are all designed with privacy in mind from the beginning.

4. Full functionality — positive-sum, not zero-sum. Privacy and functionality are not in tension. Privacy by design aims to accommodate all legitimate interests and objectives, not to sacrifice one for the other.

5. End-to-end security — full lifecycle protection. Personal data must be protected throughout its entire lifecycle — collection, use, storage, transfer, and deletion. Secure deletion and minimisation at end-of-life are part of the design requirement.

6. Visibility and transparency. Organisations and systems are transparent in their data processing practices. Individuals can verify that processing matches stated purposes. All stakeholders can understand what happens with data.

7. Respect for user privacy — keep it user-centric. Systems are designed to protect individual privacy interests. User consent, accuracy, access and compliance are built into the architecture.

Privacy by Default in Practice

Privacy by default (Article 25(2)) is more concrete than privacy by design and more easily assessed during audits. Practical implementation includes:

Data minimisation at collection points. Forms collect only the fields necessary for the stated purpose. Optional fields are genuinely optional — marked clearly and not required for service delivery. Pre-populated fields contain only essential data.

Audience and access defaults. User-generated content defaults to private, not public. Account settings default to the most restrictive sharing configuration. Users must actively opt in to share more broadly, not opt out of default sharing.

Retention defaults. Data is not retained indefinitely. Default retention periods are set and applied automatically. Inactive accounts trigger deletion or anonymisation without manual intervention by an administrator.

Consent and marketing defaults. Marketing preferences default to opt-out. Email marketing requires explicit opt-in. Analytics and tracking are disabled until consent is explicitly given.

Third-party integrations. Third-party tools and plugins are not activated by default if they collect personal data. They are disabled until consent is obtained or another lawful basis established.

Technical Measures for Privacy by Design

Article 25 does not specify which technical measures must be used — this is left to controllers, applying the standard of "state of the art" (GDPR Article 25(1) and Recital 78). Commonly recognised technical measures include:

• Encryption: Personal data encrypted at rest and in transit using current standards (AES-256, TLS 1.2/1.3). Encryption keys managed separately from the encrypted data.
• Pseudonymisation: Replacing identifying data with non-identifying tokens that can only be re-linked to the individual with access to a separate key. Pseudonymised data receives reduced GDPR obligations in certain contexts while retaining analytical utility.
• Data minimisation in architecture: Designing systems to collect only what is needed. Database schemas without catch-all fields. API responses returning only requested fields rather than full objects.
• Access controls: Role-based access control ensuring staff can access only the personal data necessary for their role. Audit logs of who accessed what and when. Multi-factor authentication for accounts with access to personal data.
• Anonymisation at end of retention period: Automated processes that anonymise or delete personal data at the end of retention periods, rather than relying on manual cleanup.
• Data Protection Impact Assessments (DPIAs): Formal risk assessments conducted before implementing high-risk processing activities (required by GDPR Article 35 for certain categories of processing).

Organisational Measures for Privacy by Design

Technical measures alone are not sufficient. GDPR Article 25 requires "technical and organisational measures." Organisational measures include:

• Privacy by design in procurement: Requiring suppliers and processors to implement privacy by design in tools and services purchased by the controller. Data protection requirements included in contracts (required separately by GDPR Article 28 for processors).
• Privacy impact review in project management: Privacy risks assessed during project planning, not after launch. A designated privacy review gate before new processing activities go live.
• Staff training: Staff with access to personal data trained on data minimisation, access controls and incident response. Training records maintained.
• Records of processing activities (Article 30): Maintaining accurate records of all processing activities, which forces systematic thinking about what data is collected and why.
• Vendor management: Assessing third-party tools for privacy risks before adoption. Regular review of existing third-party integrations to confirm continued necessity.

How Privacy by Design Relates to Other GDPR Requirements

Privacy by design is not a standalone obligation — it connects to several other GDPR requirements:

GDPR principles (Article 5): Privacy by design operationalises the data minimisation, purpose limitation and storage limitation principles. Building minimisation into system architecture is how Article 5 compliance becomes structural rather than aspirational.

Data Protection Impact Assessments (Article 35): DPIAs are the formal mechanism for assessing privacy risks in high-risk processing before implementation. They are a direct application of privacy by design — the risk assessment that precedes design decisions.

Security of processing (Article 32): The technical and organisational security measures required by Article 32 overlap substantially with privacy by design measures. Encryption, access controls and pseudonymisation are required by both provisions.

Data breach notification (Articles 33-34): Privacy by design measures — particularly encryption and data minimisation — directly affect breach notification obligations. Breaches involving encrypted data where the key was not compromised may not trigger notification, precisely because privacy by design reduced the risk.

Demonstrating Compliance

GDPR's accountability principle (Article 5(2)) requires controllers to be able to demonstrate compliance with privacy by design requirements. Supervisory authorities have found the following useful as evidence of compliance:

• Privacy impact assessments conducted before system deployment
• Documentation of design decisions showing that privacy alternatives were considered
• Records showing minimisation decisions at collection point design stage
• Retention schedule documentation and evidence of automated enforcement
• Access control matrices showing the principle of least privilege
• Vendor assessment records

The absence of documentation is itself a compliance risk under the accountability principle, even if the underlying practices are sound.

For data breach response planning — a core privacy by design deliverable — see our data breach notification guide.