GDPR security controls: what Article 32 actually requires

GDPR contains no control catalogue. Article 32 names four measures as examples, sets a risk-based test, and leaves the rest to you. That openness is deliberate — and it is why security teams keep asking which controls are actually required, and keep getting an unsatisfying answer.

The honest answer: the controls that are appropriate to your risk, which you can show you chose deliberately. The useful answer is below — what the article says, what regulators consistently look at when something goes wrong, and which evidence holds up.

What Article 32 actually names

The article requires appropriate technical and organisational measures, taking into account the state of the art, costs of implementation, and the nature, scope, context and purposes of processing, against the risk to the rights and freedoms of natural persons. It then offers four examples:

• Pseudonymisation and encryption of personal data.
• The ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services.
• The ability to restore availability and access in a timely manner after a physical or technical incident.
• A process for regularly testing, assessing and evaluating the effectiveness of the measures.

Two of those four are about recovery and assurance rather than prevention, which is the part most control sets under-weight. Encryption gets the attention; the ability to prove you can restore, and that you test whether your controls work, is what the text actually emphasises.

The risk the controls must address

Article 32 is explicit about what you are protecting against: accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. Note that destruction, loss and alteration sit alongside disclosure. A ransomware event that encrypts personal data and nothing else is a personal data breach under GDPR even if not one record leaves the building — a point that still surprises teams who equate breach with exfiltration.

The controls regulators keep coming back to

Enforcement practice, rather than the text, is the better guide to priorities. Recurring themes:

• Access control and least privilege. Excessive standing access is a persistent finding — particularly support and administrative accounts that can read production personal data without a ticket.
• Multi-factor authentication on remote access and privileged accounts. Its absence is difficult to justify as state of the art.
• Encryption in transit and at rest, with attention to where data is decrypted and who can see it there. Encryption at rest on a disk that is always mounted protects against theft of the disk and very little else — say so in your risk assessment rather than claiming more.
• Patching and vulnerability management, with timelines you actually meet. A stated 30-day SLA that is routinely missed is worse evidence than a documented 60-day SLA that is met.
• Logging and monitoring sufficient to establish what was accessed. After an incident, the inability to determine which records were touched usually forces you to notify on the worst-case assumption.
• Backup and tested restoration. Article 32 asks for timely restoration; an untested backup does not evidence it.
• Pseudonymisation and minimisation in non-production environments. Copies of production personal data in test systems are a recurring root cause.

The organisational half

Technical and organisational measures — the second half carries as much weight in enforcement:

• Article 28 processor contracts with the required terms, and due diligence that is proportionate rather than a returned questionnaire nobody read.
• Article 32(4) instruction control: anyone acting under your authority processes personal data only on your instructions. In practice, this means role definitions and training, not a clause.
• Article 25 data protection by design and by default, evidenced by review at design time rather than a policy asserting it.
• Breach response: 72 hours to the supervisory authority from awareness, and notification to data subjects without undue delay where the risk to them is high.
• An internal breach register, including incidents you decided not to notify — with the reasoning recorded. Regulators read the ones you did not report.

The measure most often missing is the fourth one: a process for regularly testing and evaluating effectiveness. Implementing a control and never checking whether it works fails the article on its own terms.

How to document the choice

Because the standard is appropriateness rather than a fixed list, the defensible artefact is the reasoning. For each significant processing activity, record the risk to individuals, the measures selected, what you considered and rejected, and when you last tested effectiveness. That record is what turns "we thought it was enough" into a demonstrable decision — and it is the difference between a finding and an aggravating factor.

Key takeaways

• Article 32 names four measures and a risk test, not a control catalogue — the reasoning is the deliverable.
• Loss and alteration are breaches too; ransomware qualifies without any exfiltration.
• Testing effectiveness is an explicit requirement, and the one most commonly skipped.
• Insufficient logging usually forces worst-case notification, which makes it a compliance control as well as a security one.