What "appropriate technical and organisational measures" actually requires under GDPR

GDPR Article 32 is probably the most cited provision in security compliance. It requires organisations to implement “appropriate technical and organisational measures” to ensure a level of security appropriate to the risk. Most organisations interpret this as: implement controls, document them, pass the audit.

That interpretation misses the fourth subparagraph.

Article 32(1)(d)

The full text of Article 32(1)(d) requires “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.”

Three elements are embedded in that sentence, and each one carries a distinct obligation.

First: a process. Not a one-time exercise. Not an annual event. A documented, ongoing process with a defined cadence, defined inputs, and defined outputs. The word “process” means there is a system — something that runs on a schedule, produces records, and can be demonstrated to an auditor as a functioning piece of organisational machinery.

Second: regularly. This is a frequency obligation. “Regularly” does not mean “when we get around to it” or “when something goes wrong.” It means there is a defined interval — quarterly, monthly, whatever is proportionate to the risk — and that the testing and assessment happens on that interval. If the policy says quarterly and the last assessment was eleven months ago, the process has not met its own standard.

Third: effectiveness. Not existence. Not documentation. Effectiveness. The requirement is not to test whether a measure is in place. It is to test whether the measure works — whether it produces the effect it is designed to produce. This is the distinction that most compliance programmes miss. Having a firewall is not enough. Having a firewall and testing whether it blocks what it is supposed to block is what the article requires.

What “appropriate” actually requires

The word “appropriate” in Article 32 is doing more work than most organisations realise. Appropriateness under GDPR is a proportionality standard. A measure is appropriate if it is proportionate to the risk it addresses. But proportionality is a comparative claim. You cannot demonstrate that a measure is proportionate to a risk without measuring what the measure actually does against that risk.

If you do not measure the effect of your controls, you cannot demonstrate proportionality. If you cannot demonstrate proportionality, you cannot demonstrate that your measures are “appropriate” within the meaning of Article 32. The effectiveness testing requirement in 32(1)(d) is not a separate obligation bolted onto the article. It is the mechanism that gives the word “appropriate” its operational meaning.

An organisation that implements measures but never tests their effectiveness has no basis for claiming those measures are appropriate. It may believe they are. It may be right. But it cannot demonstrate the claim, and under Article 32, the obligation is to demonstrate, not to believe.

The enforcement record

Two enforcement decisions illustrate how regulators are reading Article 32 in practice.

The Romanian data protection authority (ANSPDCP) fined UiPath €70,000 in August 2023, citing Articles 25 and 32. The decision reasoning addressed the Article 32(1)(d) testing obligation using the statute’s own language. The regulator did not simply find that controls were inadequate. It found that the process for testing whether controls were effective was absent. The failure was not in the controls themselves. It was in the testing process — the organisational machinery that Article 32(1)(d) requires.

The UK Information Commissioner’s Office fined British Airways £20,000,000 in October 2020 for Article 32 failures affecting 429,612 customers. Among the material failures the ICO identified was the absence of penetration testing — a testing process that would have identified the vulnerabilities exploited in the breach. The ICO named the absence of a testing process as a contributing cause, not merely an aggravating factor.

Both cases show regulators reading Article 32 as requiring an active, ongoing testing obligation. Not a one-time implementation exercise that produces a static document. A live process that produces evidence over time.

What this means in practice

The practical question is straightforward. Does your organisation have a documented process for regularly checking whether its security controls work? And does that process produce output — reports, data, findings — that feeds back into decisions?

A policy that says “we test controls annually” with no evidence the test ran is weaker than an organisation operating under Article 32 can afford to be. The policy creates the obligation. The absence of evidence creates the liability. The combination is worse than having no policy at all, because the policy documents a commitment the organisation failed to honour.

What an auditor or regulator is looking for is not complex. A process exists. It runs on a defined schedule. It produces output. The output is reviewed. Decisions are made based on the findings. That loop — implement, test, find, decide, act — is what Article 32(1)(d) requires.

The obligation that was always there

“Appropriate technical and organisational measures” has always included the obligation to check whether your measures are working. Article 32(1)(d) is not new. It has been in force since May 2018. What has changed is that regulators are now reading it, citing it in enforcement decisions, and holding organisations to its standard.

The enforcement record shows the direction. The question is whether your process documentation matches the obligation — not as a future aspiration, but as a current, demonstrable fact.

For the full regulatory argument and enforcement precedents, read the white paper: Measuring Security Control Effectiveness: From Attestation to Evidence