Scope - What This Guide Covers
This guide translates Article 25 GDPR privacy by design obligations into concrete technical requirements you can implement. It's written for security engineers and architects who need to embed data protection into systems before they go live, not retrofit it afterward.
You'll find requirement breakdowns, implementation patterns, and a reference table you can use during design reviews. This isn't about compliance theatre, it's about building systems that process personal data lawfully from the first line of code.
Key Concepts and Definitions
Privacy by design (Article 25(1) GDPR) requires controllers to implement technical and organizational measures to integrate data protection principles into processing operations. This applies at two stages: when determining the means of processing and during the processing itself.
Privacy by default (Article 25(2) GDPR) mandates that systems process only the personal data necessary for each specific purpose. By default, personal data shouldn't be accessible to an indefinite number of people without individual intervention.
State of the art: The technical measures available at the time you design the system. You're not expected to implement theoretical research, but you can't ignore well-established practices like encryption at rest or pseudonymisation.
Cost of implementation: Article 25 acknowledges resource constraints, but supervisory authorities interpret this narrowly. If you're processing sensitive data at scale, "too expensive" won't justify weak controls.
Requirements Breakdown
Article 25(1): Design-Stage Obligations
When you're architecting a new system or feature that processes personal data, you must:
Implement data minimisation controls that limit collection to what's necessary for the stated purpose. This means technical enforcement, not just policy documents. If your analytics dashboard doesn't need email addresses, the data pipeline shouldn't extract them.
Build in pseudonymisation or anonymisation where compatible with the processing purpose. A customer support system might replace account IDs with session tokens in logs. A marketing platform might hash email addresses before passing them to third-party analytics.
Enable purpose limitation through system architecture. If you collect addresses for order fulfillment, your recommendation engine shouldn't access that table without a separate lawful basis and transparency disclosure.
Design for storage limitation. Implement automated retention policies at the database level, not as a manual cleanup task someone runs quarterly. Your schema should include created_at and expires_at fields with enforcement logic.
Article 25(2): Default Settings
Your system's initial configuration must:
- Process the minimum data necessary without user intervention
- Restrict data access to authorized personnel only
- Disable optional processing features until explicitly enabled
- Set the shortest defensible retention period as the default
Consider a user profile system. By default, it should collect only the fields required for account creation, not optional demographic data that might be useful for analytics later. Make those opt-in.
Implementation Guidance
Step 1: Map Data Flows Before You Code
Create a data flow diagram that shows:
- What personal data enters the system and from where
- Which components process, store, or transmit it
- Where it exits (APIs, reports, third-party integrations)
- Retention periods for each data category
This diagram becomes your design constraint. If you can't justify a flow against a specific processing purpose, don't build it.
Step 2: Embed Controls at the Schema Level
Use database constraints and application logic to enforce data protection principles:
-- Storage limitation: automated expiry
ALTER TABLE user_sessions ADD COLUMN expires_at TIMESTAMP;
CREATE INDEX idx_expired_sessions ON user_sessions(expires_at)
WHERE expires_at < NOW();
-- Data minimisation: nullable fields for optional data
ALTER TABLE user_profiles
ALTER COLUMN marketing_preferences DROP NOT NULL;
Step 3: Implement Access Controls That Reflect Purpose
Your authentication system should enforce purpose-based access. A support engineer handling a DSAR needs read access to order history. Your marketing team doesn't, even if they're in the same database.
Use role-based access control (RBAC) with granular permissions tied to processing purposes, not just job titles.
Step 4: Build Transparency Into the Interface
When your system collects personal data, the interface should explain what you're collecting and why, right there, not buried in a privacy notice. A shipping address form might include: "We'll use this address only to deliver your order and will delete it 90 days after delivery."
Step 5: Test Your Defaults
Before launch, verify that:
- A new user account processes the minimum necessary data
- Optional features are disabled until explicitly enabled
- Retention policies execute automatically
- Access logs show only authorized personnel viewing personal data
Common Pitfalls
Treating privacy by design as a checklist exercise. Supervisory authorities expect you to demonstrate how technical measures integrate data protection principles into your architecture. "We have encryption" isn't enough if you're still collecting unnecessary data.
Assuming consent fixes design problems. You can't collect excessive data and justify it with a consent checkbox. Article 25 operates independently of your lawful basis, even if users consent, you must still minimize data collection.
Ignoring legacy systems. Article 25(1) applies "at the time of the determination of the means of processing." When you refactor or extend an existing system, that's a new determination. You can't grandfather in poor design indefinitely.
Confusing security with privacy by design. Encryption and access controls are necessary but insufficient. Privacy by design also requires data minimisation, purpose limitation, and storage limitation, principles that security engineering doesn't always address.
Building flexibility you don't need. That "just in case" data field or that "might be useful later" integration creates compliance debt. If you don't have a specific, documented purpose now, don't build the capability.
Quick Reference Table
| Principle | Technical Control | Implementation Example |
|---|---|---|
| Data minimisation | Schema constraints | Nullable columns for optional data; form validation that rejects unnecessary fields |
| Purpose limitation | Access control policies | Separate databases or schemas per processing purpose; API gateways that enforce purpose-based routing |
| Storage limitation | Automated retention | Database triggers or scheduled jobs that purge expired data; TTL settings on cache layers |
| Accuracy | Update mechanisms | User-facing interfaces to correct data; automated validation on data entry |
| Integrity and confidentiality | Encryption and access logs | TLS in transit; encryption at rest; audit logs for all personal data access |
| Pseudonymisation | Tokenisation or hashing | Replace identifiers with tokens; hash email addresses before passing to analytics |
You'll reference this table during design reviews and architecture discussions. When someone proposes a new feature, ask: which principles does this affect, and what controls will we implement?
Privacy by design isn't a project with a completion date. It's a design discipline you apply every time you write a technical specification.
