GDPR Article 32 & Website Security: What 'Appropriate Technical Measures' Requires

Article 32(1) requires controllers and processors to implement technical and organisational measures to ensure a level of security "appropriate to the risk," taking into account the state of the art, implementation costs, and the nature, scope, and purposes of processing. It gives four non-exhaustive examples: pseudonymisation and encryption of personal data; the ability to ensure ongoing confidentiality, integrity, availability, and resilience of processing systems; the ability to restore availability and access after an incident; and a process for regularly testing and evaluating the effectiveness of measures.

Notice what's missing from that list: no mention of HTTPS, no mention of HTTP headers, no mention of cookie flags. Article 32 is deliberately technology-neutral and risk-based — it tells you the outcome required (confidentiality, integrity, availability, resilience) without prescribing the specific mechanism, because the same law has to apply to a five-page brochure site and a hospital's patient portal.

They're the concrete implementation of "confidentiality... of processing systems" for the most common case: a website that transmits personal data (a contact form, a login, a checkout, even just an IP address in a server log) between a visitor's browser and your server. Encryption in transit — HTTPS with a valid certificate, no fallback to plain HTTP — is the baseline mechanism for that outcome, and it's about as close as website configuration gets to being explicitly named in Article 32's own text ("encryption of personal data").

HTTP security headers are a step further from the statute's wording but are widely treated by security guidance (OWASP, browser vendors, national cybersecurity agencies) as standard, low-cost measures that reduce common attack classes — clickjacking, MIME-sniffing, protocol downgrade — that would otherwise put the confidentiality or integrity of a processing system at risk. A regulator investigating a breach won't cite "you were missing a Content-Security-Policy header" as the sole finding, but a pattern of absent baseline hardening is exactly the kind of thing that gets referenced when assessing whether measures were "appropriate."

Not by name, and cookie rules themselves mostly come from the ePrivacy Directive (consent, purpose disclosure) rather than the GDPR directly. But once a cookie carries a session identifier or any personal data, Article 32's confidentiality and integrity obligations apply to that cookie the same way they apply to any other personal data in transit or storage. The Secure flag prevents a cookie from being sent over plain HTTP; HttpOnly blocks client-side scripts (including injected malicious ones) from reading it; SameSite limits cross-site request forgery exposure. Missing all three doesn't just weaken "security" in the abstract — it weakens the specific confidentiality guarantee Article 32 asks for on any cookie that touches personal data.

These three DNS records authenticate email sent from your domain, making it harder for someone to send a convincing phishing email that appears to come from you. The GDPR connection is indirect but real: contact forms, data subject access requests, and breach notifications typically flow through email, and a domain that's easy to spoof is a domain that's easier to use for social-engineering attacks against your own staff or your customers — attacks that frequently precede the kind of security incident Article 32 is meant to prevent in the first place.

None of the three are perfectly discoverable from outside. SPF and DMARC live at predictable DNS locations (a TXT record on the domain, and one at `_dmarc.<domain>`), so they can be checked directly. DKIM has no single standard location — it depends on a selector chosen by whichever service sends your mail — so any external check for DKIM is necessarily a best-effort search of common selectors, not a definitive absence finding.

No, and treating it that way would overstate what a configuration check can do. Article 32 compliance is a documented, risk-based determination — it requires you to have actually assessed the risk of your specific processing and chosen measures proportionate to it, not just to have a green checkmark next to a fixed list of technical settings. A five-employee blog and a site processing special-category health data face very different "appropriate" bars even if both pass the same header check.

What a configuration check is genuinely useful for is closing the gap between "we assumed this was set up correctly" and "we verified it." Missing HTTPS enforcement, absent security headers, or unauthenticated email for a domain that processes personal data are exactly the kind of avoidable, easily-fixed gaps that are hard to justify as "appropriate" under any risk assessment — so ruling them out is a reasonable first step, not the whole exercise.

The parts covered above — HTTPS/TLS, standard security headers, cookie flags, and SPF/DMARC/DKIM — are all externally observable from a browser's or a DNS resolver's point of view, which makes them well suited to an automated check that runs in seconds rather than a manual audit. What that kind of check can't do is assess your internal risk documentation, your access controls, or your incident-response process — those are organisational measures under Article 32, and they need to be evaluated on their own terms, typically with legal or DPO input rather than a scanner.