Does GDPR require my website to use HTTPS?

In practice, yes. GDPR Article 32 requires 'appropriate technical measures' to secure personal data, and names encryption specifically. Any page that collects personal data — a contact form, a login, a checkout — sends it across the network, and sending that in plain HTTP is exactly the kind of failure regulators treat as inadequate security. Serve everything over TLS (HTTPS), and enforce it with HSTS.

What are the website security measures GDPR Article 32 expects?

Article 32 doesn't list exact settings, but the widely accepted technical baseline for a website is: TLS on every page with modern protocol versions (no old SSL/TLS 1.0/1.1), HTTPS enforced with HSTS, security headers like Content-Security-Policy, cookies set with the Secure, HttpOnly and SameSite flags, a valid unexpired certificate, and email authentication (SPF/DKIM/DMARC) to reduce spoofing of your domain. These are all things an outside checker can verify.

What are the fines for weak security under GDPR?

GDPR's higher penalty tier is up to €20 million or 4% of the organization's total worldwide annual turnover, whichever is higher — and failures of the core security obligations in Article 32 fall into that higher tier. As of 2025, regulators may calculate the turnover figure against an entire corporate group, not just the individual entity.

The GDPR website-security checklist

Published September 21, 2026 · about a 6-minute read

Say "GDPR" and most people picture a cookie banner and a privacy policy. Those matter, but they're the paperwork half. There's a quieter half — Article 32, "security of processing" — that asks whether your website actually protects the personal data flowing through it. And it's the security half, not the cookie banner, that draws the eye-watering fines.

Good news: the website-security part of GDPR is concrete and checkable. Here's what it expects, in plain English.

What Article 32 actually says

Article 32 requires "appropriate technical and organisational measures to ensure a level of security appropriate to the risk," and it names encryption as an example. It deliberately doesn't hand you a settings list — the idea is that a bank and a brochure site face different risks. But for any website that touches personal data (a contact form counts), a well-established technical baseline has emerged, and regulators lean on it when they judge whether your measures were "appropriate."

The useful thing about that baseline: nearly all of it is visible from outside your infrastructure. An auditor — or a regulator, or an attacker — can check it in minutes. So can you.

The checklist

These are the externally verifiable measures that make up a defensible GDPR website-security posture:

TLS on every page. Personal data in transit must be encrypted. Any form, login or checkout served over plain HTTP is the textbook example of inadequate security. Serve the whole site over HTTPS.
Modern protocol versions only. Article 32 talks about "state of the art." Old SSL and TLS 1.0/1.1 are not it — disable them and serve TLS 1.2/1.3 with strong ciphers.
A valid, unexpired certificate. An expired cert means data stops being protected in transit and visitors get a scary warning. It's a security lapse and a trust lapse at once — don't let it happen silently.
HTTPS enforced with HSTS. Redirecting to HTTPS isn't enough on its own; HSTS tells browsers to refuse plain HTTP entirely, closing the downgrade gap.
Security headers. A Content-Security-Policy and the other standard headers reduce the XSS and injection risks that lead to data exposure in the first place.
Secure cookies. Any cookie carrying a session or personal data should have the Secure, HttpOnly and SameSite flags. Missing flags are a common, easily-found finding.
Email authentication. SPF, DKIM and DMARC stop attackers from spoofing your domain to phish your users' personal data — an angle regulators increasingly expect you to have covered.

None of this is exotic. It's the boring baseline — and "we skipped the boring baseline" is exactly the story a regulator wants to avoid writing about you after a breach.

Why the security half is the expensive half

GDPR has two penalty tiers. The higher one — up to €20 million or 4% of total worldwide annual turnover, whichever is higher — is where the core security obligations of Article 32 sit. Regulators treat "you didn't put appropriate measures in place" as a more serious failing than a procedural slip. And as of 2025, that turnover figure can be calculated against an entire corporate group, not just the entity that slipped. A missing header won't get you fined on its own, but a breach traced back to security you demonstrably neglected is precisely the higher-tier scenario.

"Appropriate" is a moving target — so check continuously

Here's the part that trips people up. Article 32 isn't a one-time certification you frame on the wall. "Appropriate measures" means currently appropriate. A certificate that was valid last quarter expires. A header that was set gets dropped in a redeploy. A protocol that was fine gets deprecated. The day any of those slips, your defensible posture quietly stops being defensible — and you won't know unless something is watching.

That's the whole reason external monitoring exists. See where your site stands right now with our free site checker — it grades your TLS, headers, cookies and DNS against exactly this baseline, no signup — and if you're accountable for keeping it that way, a dated record of "these measures were in place, continuously" is the evidence that turns a scramble into a shrug.

Check your GDPR security baseline

Perimeter grades your TLS, security headers, cookies and DNS/email records against the Article 32 baseline — and re-checks them continuously, with dated reports you can keep as evidence. Free scan, no signup.

Keep the evidence current → · Compliance plan $49/mo, with dated reports