UK GDPR Article 32: HTTPS and security headers

The rule

Article 32 of the UK GDPR is headed security of processing. It is risk-based and it names no technology. The ICO’s penalty notice to DPP Law Ltd sets out its core text.

The word “transmitted” matters for a website, because it brings data on its way between a visitor’s browser and the server inside the article. Article 32(1) also lists, among its examples, “the pseudonymisation and encryption of personal data” and regular testing of how well the measures work (legislation.gov.uk).

The ICO has said what that means for a website. Its encryption guidance states that “if you provide a website, you should use HTTPS across all its pages. This is especially important for safeguarding personal information.” It relays the NCSC’s statement that SSL “must not be used” on a public-facing HTTPS site, and it recommends HTTP Strict Transport Security (HSTS) “to force all connections to use HTTPS instead of unencrypted HTTP”. The ICO’s wider data security guide says an organisation should consider “the security of your website and any other online service or application that you use”, and have “a process for regularly testing, assessing and evaluating the effectiveness of any measures you put in place”. The ICO’s encryption guidance names Content-Security-Policy only for its “upgrade-insecure-requests” directive, to force third-party content onto HTTPS. The pages read do not name X-Frame-Options, so that header is better described as common practice.

The ICO often cites Article 32 together with Article 5(1)(f), the integrity and confidentiality principle, which sits in the upper tier. In the British Airways notice the ICO adds that it must avoid reasoning “purely with the benefit of hindsight”.

What PeekWell checks and how

UK-15 asks what your server says about itself to every visitor. It doesn’t ask whether the site can be broken into, and it can’t answer that.

The scan is automated. It opens your public pages the way an ordinary browser does and notes what the server shows any visitor: the TLS version and cipher, whether the site’s TLS identity is in date, and the HSTS, Content-Security-Policy and X-Frame-Options headers. It also notes mixed content, which is a page on HTTPS that still loads some resources over plain http. An expired or weak TLS identity, a missing HSTS or Content-Security-Policy header, or mixed content becomes a finding. 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 doesn’t port-scan, try to get in where it isn’t allowed, send unusual requests, run any security test or open addresses nobody linked to. It can’t see how data is stored, who inside the company can reach it, or what happens on a server after a form is sent. A Passed means the expected setup was observed on the pages scanned. It doesn’t say the site complies.

The check is the same as for the European rule. EU-15 covers the CNIL and Garante decisions, and US-15 adds a check of well-known paths. Only the law the observations are read against differs.

Why it matters for a company

None of the ICO decisions below turns on a missing header. They show how the ICO reads Article 32 once something has gone wrong, and the HTTPS guidance above shows what it expects from a website.

The British Airways notice of 16 October 2020 imposed £20 million. Between 22 June and 5 September 2018 an intruder used compromised credentials for a remote-access gateway and eventually edited a JavaScript file on britishairways.com, designed to send cardholder data to a domain the intruder controlled. The ICO found that BA had not processed customers’ data with appropriate security, under Articles 5(1)(f) and 32 of the GDPR as it applied at the time, for about 429,612 people. BA did not admit liability, and the ICO took account of its prompt notification, its cooperation and the effect of the pandemic when it set the amount.

DPP Law Ltd was fined £60,000 on 14 April 2025 for infringements of Articles 5(1)(f), 32(1), 32(2) and 33(1). The ICO found that the firm did not apply least privilege or audit its administrator accounts, and that a legacy-system service account with full network rights had no multi-factor authentication. Data on 791 clients and experts was taken and posted on the dark web. The ICO press release of 16 April 2025 says the intruders used brute force. The notice records fewer than 250 staff and a turnover of £3,486,494 in 2023/24, and the ICO weighed that turnover when it set the figure.

Two reprimands point the same way. In April 2024 the ICO reprimanded Clyde Valley Housing Association after a new online portal, on its first day, let residents see other residents’ documents, and the ICO said it had not been properly tested before launch. In August 2026 it reprimanded ACRO after unauthorised access to its website and content management system, citing Article 32.

For a company the reading is practical. The ICO’s guidance treats testing as part of the duty, its notices describe what happened after a gap was left open, and its HTTPS guidance says what it expects a website to have in place.

Smaller companies and larger companies

Article 32 has no size threshold, and the ICO weighs turnover only when it sets a fine, as the DPP notice shows. The risk to people is what counts.

In a smaller company the site is often a hosted builder or a plugin-heavy content system. The main address has HTTPS, and the gaps are at the edges: an old subdomain on plain http, images linked with http addresses that produce mixed content, a TLS identity that expired because the renewal was tied to one person’s card, and a hosting default that sends no security headers. DPP Law shows that a firm with a turnover of a few million pounds is within the ICO’s reach, though its case was about account access, not a website setup.

In a larger company the same problems multiply. There are many hostnames, agency microsites, legacy portals and a tag manager that adds third-party scripts. A content security header is loosened because it broke a tag and then left that way. TLS settings differ between the main site and the customer area. British Airways shows why scripts matter: the card data left through a changed file on the live site.

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 pages link to, including ones an agency built.
2. Redirect http to https everywhere. Use a permanent redirect on every hostname, to the same host.
3. Allow only TLS 1.2 and 1.3. Switch off SSL and older TLS versions in the server, load balancer or CDN settings. The ICO says TLS 1.3 and 1.2 provide strong protection when configured correctly.
4. Automate renewal and watch the dates. Let the TLS identity renew by itself and send expiry warnings to a shared mailbox.
5. Fix mixed content. Search templates, the database and the page builder for http:// links to images, scripts and fonts, and 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 when every subdomain answers over HTTPS.
7. Add the content security headers. Run Content-Security-Policy in report-only mode first and read the reports. Set frame-ancestors or X-Frame-Options so other sites cannot frame yours.
8. Test on a schedule. The ICO’s guide asks for regular testing of the measures. Put a dated re-scan in the calendar, and run one now to check the 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. Whether it meets your obligations is a question for your adviser, and Peeky reports only what it sees.