GDPR Article 32: HTTPS and security headers

The rule

Article 32 of the GDPR is headed security of processing. It is short, it is risk-based, and it names no technology. The wording below is taken from the Official Journal text, read at the Publications Office mirror.

The measures are proportionate to the risk, so a login form that carries invoices is held to more than a brochure page, and “state of the art” moves over time.

The article does not mention HSTS, content security headers or TLS versions. Those come from regulators’ guidance. The CNIL’s web security page, dated 14 March 2024, asks organisations to “mettre en œuvre le protocole TLS sur tous les sites web, en utilisant uniquement les versions les plus récentes”, and to make it mandatory on pages that handle authentication or personal data. The CNIL’s 2020 sheet on securing websites asks for TLS 1.2 or 1.3, TLS on all pages, and mentions HSTS to force HTTPS for authentication cookies. Neither page names Content-Security-Policy or X-Frame-Options, so those two headers are better described as widely used practice than as something an authority has asked for.

Penalties sit in two tiers. The CNIL’s own page gives the general ceiling as 10 million euros or 2% of worldwide annual turnover, and 20 million euros or 4% for the most serious infringements. Article 83(4)(a) places the controller’s and processor’s obligations under Articles 25 to 39, which include Article 32, in the lower tier; the same numbering appears in the retained UK text. The check’s citation lists Art. 83(4), and that is where this obligation sits. Authorities often cite Article 32 together with Article 5(1)(f), which sits in the upper tier.

What PeekWell checks and how

EU-15 asks what your server says about itself to every visitor. It does not ask whether the site can be broken into, and it cannot answer that.

The scan opens a public page the way an ordinary browser does. It reads the TLS handshake, which gives the protocol version, the cipher and whether the site’s TLS identity is in date, and it reads the response headers. It looks at HSTS, Content-Security-Policy and X-Frame-Options, and it notes mixed content, which is a page loaded over HTTPS that still pulls in some resources over plain http. The results are compared with a baseline. An expired or weak certificate, a missing HSTS header, a missing Content-Security-Policy header or mixed content becomes a finding. HSTS, Content-Security-Policy and X-Frame-Options are all read.

The decision is made by code from what the server sent. A language model may help word the explanation, but it never decides that a header is absent. The default severity is low, and the report frames a gap as a question about appropriate measures, never as a proven failure.

The scan has limits, and the report says so. It reads the advertised TLS and header setup of the public pages it visited, and nothing more. It does not sign in, submit forms, test passwords, send unusual requests or open addresses nobody linked to. It cannot see how data is stored, who has access inside the company, or what happens on a server after a form is sent. A Passed means the expected setup was observed on the pages scanned. It does not say the site complies.

The same engine runs for the British and American rules. UK-15 and US-15 describe the same observation read against their own law. US-15 adds a check of well-known paths, which this check does not do.

Why it matters for a company

None of the decisions below is about a missing header. The Garante and the CNIL have dealt with the layer underneath: whether data travels in the clear, and whether documents are reachable by anyone who asks.

In October 2022 the Garante decided a complaint about a water utility. Users signed in to a customer area, where they saw names, tax codes, contact details and invoices for about 13,000 registered users, including over 2,000 businesses. The area ran over http. The Garante wrote that failing to use cryptographic techniques for the transport of data amounts to an infringement of Articles 5(1)(f) and 32, and that the company should have adopted a secure protocol “quale il protocollo https” from the design stage. It set the fine at 15,000 euros, counting the number of users and the fact that the company had not acted after the complainant raised the problem twice.

The CNIL’s SERGIC decision of 28 May 2019 concerned documents sent by rental applicants. Changing the number in an address returned someone else’s file, with no authentication step. The CNIL called an authentication procedure “une précaution d’usage essentielle”, noted that the flaw was known from March 2018, and recorded the company’s statement that a fix was due to go into production on 17 September 2018. It fined the company 400,000 euros for this flaw and for keeping applicants’ data longer than needed (Articles 32 and 5(1)(e)).

On transport itself the CNIL has written to organisations. Its 2023 report records 39 formal notices to public bodies, such as regions and municipalities, whose sites did not use HTTPS. Its March 2024 note on simplified sanctions describes fines for organisations that kept TLS 1.0 or 1.1, and the SHA-1 hash function, after a formal notice. The page does not name them.

For a company the practical points are three. These facts are visible from outside, so an authority needs no inside access to notice them. In several of the matters above, a complaint or a formal notice came first. And the cost of leaving a known gap open grows with the number of people whose data passes through it.

Smaller companies and larger companies

Article 32 has no size threshold, but it is risk-based, so the same gap weighs differently depending on what the site carries. The risk is about the data and the people, not the headcount.

In a small company the site usually sits on a hosted builder or a managed plan, which switches on HTTPS for the main address. The gaps appear at the edges. An old shop subdomain still answers on http. Product images are linked with absolute http addresses from years ago, so every page has mixed content. A TLS identity expires because the renewal was tied to one person’s card or inbox. Headers are not set because nobody owns the server configuration, and the host’s default does not include them. No decision against a company confirmed as small was found for this check.

In a larger company the same problems multiply. There are dozens of hostnames, campaign microsites built by agencies, legacy portals, and tag managers that inject third-party scripts. A content security header is often loosened or dropped because it broke a tag, and then never tightened. TLS settings differ between the main site and the customer area, which is the pattern in the SERGIC and water-utility decisions: the public front looks fine and the sign-in or document area behind it does not.

How to fix it

1. List every hostname. Write down the main domain, www, the shop, the customer area, the blog and any subdomain your site links to. Check each one in a private window. Include the ones an agency built.
2. Redirect http to https everywhere. Use a permanent redirect on every hostname and make sure the redirect goes to the same host, not through a third-party address.
3. Allow only TLS 1.2 and 1.3. Switch off older versions and weak ciphers in the server, load balancer or CDN settings. The CNIL’s guidance asks for recent versions only.
4. Automate renewal and watch the dates. Set the TLS identity to renew by itself and send expiry warnings to a shared mailbox, not a person.
5. Fix mixed content. Search templates, the database and the page builder for http:// links to images, scripts and fonts. Change them to https:// or to relative paths.
6. Add HSTS, then raise it. Start with a short max-age, check nothing breaks, then extend it. Add includeSubDomains only once every subdomain answers over HTTPS.
7. Add the content security headers. Start Content-Security-Policy in report-only mode and read the reports. Set frame-ancestors or X-Frame-Options so other sites cannot frame yours.
8. Re-scan. Run a scan again and check that the TLS and header findings are gone.

add_header Strict-Transport-Security "max-age=86400" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy-Report-Only "default-src 'self'" always;

The snippet is a starting point, not a finished policy. A real content security policy has to list the scripts and services your pages use, and your adviser can say what suits your risk. Peeky reports only what it sees.