Article 32 of the UK GDPR requires appropriate technical and organisational measures, and it goes further than most people remember. It names a process for regularly testing, assessing and evaluating the effectiveness of those measures as part of what appropriate means. Testing is not an optional extra you might choose. It is written into the obligation, and the Information Commissioner’s Office reads it that way.
What appropriate actually means
The standard is risk-based rather than fixed, which frustrates people looking for a checklist and is the only workable approach across organisations of every size. What is appropriate for a two-person consultancy differs from what is appropriate for a company processing health records for thousands of people. Article 32 lists examples including pseudonymisation, encryption, resilience and the ability to restore availability after an incident. The common factor is that each is a measure you should be able to describe, justify against your risk and show working. The regulator also expects measures to reflect the state of the art, so a control that looked reasonable in 2019 may not look reasonable now.
Where testing fits into the obligation
Regular testing turns a claim into evidence. A penetration test of the systems processing personal data shows you looked for weaknesses in the way an attacker would. Vulnerability scanning shows the ongoing process rather than a single moment. Restoration testing evidences the availability limb, which is the one most organisations skip until an incident forces it. The word regularly matters: a report from three years ago describing a system rebuilt since then evidences nothing about your current measures.
“After a breach, the first thing the Information Commissioner’s Office asks about is what you had in place beforehand and how you knew it worked. A dated test report with a remediation record answers that in one document. Organisations that cannot answer it end up arguing about whether their measures were appropriate, which is a much harder conversation to have after the event.”
William Fieldhouse, Director, Aardwolf Security Ltd
Building the evidence trail
Keep the material that shows the process running, not just the conclusion. That means the scope of each assessment, the dates, the findings, who owned each fix, when it completed and how it was verified. Link that to your record of processing activities so it is clear which systems handling personal data have been assessed and which have not. Accountability under Article 5 means being able to demonstrate compliance, so a folder of reports with no remediation record does half the job.
Proportionality without complacency
Small organisations sometimes read Article 32 as a large company obligation and do nothing. That is the wrong conclusion, since the risk depends on the data rather than the headcount, and a small firm holding sensitive personal data carries a serious obligation. Start with the systems that process personal data and are reachable from the internet, then work inwards to the internal systems holding the same records. Regular vulnerability testing gives you continuous coverage at modest cost, and application penetration testing services provide the depth for the systems where a failure would affect the people whose data you hold.
Frequently asked questions about Article 32
These questions come up whenever a data protection review meets a security programme.
How often is regularly?
The law does not state a period. Annually is the common interpretation for significant systems, with additional testing after material change. Argue your interval from your risk and write the reasoning down.
Does a certificate satisfy Article 32?
Certification supports your case and does not settle it. The Information Commissioner’s Office looks at whether measures were appropriate for the specific processing, which is a question about your systems rather than about a scheme you belong to.
