GDPR Article 25 requires controllers to build data protection into processing, both when deciding how it works and while it runs, and to configure it by default so that only the personal data needed for each purpose is processed. In engineering terms that means minimisation, short retention and tight default access.
Two obligations
By design (paragraph 1). Weigh the state of the art, cost, the nature, scope, context and purposes of processing and the risks to people, then apply appropriate technical and organisational measures, such as pseudonymisation, that put principles like data minimisation into practice.
By default (paragraph 2). Only process the personal data needed for each specific purpose. That covers how much is collected, how far it is processed, how long it is stored and who can access it. By default, data should not be accessible to an unlimited number of people without the individual's action.
Turning it into design review questions
Add these to your design template:
- What is the purpose of each field we collect? Delete fields with no answer.
- Can we hold a pseudonymous identifier instead of the name or email?
- What is the retention period, and what job deletes the data?
- Who can read it by default? Is the answer a role, not "everyone in engineering"?
- Do logs, traces and analytics events capture personal data that nobody needs?
- Is the sharing or visibility setting off until the user turns it on?
Defaults that matter
- New accounts start with the most private setting available.
- Profiles and shared items are not public until the person chooses.
- Optional fields stay optional and unchecked.
- Production data is not copied into test environments without a reason and controls.
- Exports and admin tools write to an audit log.
Pseudonymisation in practice
Article 4 defines pseudonymisation as processing so that data can no longer be attributed to a person without additional information kept separately under safeguards. A typical pattern is a lookup table in a restricted store, with analytics working only on tokens. Pseudonymised data is still personal data if the information to reverse it exists, so the regulation still applies. More in pseudonymisation vs anonymisation.
Showing your work
An approved certification mechanism can help demonstrate compliance with Article 25, but a design review record, a retention schedule and tests for the deletion job are what you can show an auditor today. Keep them with the feature's documentation.
Quick check
Does privacy by design apply to old systems?
The obligation applies to ongoing processing, so revisit legacy systems when you change them or review risk.
Is encryption enough?
No. It is one measure. Minimisation, retention and access defaults are separate requirements.
Safeguard's policies, gates and guardrails can enforce engineering rules in the pipeline, and its SBOM and dependency scanning covers the components you ship. Privacy design decisions stay with your team.
Sources
Last reviewed: 19 October 2026.
