GDPR Article 25 Is a Code-Level Requirement, Not an Architecture Diagram
Article 25 of the GDPR requires 'data protection by design and by default.' Most organizations implement this at the architecture level. Here's what it means at the code level.
"By design" is the part most programs skip
Article 25 reads as an architectural requirement when it is quoted at a high level: "appropriate technical and organisational measures" for data protection by design and by default. Most compliance programs treat it that way. They commission a privacy impact assessment, document the architectural choices, and stop.
The EDPB's Guidelines 4/2019 on Article 25 are explicit that this reading is incomplete. The obligation attaches "at the time of the determination of the means for processing and at the time of the processing itself." That is code-level language. A logging statement that captures a request body containing personal data fails Article 25 even if the architecture document does not mention logging at all.
Data Minimization in Code (CWE-212)
Article 25(2) requires that "by default, only personal data which are necessary for each specific purpose of the processing are processed." This maps directly to CWE-212 (Improper Removal of Sensitive Information Before Storage or Transfer).
Common code-level violations:
- Logging request bodies that contain personal data
- Storing full user objects when only user IDs are needed
- Including PII in error messages or stack traces
These are not architecture decisions. They're code decisions made at line level. A logging statement that includes request.user captures more data than request.user.id, and that difference is an Article 25(2) question.
Access Control as Privacy Control (CWE-284)
Article 25(1) requires that systems be designed to process "only personal data which are necessary for each specific purpose" and that by default "personal data are not made accessible without the individual's intervention to an indefinite number of natural persons."
This means: unauthorized access to personal data is a technical failure, not just a policy failure. CWE-284 (Improper Access Control) is a GDPR Article 25 finding, not only an OWASP finding.
Pseudonymization Requirements
Article 4(5) defines pseudonymization as "the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information." Article 25 requires pseudonymization as a default measure where appropriate.
In code, pseudonymization means:
- Analytics data uses hashed or tokenized identifiers, not direct user IDs
- Logs use pseudonymous identifiers that can be de-anonymized only with a separate key
- Data passed to third-party services is pseudonymized before transmission
CWE-359 (Exposure of Private Personal Information) covers the cases where code fails to apply pseudonymization before processing or sharing.
The 72-Hour Breach Notification Requirement and Logging
GDPR Article 33 requires notification to supervisory authorities within 72 hours of becoming aware of a breach. Meeting this deadline requires:
- Detecting the breach quickly (monitoring and alerting)
- Assessing scope quickly (audit logs showing what was accessed)
- Notifying affected individuals if appropriate (notification system)
Audit logging for personal data access is both an Article 25 design requirement (build the logging in) and an Article 33 operational requirement (use the logs when a breach occurs). CWE-778 (Insufficient Logging) is a direct GDPR finding.
How Deva Addresses GDPR Article 25
Deva's GDPR preset covers Article 25 and related code-level requirements. CWE-212, CWE-284, CWE-359, CWE-778 are all included with GDPR article references. When Deva surfaces a logging statement capturing request body content, it shows: Art. 25(2) Data Minimization · Art. 33 Breach Notification.
The fix generator is compliance-aware: GDPR-preset fixes add pseudonymization where appropriate rather than just removing the data from logs entirely. For definitions of GDPR-specific terms (controller, processor, pseudonymization, ePHI), see the glossary.
Deva Security Team
Threat research, application security analysis, and defensive engineering insights from the DevSecCode team.
Related Articles
HHS Wants Annual Pentests in the HIPAA Security Rule. Here's What That Looks Like.
HHS proposed updates to the HIPAA Security Rule in early 2025 that would make penetration testing an explicit requirement for covered entities. Here's what the proposed rule says and how to prepare.
Read moreCMMC Level 2 Is Enforced. Here's What Your Code Has to Show.
CMMC 2.0 Level 2 enforcement is active for DoD contracts. Most compliance failures trace back to code, not policy. Here's the control mapping every developer on a defense program needs to understand.
Read moreNIST CSF 2.0: Govern Got the Headlines, ID.AM-07 Will Cost You the Audit
NIST released Cybersecurity Framework 2.0 with a new Govern function and expanded scope beyond critical infrastructure. Here's what the update means at the code level.
Read more