Data Privacy and GDPR Compliance
Implement data privacy controls, consent management, data anonymization, and GDPR-compliant data handling in web applications.
Note: This guide follows English-language naming conventions and terminology standards common in international development teams. Examples use English identifiers and comments to maximize compatibility across codebases and tooling.
Overview
The General Data Protection Regulation (GDPR) sets strict rules for handling personal data of EU citizens. Beyond legal compliance, privacy-by-design builds user trust and reduces breach impact. This resource covers practical technical controls: consent management, data minimization, anonymization, right to erasure, and data portability.
When to Use
Use this resource when:
- Processing personal data of EU residents (customers, employees, leads)
- Building consent flows for marketing, analytics, or third-party sharing
- Implementing data retention and automatic deletion policies
- Preparing for data subject access requests (DSARs)
Solution
Consent Management Schema (PostgreSQL)
CREATE TABLE user_consents (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
purpose VARCHAR(50) NOT NULL, -- 'marketing', 'analytics', 'third_party'
granted BOOLEAN NOT NULL DEFAULT false,
granted_at TIMESTAMPTZ,
withdrawn_at TIMESTAMPTZ,
ip_address INET,
user_agent TEXT
);
-- Index for fast DSAR lookups
CREATE INDEX idx_consents_user ON user_consents(user_id);
Anonymization Pipeline (Python)
import hashlib
import hmac
from datetime import datetime
SECRET_KEY = b"rotation-secret-2024"
def pseudonymize(user_id: str) -> str:
"""Replace PII with irreversible hash for analytics."""
return hmac.new(SECRET_KEY, user_id.encode(), hashlib.sha256).hexdigest()[:16]
def anonymize_age(birth_date: datetime) -> str:
"""Bucket age into ranges for statistical use."""
age = (datetime.now() - birth_date).days // 365
if age < 18: return "<18"
if age < 25: return "18-24"
if age < 35: return "25-34"
return "35+"
Right to Erasure (Node.js)
async function eraseUserData(userId) {
// 1. Delete or anonymize user record
await db.users.update(userId, {
email: null,
name: 'Deleted User',
deleted_at: new Date()
});
// 2. Cascade delete related data
await db.orders.anonymize({ user_id: userId });
await db.sessions.delete({ user_id: userId });
await db.activity_logs.delete({ user_id: userId });
// 3. Notify third parties
await webhookService.notify('user.deleted', { userId });
// 4. Log the erasure for audit
await auditLog.create({ action: 'erasure', user_id: userId, timestamp: new Date() });
}
Explanation
Six GDPR principles with technical implementation:
- Lawfulness: Store consent records with timestamp, IP, and purpose
- Purpose limitation: Tag data with allowed purposes; reject unauthorized use
- Data minimization: Collect only what’s necessary; use form validation
- Accuracy: Allow users to update profiles; validate inputs
- Storage limitation: TTL on personal data; auto-delete after retention period
- Integrity/confidentiality: Encrypt at rest; hash for analytics; access controls
Data Subject Rights (DSRs):
- Access: Export all personal data in machine-readable format (JSON)
- Rectification: Update incorrect data via self-service portal
- Erasure: Delete or anonymize within 30 days (with audit trail)
- Portability: Export data in standard format (JSON, CSV)
- Objection: Stop processing for marketing or profiling
Variants
| Control | Implementation | Effort |
|---|---|---|
| Consent banners | Cookie consent SDK | Low |
| Data mapping | Manual audit + schema tags | Medium |
| Auto-deletion | Cron jobs with retention rules | Medium |
| Pseudonymization | Hashing + key rotation | Medium |
| DPO dashboard | Custom admin tool | High |
Best Practices
- Privacy by default: New features opt-out by default; explicit opt-in required
- Encrypt PII at rest: Use AES-256 encryption for databases, S3, and backups
- Log access to personal data: Audit who accessed what and when
- Separate analytics data: Pseudonymize before sending to BI tools
- Document your lawful basis: Contract, consent, or legitimate interest per data type
Common Mistakes
- Implicit consent: Pre-checked boxes or buried terms don’t count under GDPR
- No retention limits: Keeping user data forever violates storage limitation
- Third-party leakage: Analytics, ads, and CDNs receive PII without user knowledge. Run dependency audits regularly.
- Ignoring backup deletion: Erased user data persists in old database snapshots
- One-size-fits-all consent: Marketing and functional cookies need separate consent
Frequently Asked Questions
Q: Does GDPR apply if my company is outside the EU? A: Yes, if you process data of EU residents. The regulation has extraterritorial reach.
Q: What’s the difference between anonymization and pseudonymization? A: Anonymization is irreversible (data can never identify the person). Pseudonymization uses a key that can re-identify if needed (still personal data under GDPR).
Q: How do I handle erasure requests with foreign key constraints? A: Use soft deletes (anonymize instead of delete), or cascade deletes with audit logging. Never orphan records.
Related Resources
Data Retention Policy Template
A data retention policy template that defines how long data is kept, when it is archived, and how it is destroyed in compliance with regulations.
RecipeImplement Encryption at Rest for Databases and File Storage
How to encrypt sensitive data before storing it in databases, object storage, and backups using AES-256-GCM, envelope encryption, and key management services.
DocThird-Party Dependency Audit Template
A template for auditing third-party dependencies: license compliance, security vulnerabilities, maintenance health, and supply chain risk.
DocPenetration Test Report Template
A penetration test report template for documenting findings, risk ratings, reproduction steps, and remediation guidance for security assessments.
DocSecurity Incident Response Template
A security incident response template for documenting breaches, containing threats, and communicating with stakeholders during a security event.