GDPR is not just a legal document — Article 32 mandates concrete technical security measures that fall squarely on development teams. This guide translates the regulation into actionable implementation steps for developers and SaaS founders.
Anay Pandya
1,686 words
Anay Pandya
Founder of ZeriFlow · 10 years fullstack engineering · About the author
Key Takeaways
GDPR enforcement has matured significantly. In the early years after the 2018 implementation, regulators focused primarily on consent mechanisms and privacy policies. By 2026, the enforcement trend has shifted firmly toward technical security failures. The €405 million fine against Meta Ireland for inadequate data protection measures, the €35 million fine against H&M for employee surveillance, and dozens of fines against smaller companies for inadequate encryption and access controls demonstrate that regulators now expect tangible technical implementation — not just policy documents.
For developers and SaaS founders, GDPR compliance is not a legal problem to hand off to a lawyer. The implementation obligations live in your codebase, your infrastructure configuration, and your security processes.
Is your site actually secure?
Keep reading
Run a free check — 60 seconds
GDPR Article 32 mandates that data controllers and processors implement "appropriate technical and organisational measures" to ensure a level of security appropriate to the risk, taking into account:
Specifically, it mentions: - Pseudonymisation and encryption of personal data - Ability to ensure confidentiality, integrity, availability, and resilience of processing systems - Ability to restore availability in the event of a physical or technical incident - A process for regularly testing, assessing, and evaluating the effectiveness of technical measures
"State of the art" is a living standard. In 2026, TLS 1.0 and 1.1 are not state of the art. Storing passwords in MD5 is not state of the art. Missing security headers on a web application serving personal data is increasingly being cited in enforcement decisions as evidence of inadequate technical measures.
GDPR does not name specific TLS versions, but DPA guidance and enforcement precedent make the requirements clear:
Required: - TLS 1.2 minimum for all connections transmitting personal data - TLS 1.3 strongly recommended as the default - Valid certificates from a trusted CA (Let''s Encrypt is acceptable) - HSTS to prevent downgrade attacks
Not acceptable: - TLS 1.0 or 1.1 (deprecated by all major browsers, prohibited by PCI-DSS) - Self-signed certificates in production - Mixed content (HTTPS pages loading HTTP resources) - Certificate expiry monitoring gaps
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadHSTS instructs browsers to always connect to your domain via HTTPS, preventing SSL stripping attacks that would expose personal data in transit. The includeSubDomains directive is important — without it, an attacker who controls a subdomain can intercept cookies scoped to the parent domain.
For GDPR purposes, HSTS demonstrates that you have taken a positive technical step to enforce encrypted transmission, rather than relying on users or clients to make correct choices.
Personal data stored in databases, file systems, and backups must be encrypted. The implementation varies by infrastructure:
Database-level encryption — most managed database services offer encryption at rest by default. Verify it is enabled:
# AWS RDS — check encryption status
aws rds describe-db-instances --query ''DBInstances[*].[DBInstanceIdentifier,StorageEncrypted]''
# Supabase — encryption at rest is enabled by default for all projectsApplication-level encryption — for particularly sensitive fields (SSNs, financial data, health information), consider field-level encryption in addition to disk encryption:
import { createCipheriv, createDecipheriv, randomBytes } from ''crypto'';
const ALGORITHM = ''aes-256-gcm'';
const KEY = Buffer.from(process.env.ENCRYPTION_KEY, ''hex''); // 32 bytes
function encryptField(plaintext) {
const iv = randomBytes(12);
const cipher = createCipheriv(ALGORITHM, KEY, iv);
const encrypted = Buffer.concat([cipher.update(plaintext, ''utf8''), cipher.final()]);
const tag = cipher.getAuthTag();
return `${iv.toString(''hex'')}:${tag.toString(''hex'')}:${encrypted.toString(''hex'')}`;
}
function decryptField(ciphertext) {
const [ivHex, tagHex, encryptedHex] = ciphertext.split('':'');
const decipher = createDecipheriv(ALGORITHM, KEY, Buffer.from(ivHex, ''hex''));
decipher.setAuthTag(Buffer.from(tagHex, ''hex''));
return decipher.update(Buffer.from(encryptedHex, ''hex'')) + decipher.final(''utf8'');
}Password hashing — passwords are personal data. Store them with bcrypt, scrypt, or Argon2 — not SHA-256, MD5, or any reversible encryption:
import bcrypt from ''bcryptjs'';
// Store
const hash = await bcrypt.hash(password, 12); // cost factor 12 minimum
// Verify
const match = await bcrypt.compare(candidatePassword, storedHash);Several security headers have a direct relationship with GDPR''s data minimization and purpose limitation principles.
The Referer header leaks the full URL of the page a user was on before navigating to an external resource. For web applications handling personal data, URLs frequently contain:
- User IDs in path parameters (/users/12345/profile)
- Tokens in query strings (/reset-password?token=abc123)
- Search queries with personal information (/search?q=John+Smith+address)
When these URLs appear in Referer headers sent to third-party analytics, CDNs, or embedded content, you are transmitting personal data to external parties without a legal basis.
Referrer-Policy: strict-origin-when-cross-originThis sends the origin (scheme + host + port) on cross-origin requests but no path or query string. For same-origin requests, the full URL is sent (useful for internal analytics). For GDPR purposes, this prevents personal data leakage to third parties via the Referer header.
The Permissions-Policy header controls which browser APIs a page can use. From a GDPR perspective, it enforces data minimization by preventing browser APIs from being used without explicit user consent:
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=()Restricting interest-cohort=() specifically disables Google''s FLoC/Topics API, which tracks browsing behavior for advertising profiling — a privacy-invasive feature with significant GDPR implications.
If your application does not need camera access, prohibiting it via Permissions-Policy provides a technical enforcement mechanism that supports your privacy-by-design obligations.
CSP''s connect-src, script-src, and img-src directives control which third parties your application sends data to. An overly permissive CSP (or no CSP) allows any injected script to exfiltrate personal data to arbitrary endpoints.
Content-Security-Policy:
default-src ''self'';
script-src ''self'' https://analytics.yourprovider.com;
connect-src ''self'' https://api.yourservice.com;
img-src ''self'' data:;This is both an XSS defense and a data flow control mechanism. For GDPR Article 30 (records of processing activities) purposes, your CSP effectively documents the third parties your application is allowed to communicate with.
GDPR''s "confidentiality" requirement translates directly to access control implementation:
Multi-factor authentication — implement MFA for all accounts accessing personal data, including admin panels, database access, and cloud infrastructure consoles.
Principle of least privilege — users, service accounts, and API keys should only have access to the data they require for their specific function.
Session management — sessions should expire after inactivity, and logout must be complete (server-side session invalidation, not just cookie deletion).
Audit logging — log all access to personal data with user ID, timestamp, and action. These logs are evidence of appropriate technical controls if you are ever audited.
// Audit log middleware
app.use(''/api/users/:id'', (req, res, next) => {
auditLog.info({
userId: req.user.id,
action: req.method,
resource: `user:${req.params.id}`,
ip: req.ip,
timestamp: new Date().toISOString(),
userAgent: req.headers[''user-agent'']
});
next();
});Article 33 requires notification to your supervisory Data Protection Authority within 72 hours of becoming aware of a personal data breach — "where feasible." Article 34 requires notification to affected individuals "without undue delay" when the breach is likely to result in high risk to their rights.
This obligation has a technical prerequisite: you must be able to detect that a breach has occurred. Without logging, monitoring, and alerting infrastructure, you will not know within 72 hours.
Minimum monitoring for breach detection: - Anomalous data export: queries or API calls that return unusually large volumes of records - Authentication failures: repeated failed logins, especially against admin accounts - Privilege escalation: users accessing resources beyond their normal scope - Outbound data: unexpected large data transfers from your infrastructure
The breach notification process itself should be documented and rehearsed before it is needed.
Encryption and Transport
- [ ] TLS 1.2 minimum, TLS 1.3 preferred, on all endpoints handling personal data
- [ ] HSTS with includeSubDomains and max-age of at least 1 year
- [ ] Database encryption at rest verified and documented
- [ ] Sensitive fields encrypted at application layer where warranted
- [ ] Passwords hashed with bcrypt/Argon2 (cost factor appropriate for 2026 hardware)
Security Headers
- [ ] Referrer-Policy: strict-origin-when-cross-origin or stricter
- [ ] Permissions-Policy restricting unused browser APIs (camera, mic, geolocation)
- [ ] Content-Security-Policy with explicit third-party allowlist
- [ ] X-Content-Type-Options: nosniff
- [ ] X-Frame-Options: DENY or SAMEORIGIN
Access Control - [ ] MFA enforced for all administrative access - [ ] Principle of least privilege applied to all database and service accounts - [ ] Audit logging for all personal data access with sufficient retention - [ ] Automatic session expiry after configurable inactivity period - [ ] Complete server-side session invalidation on logout
Testing and Assessment - [ ] Automated security scanning in CI/CD pipeline - [ ] Penetration testing conducted at least annually - [ ] Vulnerability disclosure policy documented and published - [ ] Regular review of third-party dependencies for known CVEs
Incident Response - [ ] Breach detection monitoring in place - [ ] Incident response procedure documented and tested - [ ] DPA contact information stored and accessible - [ ] 72-hour notification process defined
Data Lifecycle - [ ] Retention periods defined for all personal data categories - [ ] Automated deletion or anonymization at retention expiry - [ ] Data subject request workflow implemented (access, erasure, portability)
Most EU member states require organizations processing personal data to register with their national Data Protection Authority (DPA). Even where registration is not mandatory, Article 30 requires you to maintain records of your processing activities.
Your Article 30 record should include: - Categories of personal data processed - Purposes of processing - Categories of recipients (including third-party services) - International transfers and safeguards - Retention periods - Security measures implemented
The security measures section is where your technical implementation lives. Document your encryption standards, access control policies, and security assessment cadence here.
ZeriFlow checks your site''s security headers, TLS configuration, and DNS records against 80+ security criteria, giving you a prioritized list of GDPR-relevant technical gaps to address. Run a free compliance-focused scan at zeriflow.com.
Related resources
Website Vulnerability Scanner
Run a broader website security audit across headers, TLS, DNS, cookies, SEO, and disclosure checks.
Security Headers Checker
Check CSP, HSTS, X-Frame-Options, and other response headers.
SSL Checker
Review TLS certificate, HTTPS, and transport security signals.
DMARC Checker
Validate email authentication records for domain spoofing protection.
CSP Checker
Review Content-Security-Policy coverage and common gaps.
April 30, 2026
Best SAST Tools for Small Development Teams in 2026 (Free Included)
Monitor your security score
Schedule recurring scans and catch regressions after deployments.