GDPR and Web Security: What Developers Must Implement in 2026

GDPR and Web Security: What Developers Must Implement in 2026

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.

What Article 32 Actually Requires

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:

• The state of the art and costs of implementation
• The nature, scope, context, and purposes of processing
• The risks to the rights and freedoms of individuals

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.

Encryption in Transit: TLS Requirements

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

HSTS Implementation

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

HSTS 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.

Encryption at Rest

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 projects

Application-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);

Security Headers That Directly Support GDPR Compliance

Several security headers have a direct relationship with GDPR''s data minimization and purpose limitation principles.

Referrer-Policy

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-origin

This 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.

Permissions-Policy

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.

Content-Security-Policy and Third-Party Data Flows

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.

Access Control and Authentication

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();
});

Breach Notification: The 72-Hour Clock

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.

GDPR Security Compliance Checklist for Developers

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)

DPA Registration and Article 30 Records

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.