Unencrypted forms and invalid certificates — what does the GDPR require?
The GDPR does not literally say your website must have https. But article 32 requires technical measures appropriate to the risk, and explicitly mentions encryption as an example of such a measure. For a form that sends personal data, transport encryption is today's baseline expectation — a form posting over unencrypted http can be eavesdropped on or tampered with along the way. And a certificate that has expired or was issued for the wrong domain does not protect much better: the visitor can no longer trust who they are talking to.
What does the law say?
Under GDPR article 32, the controller must implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. The requirement is risk-based and technology-neutral — no fixed checklist — but encryption is explicitly mentioned in the article as an example of such a measure.
For web forms sending personal data, that lands in a clear baseline expectation: transport encryption via https/TLS. A contact form typically sends a name, an email address and free text — personal data — and without TLS they travel in cleartext across the network. The more sensitive the data the form handles, the higher the bar, with login credentials at the top.
Unencrypted forms — what can go wrong?
A form posting over http sends its contents unprotected: it can be eavesdropped on or manipulated on the way between the visitor and the server. That concerns both confidentiality — someone reads the data — and integrity — someone alters it in transit.
Login forms are especially sensitive: a password in cleartext over http exposes the entire account, and everything behind the login.
The sneaky variant is the website that looks encrypted but isn't all the way: the page is served over https, but the form's target (action) points to an http address — or the site can still be reached via http without a redirect. The padlock in the address bar says nothing about where the form actually sends the data.
Invalid certificates — expired, self-signed or wrong domain
The certificate is what attests who the visitor is actually talking to. A certificate that has expired, is self-signed or was issued for the wrong domain name means the authenticity of the connection cannot be guaranteed — the visitor is met with security warnings, and modern browsers often block the page entirely.
One nuance: the traffic is still encrypted by TLS even with an invalid certificate. The problem is that the visitor cannot know who the traffic is encrypted towards — a connection whose counterpart cannot be verified cannot be guaranteed to be safe from tampering. And in plain practical terms, a blocked page is a closed door: a visitor met by a warning screen turns around.
Common issues we see
- The website is on https, but a form posts to an http address — the encryption on the page does not help the form that is sent unencrypted.
- The site can still be reached over http without a redirect, so the forms can be filled in and submitted entirely unprotected.
- A login form lives on an older page or subdomain that never got https — the passwords travel in cleartext.
- The certificate has expired — often because renewal was handled manually and got forgotten.
- The certificate covers the wrong name: it is valid for www.example.com but not example.com, or the other way around.
How CompliantHQ tests this
The scanner deterministically checks that forms collecting personal data or login credentials are submitted encrypted — a form whose target is an http address is flagged, with the form and its target pointed out so you can see exactly where the gap is.
In parallel, the website's certificate is checked: that it is not expired, not self-signed and issued for the right domain name. Both checks are deterministic — no judgement calls, just observed facts about the connection.
The checks are included already in the trial.
How to fix it
- Get a valid certificate from a trusted issuer — Let's Encrypt is free and perfectly sufficient.
- Serve the entire website over https and force a redirect from http, so that no page — and no form — can be reached unencrypted.
- Check the forms' targets (action): they must point to https addresses, even when the page itself is already on https.
- Make sure the certificate covers exactly the domain name your visitors use — including both with and without www.
- Automate certificate renewal so it never gets a chance to expire.
What the check covers
- That forms with personal data or logins are submitted encrypted (https) — unencrypted forms can be eavesdropped in transit.
- That the site's security certificate is valid — not expired, self-signed or issued for the wrong address.
Common questions
Does my website have to use https under the GDPR?
The GDPR does not mention https literally, but article 32 requires security measures appropriate to the risk and explicitly points to encryption as an example. For forms sending personal data, transport encryption is today's baseline expectation.
Does the data in a contact form really count as personal data?
Yes — a name, an email address and often the free text of the message are personal data. If the form is submitted over http, they travel in cleartext and can be intercepted along the way.
Isn't the traffic encrypted anyway if the certificate has merely expired?
Yes, TLS still encrypts — but an invalid certificate means the authenticity cannot be guaranteed: the visitor cannot know who the traffic is encrypted towards. That is why browsers warn, and often block the page entirely.
Is a free certificate from Let's Encrypt enough?
Yes. What matters is that the certificate is valid, issued by a trusted issuer and covers the right domain name — not what it costs. Automate the renewal and it never gets a chance to expire.
Want to see what we find on your site?
Run a free scan — all four modules included for 30 days, no card required.