GDPR Article 32 in practice: which security controls actually satisfy it

Article 32 is the part of GDPR that engineers actually have to implement, and it is written to frustrate anyone looking for a checklist. "Appropriate technical and organisational measures" appropriate "to the risk," taking into account "the state of the art" and "the costs of implementation." That is the law deliberately refusing to name your firewall rules.

Which is fine, until there is a breach, and a data protection authority reads Article 32 backwards from the incident to decide whether your measures were appropriate. That is the lens that matters. Not "did we tick Article 32" but "would a regulator, holding the breach in one hand and our control evidence in the other, agree the measures matched the risk."

What the article actually says to build

Strip the risk-based framing and Article 32(1) does point at concrete capabilities. It names pseudonymisation and encryption directly in 32(1)(a). Then 32(1)(b) asks for the ongoing confidentiality, integrity, availability and resilience of processing systems. 32(1)(c) wants the ability to restore availability and access to personal data in a timely manner after a physical or technical incident. And 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of those measures.

Read it as four obligations and the mapping to a normal security program is obvious.

Encryption and pseudonymisation is your data-at-rest and in-transit crypto, which is the same control as ISO 27001 A.8.24 and CIS Safeguard 3.11. The cryptography crosswalk lines these up across frameworks, and it is the clause regulators reach for first because it is the one with a yes or no answer. Was the lost laptop encrypted. Was the exposed bucket encrypted and access-controlled. There is no risk argument that makes unencrypted personal data at rest look appropriate in 2026 when full-disk and database encryption are free.

The CIA-plus-resilience clause is broader: access control, network segmentation, monitoring, the usual technical and organizational measures. This is where most of Annex A lives.

The restore clause is the one teams forget is a security control. Backups that have never been restored do not satisfy 32(1)(c). I mean that literally. If your last restore test was the initial setup, you cannot claim the ability to restore in a timely manner, and ransomware cases are exactly where DPAs ask for evidence of it.

The testing clause, 32(1)(d), is vulnerability scanning, penetration testing, and internal audit. Not as a one-time exercise. As a process, with a cadence, with findings that get closed.

Why "we follow ISO 27001" is a strong answer

Article 32(3) says adherence to approved codes of conduct or an approved certification mechanism can be used as an element to demonstrate compliance. ISO 27001 is not an approved GDPR certification in the Article 42 sense, so it does not automatically prove Article 32. But in practice, an ISMS with a real risk assessment and a Statement of Applicability is the cleanest way to show a regulator that you chose measures appropriate to risk, because that is the exact reasoning Article 32 demands and ISO 27001 forces you to document.

That is the quiet value of the mapping. Article 32 wants a risk-based justification for your controls. ISO Clause 6 produces precisely that artifact. When you crosswalk GDPR Article 32 to your ISO controls, you are not just relabeling, you are attaching the risk rationale a DPA will ask for.

The mistakes that turn an incident into a fine

A few patterns show up again and again in enforcement decisions, and none of them are exotic.

No encryption where it was feasible and cheap. This is the easiest finding a regulator can make and the hardest to defend, because the state-of-the-art and cost tests both cut against you.

No access control on the blast radius. A single compromised credential reaching an entire personal-data store reads as a failure of the confidentiality measure, and "we had a password policy" does not answer it. MFA and least privilege are the expected baseline now.

Restore that was never tested, surfaced during a ransomware response when the team discovers the backups are incomplete or themselves encrypted.

And no evidence of the 32(1)(d) testing process, which is the difference between "we have security measures" and "we can show they were effective." A regulator weighing a fine under Article 83 looks at exactly that, and the presence or absence of a documented, recurring effectiveness review moves the number.

Article 32 will never hand you a control list, and that is the point. It hands you a risk standard and asks you to map controls onto it. Do that mapping deliberately, keep the crosswalk to your frameworks current, and the appropriateness argument is already written when you need it.