Article 25
Data protection by design and by default
GDPR · Regulation (EU) 2016/679 · Last verified July 2026
Objective
The controller shall implement appropriate technical and organisational measures designed to implement data-protection principles effectively and to integrate necessary safeguards into processing, and shall implement measures to ensure that by default only personal data necessary for each specific purpose are processed.
Points of focus
- Implement technical and organisational measures that implement Article 5 principles effectively
- Integrate safeguards into processing at design and implementation time
- Ensure by default only necessary personal data are processed for each purpose
- Limit by default the accessibility of personal data to an indefinite number of people
- Consider state of the art, cost, and processing risks when choosing measures
Implementation notes
Article 25 binds controllers to build data protection into systems by design and by default. In a SaaS company that is controller for workforce or marketing data — and that designs features customers will use as controllers — bake privacy reviews into the SDLC alongside security design reviews. Require data inventories for new event streams, prefer aggregation or pseudonymisation where purpose allows, set short default retention for debug logs containing PII, and ship product defaults that minimise fields and cross-tenant visibility. Document how 'state of the art' and risk influenced choices when you pick vendors or architectures. Article 25 is demonstrated by design artifacts and default configs, not by a privacy policy sentence alone. Pair it with Article 32 security measures so safeguards are both protective and privacy-preserving.
Audit tip: Show one feature that changed design because of Article 25 (for example, default-off field, hashed identifier, or delayed collection) with ticket and final default settings.
Evidence auditors typically request:
- Privacy-by-design checklist embedded in product/engineering SDLC
- Default configuration screenshots showing minimised collection and restricted sharing
- DPIA or design review records for high-risk features
- Data-minimisation standards for logs, analytics events, and support tooling
- Access-control defaults (least privilege) for admin and support roles
Common gaps
- Privacy review only at launch marketing copy — never in design tickets
- Analytics SDKs enabled by default collecting excess identifiers
- Tenant admin defaults that expose PII broadly inside the workspace
- No retention defaults; raw logs kept indefinitely 'just in case'
Cross-Framework Mapping
| Framework | Requirement | Implementation note |
|---|---|---|
| GDPR | Article 25 | This control |
| ISO 27001 | A.5.34, A.8.2, A.8.3 | PII protection, classification, and access restriction |
| SOC 2 | CC6.1, CC8.1 | Access control and change management as design gates |
| HIPAA | 164.308(a)(1)(ii)(A), 164.312(a)(1) | Risk analysis and access control — complementary, not identical |