Of all the compliance requirements that touch on security testing, Article 32 of the UK GDPR is probably the vaguest. It requires organisations to have “a process for regularly testing, assessing and evaluating” their security measures, but says nothing about what that testing should involve, how often “regularly” is, or who should carry it out.
That vagueness leaves a lot of businesses unsure where they stand when it comes to GDPR penetration testing.
Some assume that, because the law doesn’t mention penetration testing, they don’t need one. Others assume that any kind of scan or audit will do. This guide looks at what Article 32 actually says, how the ICO has treated organisations that couldn’t show they were testing, and what a defensible approach looks like when the law won’t spell it out.
Summary
The UK GDPR doesn’t explicitly require a penetration test, but it does require a regular, documented process to test that your security measures work, and that process must be proportionate to the risk to the personal data you hold.
In practice, the ICO’s own guidance lists vulnerability scanning and penetration testing as part of that process “as appropriate”, and its enforcement action shows a clear pattern.
Organisations that couldn’t evidence regular testing, tested too rarely, or ignored what their tests found have all been criticised after a breach. For most organisations with internet-facing systems or sensitive data, a penetration test is the most defensible way to show that Article 32 is being taken seriously.
What Article 32 Actually Says
Article 32 of the UK GDPR requires controllers and processors to implement “appropriate technical and organisational measures to ensure a level of security appropriate to the risk”. When deciding what’s appropriate, organisations are expected to consider the state of the art, the costs of implementation, the nature and purpose of the processing, and the likelihood and severity of the risks to individuals.
It then lists measures that may be appropriate, including pseudonymisation and encryption, the ability to keep systems confidential, available and resilient, and the ability to restore access to data after an incident. The fourth item, Article 32(1)(d), is the one this guide is about:
“a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.”
The wording asks for a process, meaning a planned, repeatable approach instead of a one-off check, and it asks you to test effectiveness, which is a higher bar than simply confirming that a control exists.
It’s also easy to overlook that Article 32 applies to processors as well as controllers, which, as we’ll see shortly, has become very relevant in recent enforcement.
So What Does “Regularly” Mean?
The law doesn’t say, and that’s deliberate. Article 32 is risk-based, meaning the right level of testing for a small business with a mailing list differs greatly from that of a company processing health records for millions of people.
The ICO’s guidance does fill in some of the detail, though. Its security outcomes guidance, which was developed with the NCSC, says organisations should “undertake regular testing to evaluate the effectiveness of your security measures”, and that this testing should include virus and malware scanning, “vulnerability scanning and penetration testing as appropriate”.
It also says you should record the results of that testing and any remediation plans. The NCSC publishes the same framework as its GDPR security outcomes.
Notably, the ICO has also pointed to NCSC advice that vulnerability scans of infrastructure should be carried out regularly, at least once a month, when assessing organisations after a breach. That gives a useful benchmark for scanning, even though the law itself doesn’t set one.
How the ICO Has Treated a Lack of Testing
The clearest picture of what “regularly testing” means in practice comes from the ICO’s enforcement action. Looking across recent reprimands and fines, four different failures come up again and again.
No testing at all: the Chartered Institute for Securities & Investment
In a reprimand letter dated the 21st of February, 2023, the ICO looked at a 2020 attack on the Chartered Institute for Securities & Investment (CISI). An attacker exploited a known vulnerability in unsupported website software, for which a patch had been available since 2017, and captured the payment details of an estimated 3,883 people.
The ICO noted that “no penetration testing or web application scanning had been conducted” and that CISI “were not conducting regular security testing prior to the incident”. Its recommendations included implementing “a testing procedure which sets out the timings and nature of testing to be conducted”, which is a useful summary of what Article 32(1)(d) expects.
Testing that couldn’t be evidenced: Brand New Tube
In a reprimand following a 2022 breach at My Media World Ltd, which trades as Brand New Tube, the personal data of around 345,000 UK users was taken, including names, email addresses and passwords. The company said a third party handled its testing, but it couldn’t confirm when scans had last been carried out or what methodology had been used.
Interestingly, this case shows that outsourcing your testing doesn’t outsource the obligation. The ICO found that the company couldn’t show it was conducting “regular penetration testing or vulnerability scanning on their systems”, and recommended that it carry out regular scans and testing, record the outcomes and address issues promptly.
Testing that was too infrequent: Advanced Computer Software Group
In a penalty notice dated the 26th of March, 2025, the ICO fined Advanced Computer Software Group’s health and care subsidiary £3,076,320 after a 2022 ransomware attack.
The attacker most likely used the Zerologon vulnerability to gain domain administrator rights, and the data of around 79,000 people was taken, including information about how to gain entry to the homes of 890 people receiving care at home. The incident also disrupted NHS services.
Crucially, Advanced had carried out penetration tests, but the ICO found they “were infrequent for each product” and “could not be relied upon to serve the same purpose as a regular ongoing vulnerability scanning programme”.
Some of those tests had even identified vulnerabilities that were later exploited. The ICO concluded that the lack of comprehensive vulnerability scanning breached Article 32(1)(d) because the company lacked a process for regularly testing and evaluating its security measures. This was also the ICO’s first fine against a data processor, rather than a controller.
Findings that weren’t acted on: Capita
On the 15th of October, 2025, the ICO announced a £14 million fine against Capita plc and Capita Pension Solutions Limited, which was reduced from a provisional £45 million, after a 2023 cyber attack affected 6.6 million people.
According to the ICO’s penalty notice, systems processing millions of records “were only subject to a penetration test upon being commissioned and were not subject to any subsequent penetration test”.
Perhaps most importantly, the ICO found that a weakness in how Capita separated its administrator accounts had been flagged as a vulnerability on at least three separate occasions without being fixed, and that penetration test findings were kept within individual business units instead of being addressed across the wider network.
In other words, Capita did test, but it didn’t test regularly enough, and it didn’t act on what its tests told it.
What these cases have in common
Taken together, these cases show that the ICO judges Article 32(1)(d) on four questions:
- Did you test at all?
- Can you prove when, how and by whom the testing was done?
- Was the testing frequent enough for the risk?
- Did you fix what the testing found?
An organisation that can answer yes to all four is in a far stronger position than one that commissioned a single test years ago and filed the report away.
GDPR Penetration Testing: Do You Actually Need One?
Strictly speaking, no. Article 32 doesn’t name penetration testing, and the ICO’s guidance describes it as something to use “as appropriate”. A very small organisation with minimal personal data and no internet-facing systems could reasonably argue that a lighter approach is proportionate.
For most organisations, though, a penetration test is the most practical way to meet the standard.
Vulnerability scanning is valuable and, as the Advanced case shows, the ICO expects it to happen regularly, but a scanner only checks your systems against a list of known weaknesses.
A penetration test shows how those weaknesses could actually be exploited and chained together, and it covers areas that scanners tend to miss, such as access controls and business logic. We explain the difference in more detail in our guides to vulnerability assessments and automated vs manual penetration testing.
The more sensitive your data and the larger your attack surface, the harder it is to argue you tested “appropriately” without one. That applies particularly to organisations handling special category data, financial information or confidential client material, such as healthcare providers and law firms.
What a Defensible Testing Approach Looks Like
Because the law won’t define “regularly testing” for you, the goal is to build an approach you could comfortably explain to the ICO after an incident. Based on the guidance and the cases above, that usually means the following.
- Start with your risks.
A cyber security risk assessment helps you identify which systems hold the most sensitive personal data and which are most exposed, so your testing effort goes where it matters most.
- Layer your testing.
Regular vulnerability scanning, at least monthly in line with NCSC advice, catches known weaknesses between tests. Annual penetration testing of your key systems, plus a test after any significant change, shows how those weaknesses could be exploited. Neither replaces the other, which is exactly the point the ICO made in the Advanced case.
- Write it down.
Document your testing procedure, including what gets tested, how often, by whom and using which methodology. This is almost word for word what the ICO recommended to CISI, and it’s precisely what Brand New Tube couldn’t produce.
- Act on the findings.
Track every finding through to remediation and confirm the fixes with retesting after fixing vulnerabilities. Where something can’t be fixed straight away, record the reason and the mitigation, as we explain in our guide on what to do if you can’t fix everything. Capita’s fine shows what happens when the same issue is flagged three times and nothing changes.
- Share results across the organisation.
Make sure findings reach the people responsible for the wider network, not just the team that commissioned the test.
- Check your suppliers.
Both Advanced and Capita were processing data on behalf of other organisations. If a supplier processes personal data for you, ask how they test their own security, because you can’t outsource responsibility for what happens to it.
Finally, make sure your scope keeps up with your environment. Repeating the same test every year can leave new systems untested while producing a reassuringly familiar report, which is what we call the Pentest Trap.
Building a Testing Process You Can Defend with Fortifi
Fortifi is a CREST-accredited penetration testing company, and our UK penetration testing services help organisations build the kind of regular, documented testing process that Article 32 expects. Every engagement includes a clear report, practical remediation guidance and retesting, so you have the evidence ready if you ever need it.
Because we don’t do sales calls, you’ll speak directly to a cybersecurity expert who can help you work out what proportionate testing looks like for your data and your risks. Book a call with our team today.
GDPR Article 32 FAQs
Does GDPR require a penetration test?
Not explicitly. Article 32(1)(d) requires a process for regularly testing, assessing and evaluating your security measures, and the ICO’s guidance lists penetration testing as part of that process “as appropriate”. For most organisations with internet-facing systems or sensitive data, a penetration test is the most defensible way to meet the requirement.
How often should we test to comply with Article 32?
The law doesn’t set a frequency. A common, defensible baseline is vulnerability scanning at least monthly, reflecting NCSC advice the ICO has cited in its enforcement, plus penetration testing at least annually and after significant changes. Higher-risk processing may justify more frequent testing.
Does Article 32 apply to data processors?
Yes. Article 32 applies to both controllers and processors, and the ICO’s 2025 fine against Advanced Computer Software Group was its first against a processor. If you process personal data on behalf of clients, you’re directly responsible for testing your own security measures.
Is a vulnerability scan enough on its own?
Usually not. The ICO expects regular scanning, but scans only identify known weaknesses. A penetration test shows how those weaknesses could be exploited, giving you stronger evidence that your measures are effective.
What evidence should we keep?
Keep a written testing procedure, the reports from each scan and penetration test, a record of how each finding was fixed or why it wasn’t, and the results of any retesting. If you ever have to respond to a data breach, these are the documents the ICO is likely to ask for.
Has the Data (Use and Access) Act changed Article 32?
Not in any way that affects testing. The Data (Use and Access) Act 2025 made a small change to Article 32(3), which covers using approved codes of conduct and certification to demonstrate compliance, and that change took effect on 20 August 2025. The requirement in Article 32(1)(d) for a process of regular testing is unchanged.