GDPR Technical Security Requirements Every Website Must Meet

GDPR is often discussed in terms of consent banners and privacy policies, but Article 32 — "Security of processing" — is where most websites quietly fail. It requires controllers and processors to implement appropriate technical and organisational measures to protect personal data. Regulators have repeatedly fined companies not for missing paperwork, but for missing technical controls: weak TLS, exposed cookies, leaked headers, broken access controls.

If you run a website that collects names, emails, IP addresses, or any behavioural data, here's what GDPR technical security requirements for websites actually look like at the implementation level.

What Article 32 Actually Demands

The regulation specifies four pillars, but leaves the implementation to you:

• Pseudonymisation and encryption of personal data
• Ongoing confidentiality, integrity, availability and resilience of processing systems
• Ability to restore availability after an incident
• A process for regularly testing and evaluating the effectiveness of those measures

That last point is critical — GDPR is not a one-time checklist. Whatever security controls you ship, you must be able to prove you test them on an ongoing basis.

Transport Layer Security: The Non-Negotiable Baseline

Encryption in transit is the most basic Article 32 control, and it's the first thing a DPA (Data Protection Authority) will check after a breach.

Minimum TLS configuration

• TLS 1.2 minimum, TLS 1.3 preferred
• Disable SSLv3, TLS 1.0 and TLS 1.1 — these are explicitly considered insecure
• Use strong cipher suites with forward secrecy (ECDHE-based)
• Valid certificate from a trusted CA, with auto-renewal
• HSTS enabled with a minimum max-age of 6 months

A working HSTS header looks like this:

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

Without HSTS, a user typing example.com can still be intercepted before the redirect to HTTPS happens. From a GDPR perspective, that's an unencrypted transmission of personal data — which is reportable if it leads to exposure.

HTTP Security Headers as a Compliance Layer

Security headers don't appear in the GDPR text, but they map directly to "appropriate technical measures." Missing headers are routinely cited in audit findings.

The headers regulators expect

1. Content-Security-Policy — prevents XSS, which is one of the most common vectors for stealing session cookies and personal data
2. X-Content-Type-Options: nosniff — blocks MIME confusion attacks
3. Referrer-Policy: strict-origin-when-cross-origin — stops leaking URLs (often containing tokens or IDs) to third parties
4. Permissions-Policy — restricts access to camera, microphone, geolocation
5. X-Frame-Options: DENY or a CSP frame-ancestors directive — prevents clickjacking of authenticated sessions

A weak or missing CSP is particularly dangerous under GDPR because supply-chain attacks (think Magecart-style skimmers) directly exfiltrate personal and payment data through injected scripts. Running an automated scan with a tool like WebSentry will flag exactly which of these headers are missing and grade their configuration — useful evidence for your Article 32 documentation.

Cookies and Session Security

Cookies are dual-regulated: they fall under both GDPR and the ePrivacy Directive. The technical controls matter as much as the consent banner.

Secure cookie flags

• Secure — only transmit over HTTPS
• HttpOnly — block JavaScript access to session cookies
• SameSite=Lax or Strict — mitigate CSRF and cross-site leakage
• Reasonable Max-Age — long-lived session cookies extend breach impact

Any cookie containing personal data, session identifiers, or analytics IDs that lacks Secure and HttpOnly is a finding waiting to happen. If you set cookies before consent is given (other than strictly necessary ones), you're combining a GDPR violation with a technical vulnerability.

DNS Hygiene and Email Spoofing Protection

DNS misconfiguration is frequently overlooked in GDPR audits but matters for two reasons: integrity of communications and protection against phishing that targets your users' data.

• SPF record published and not overly permissive
• DKIM signing configured for all sending domains
• DMARC policy set to quarantine or reject, not just none
• CAA records to restrict which CAs can issue certificates for your domain
• DNSSEC where your registrar supports it

A DMARC policy of p=none means anyone can spoof your domain and phish your customers. That's a foreseeable risk you've chosen not to mitigate.

CORS and API Exposure

If your site has any kind of API — and almost all modern sites do — CORS misconfiguration can quietly leak personal data across origins.

Common mistakes to fix

• Access-Control-Allow-Origin: * combined with Access-Control-Allow-Credentials: true (browsers block this, but reflective origin bugs slip past)
• Reflecting any Origin header without an allowlist
• Allowing null as an origin
• Permissive preflight responses on endpoints that return user data

Access Control, Logging, and Breach Detection

Article 33 requires breach notification within 72 hours of becoming aware. You can't be aware of a breach you aren't logging for.

• Centralised logging for authentication events, admin actions, and API access
• Alerting on anomalies — failed logins, mass data exports, off-hours admin access
• Rate limiting and brute-force protection on login and password reset endpoints
• MFA for all admin and CMS accounts (this is rapidly becoming a regulator expectation, not a suggestion)
• Documented retention periods for logs themselves — logs contain personal data too

Backup, Restore, and Resilience

"Ability to restore availability and access in a timely manner" is a direct quote from Article 32. In practice:

1. Automated, encrypted backups stored in a separate location from production
2. Tested restore procedures — an untested backup is not a backup
3. Documented RPO and RTO targets appropriate to the data sensitivity
4. Patch management process with defined SLAs for critical CVEs

The "Regularly Tested" Requirement

This is the requirement most teams ignore. GDPR explicitly requires a process for regularly testing, assessing and evaluating your technical measures. That implies:

• Periodic vulnerability scanning of public-facing assets
• Annual or biannual penetration testing for higher-risk sites
• Continuous monitoring of TLS, headers, and DNS configuration drift
• A documented remediation workflow with owners and deadlines

This is where automated scanners earn their place. Running WebSentry on a schedule gives you dated reports showing SSL grade, header configuration, CSP strength, cookie flags, DNS records, and CORS posture — exactly the evidence trail an auditor or DPA will ask for after an incident.

A Practical Starting Checklist

If you're auditing a site against GDPR technical security requirements right now, work through this in order:

1. Force HTTPS everywhere; enable HSTS with preload
2. Add CSP, Referrer-Policy, X-Content-Type-Options, Permissions-Policy, X-Frame-Options
3. Audit every cookie for Secure, HttpOnly, and SameSite flags
4. Publish SPF, DKIM, DMARC (p=quarantine minimum) and CAA records
5. Lock down CORS to an explicit allowlist
6. Enable MFA on all admin accounts and centralise auth logs
7. Verify your backup restores actually work
8. Schedule monthly scans and document the results

Run a free scan of your domain at websentry.dev to see exactly where your site stands against these controls — and where the gaps are before a regulator finds them for you.