GDPR Penetration Testing Requirements: A Practical Checklist for UK Businesses

If you’ve been asked by a client, an auditor or your own board whether you meet the GDPR penetration testing requirements, here’s the honest short answer. GDPR never names penetration testing directly. But Article 32 requires you to regularly test your security measures, and the UK’s ICO treats a penetration test as the normal evidence that you do. Here’s what that means in practice, and how to check whether your current testing would hold up.

Start here: what Article 32 actually demands

Article 32 of the UK GDPR requires “appropriate technical and organisational measures” matched to the risk, cost and nature of your processing. One specific duty inside it, Article 32(1)(d), requires “a process for regularly testing, assessing and evaluating the effectiveness” of those measures. No method is named. No frequency is set. But the obligation to test, repeatedly, is written into law.

A quick self-check: do you meet the GDPR penetration testing requirements?

• Have you had a penetration test, not just an automated scan, in the last twelve months?
• Was every system that processes personal data included in scope, not just your public website?
• Did you retest after the last major change to those systems?
• Can you show, in writing, that findings were fixed and the fixes were verified?
• If you use processors or suppliers, can they show the same evidence for their own systems?

If any answer is no, you have a gap. That’s not necessarily an emergency, but it’s worth addressing before an incident or an audit forces the question.

Why the ICO treats penetration testing as the standard

The ICO’s guidance confirms organisations must have a process for regularly testing their measures, adding that the detail “will depend on your own circumstances.” Its security outcomes guidance goes further and names the accepted techniques: vulnerability scanning and penetration testing. So although the law stays technology-neutral, the regulator’s own expectation is specific.

That expectation has teeth. In October 2025 the ICO fined Capita £14 million after a breach affecting over 6.6 million people. Part of the reason: systems holding millions of records had been penetration tested only once, when first built, and never retested. The finding wasn’t that Capita skipped testing altogether. It was that testing stopped being regular.

Vulnerability scanning or penetration testing: which do you need?

Both, used for different jobs. The NCSC recommends scanning infrastructure at least monthly, since it catches missing patches and known misconfigurations quickly and cheaply. But the same NCSC guidance is clear that automated scanning “cannot compare to manual processes such as penetration testing” for breadth and depth of coverage.

Treat scanning as your monthly hygiene check and penetration testing as the periodic, deeper look that a human tester provides, chaining weaknesses together the way a real attacker would. Article 32 doesn’t reward whichever one is cheaper. It rewards whichever one actually demonstrates the effectiveness of your controls. For a fuller breakdown of what each method catches and misses, see our guide to how vulnerability scanning and adversarial testing differ.

How to set a sensible testing frequency

Neither GDPR nor the ICO sets a number, so base it on risk rather than habit. For most small and mid-sized organisations handling customer or employee data, that means:

• A full penetration test at least once a year as a baseline.
• A fresh, scoped test after any significant change: a new application, a cloud migration, a new third-party integration.
• Monthly vulnerability scanning in between, to catch anything that surfaces before the next full test.

Organisations handling higher-risk data, health records or financial details among them, should test more often than this baseline, not less. Our guide to when annual testing stops being enough covers the specific triggers to watch for. It also helps to write the trigger events down rather than relying on memory: list the systems that hold personal data, and note what kind of change to each one should prompt a retest. That turns “regular testing” from a vague intention into something you can actually point to when someone asks.

Don’t overlook systems that feel low risk simply because they’re old. Legacy platforms that still process personal data but rarely get development attention are exactly the kind of system that ends up tested once, at launch, and never again. That’s the specific failure the ICO called out in the Capita case.

What counts as compliance evidence

A report alone doesn’t satisfy a regulator. What does is a documented trail: the scope of each test, the findings, the date each finding was fixed, and confirmation that the fix was retested and worked. Capita had test reports. What it didn’t have was a mechanism to act on findings across the whole business rather than one department at a time. A known administrative access weakness went unfixed after three separate warnings.

If you’re building or reviewing that evidence trail, Aardwolf Security’s penetration testing service is scoped around exactly this kind of data-driven risk. The engagement and its reporting map to what a regulator would actually expect to see.

What a penetration test should cover for GDPR purposes

Scope it to where personal data lives: customer databases, HR and case-management systems, web applications that collect personal details, and any APIs or third-party integrations that pass that data around. Perimeter-only testing that ignores internal systems is a common gap, and it was part of what went wrong at Capita.

Internal systems deserve particular attention. Attackers who get past the perimeter, through a phishing email or a compromised account, move through internal networks next, which is exactly the path Capita’s attacker took before deploying ransomware. A test that only checks your public-facing website tells you little about what happens once someone is already inside; an internal network penetration test is what actually answers that question.

Frequently asked questions

Is a penetration test a strict legal requirement under GDPR? Not by name, but Article 32 requires regular testing of your security measures, and the ICO treats penetration testing as the practical way most organisations demonstrate that.

What happens if I only ever run automated scans? Scanning helps and should be frequent. But the NCSC itself says it doesn’t match the depth of a manual test, so scanning-only is a weak position if a regulator asks about Article 32 compliance.

Do I need to retest after every code change? Not every minor change. But any significant change to a system handling personal data, a new feature, a migration, a new integration, should trigger a fresh, scoped test rather than waiting for the next annual review.

Does this apply to small businesses too? Article 32’s duties apply regardless of size. The ICO’s own line is that testing should match your circumstances, so a smaller business with limited personal data faces a proportionately lighter, but still real, obligation.

What’s the maximum GDPR fine for a testing failure? UK GDPR sets a higher maximum of £17.5 million or 4% of global turnover, and a standard maximum of £8.7 million or 2%, whichever is greater. Testing gaps are usually cited alongside a breach rather than fined alone.

Who inside a business should own this checklist? In most small and mid-sized organisations it sits with whoever holds day-to-day responsibility for IT or information security, working with a data protection lead where one exists. What matters is that someone is named, the testing schedule is written down, and it doesn’t quietly lapse when that person moves on.