Does UK GDPR Require Penetration Testing? Article 32 Explained

The detail is where teams get caught out. Because the Regulation sets an outcome rather than a fixed rule, there is no “test every 12 months” line to tick off, and it becomes easy to assume the duty is softer than it is. It is not. If you process personal data and you cannot show that you regularly test whether your defences work, you have a gap in your Article 32 compliance. This guide breaks down exactly what the clause requires, how the ICO and NCSC translate it into penetration testing, and how to scope a test that stands up as evidence.

Where the testing duty sits in UK GDPR

UK GDPR is built on a set of data protection principles, and one of them, in Article 5(1)(f), is “integrity and confidentiality”, the security principle. Article 32, headed “Security of processing”, is where that principle turns into a concrete obligation. It applies to both controllers and processors, so if you handle personal data on behalf of someone else, this duty is yours too.

Two adjacent pieces of law sit alongside it. The Data Protection Act 2018, at section 66, imposes an equivalent security-of-processing duty for law enforcement processing by competent authorities. And the Data (Use and Access) Act 2025 reforms parts of the wider regime, but it leaves the core expectation intact: you must secure personal data and be able to demonstrate that your security measures are effective. Enforcement of Article 32 sits with the ICO.

What Article 32 actually requires

Article 32(1) is risk-based. It asks you to put in place “appropriate technical and organisational measures”, taking into account the state of the art, the cost of implementation, and the nature and risk of your processing. It then sets out what those measures should achieve. In plain English:

• Encryption and pseudonymisation. Where appropriate, personal data should be encrypted or pseudonymised so a breach does not automatically expose it.
• Confidentiality, integrity, availability and resilience. Your systems and services that process personal data must stay secure, accurate and available.
• Restore availability after an incident. You need the ability to restore access to personal data promptly after a physical or technical failure.
• A process for regularly testing effectiveness. 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”.

That last limb is the one that drives penetration testing. It is not enough to have controls in place; you have to check, on an ongoing basis, that they actually work. A firewall you never test, a web application you assume is hardened, an access control you have not challenged, none of these are evidence of effectiveness. Testing is.

How the ICO and NCSC turn this into penetration testing

The ICO and NCSC translate GDPR’s security duty into penetration testing through their jointly published “GDPR security outcomes”, which map the Regulation onto plain, testable outcomes. Outcome B.4, “System Security”, explicitly names penetration testing as a means of gaining assurance that your security measures are effective.

This guidance fills a deliberate gap. Article 32 avoids naming any specific technique, so the practical detail comes from the regulator and the national technical authority rather than from the text of the Regulation itself.

This is the important distinction to get right. UK GDPR does not mandate a penetration test by name. What it mandates is regular testing of the effectiveness of your security. Penetration testing is the standard, ICO and NCSC-recognised way to satisfy that requirement. So if an assessor, an auditor, or the ICO after an incident asks how you evaluate the effectiveness of your controls, “we commission regular penetration testing” is the answer the guidance expects.

How often do you need to test?

Here is where UK GDPR differs from prescriptive standards. Where PCI DSS fixes a 12-month cycle, Article 32 says only “regularly” and leaves the frequency to be driven by your risk. That flexibility is not a licence to test rarely; it is an obligation to test as often as your processing warrants.

In practice, the common industry approach is to test at least once a year, and again whenever something significant changes. The ICO does not set a fixed interval of its own, and its guidance is explicit that how regularly you test depends on your organisation and the personal data you process. Triggers that should prompt a test include:

• new systems, applications or infrastructure that touch personal data;
• major changes to network architecture, cloud configuration or access controls;
• a significant change to how or where personal data is processed;
• after a security incident, to confirm the weakness is closed.

Organisations carrying out large-scale or high-risk processing should expect the “regularly” bar to sit higher for them than for a low-risk operation. The point of the risk-based wording is that you justify your cadence against your exposure, and document that reasoning.

Who is allowed to perform the test?

UK GDPR names no scheme, no certification and no accreditation for testers. There is no CREST or CHECK requirement written into the Regulation, because the Regulation does not name techniques at all. What it does require is that your testing process is genuinely effective, which in turn means it has to be credible.

Credibility rests on two things: competence and independence. A test run by suitably skilled testers, independent of the team that built and runs the systems, carries far more weight as evidence than an internal spot-check. If the ICO ever examines your Article 32 posture after a breach, the standing of your testing matters. This is why organisations lean on recognised accreditation. A CREST-accredited penetration testing provider gives you ready-made evidence that the competence and independence bar is met, without you having to argue the point. EJN Labs is CREST-accredited and organisationally independent of your operations, using UK-based testers, so our reports stand up cleanly as assurance evidence.

What the test has to cover

Scope follows your data. Because Article 32 is about the security of processing, a test that supports GDPR compliance should reach the systems whose compromise would put personal data at risk. In practice that means:

• internet-facing services and web applications that collect or expose personal data;
• the internal networks, servers and databases where personal data is stored and processed;
• authentication, access control and segmentation that protect that data;
• cloud environments and any third-party integrations in the processing chain.

A test that looks only at the public website, and skips the internal database holding customer records, leaves the exact surface a regulator would ask about untested. If you are also pursuing certification, the same engagement can double as ISO 27001 penetration testing, since ISO 27001 control A.8.29 asks for the same evidence of tested, effective controls.

What happens when the test finds something

Act on the findings and confirm the fix held, that is what matters when a test finds something. Finding weaknesses is the point of testing. Article 32(1)(d) describes a continuous process, not a one-off certificate, so a test that surfaces issues has done exactly its job.

Remediation carries real weight. After a personal data breach, the ICO looks closely at whether you knew about a weakness and whether you addressed it. An identified vulnerability left unremediated turns from a routine finding into evidence that your measures were not appropriate.

So remediation and retesting are part of compliance, not an optional extra. At EJN Labs, retests of the issues we identify are included, so verifying that a fix has closed the gap does not become a second invoice, and your evidence trail shows the loop was completed.

How EJN Labs delivers GDPR penetration testing

We scope the engagement around your personal data processing, so the test targets the systems Article 32 cares about. You get a fixed price, a realistic timeline, CREST-accredited UK-based testers, and a report structured to serve as Article 32 assurance evidence and to map against the ICO and NCSC security outcomes. Findings are triaged by real-world exploitability, remediation guidance is practical rather than generic, and retesting to confirm your fixes is included.

If you want to see the format before you commit, request a sample report, or get a fixed-price quote in 24 hours for your GDPR scope.

Frequently asked questions

Does UK GDPR require a penetration test?

No, not by name, UK GDPR never uses the words “penetration testing”. Article 32(1)(d) instead requires a process for regularly testing and evaluating the effectiveness of your security measures, and in practice a penetration test is how most organisations meet that duty.

Penetration testing earns that role because it is the standard, ICO and NCSC-recognised way to satisfy the requirement, through security outcome B.4.

Which part of GDPR covers penetration testing?

Article 32, “Security of processing”, covers penetration testing. Specifically, Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of your technical and organisational security measures, which is the duty a penetration test is used to evidence.

The ICO and NCSC map this to their GDPR security outcomes, where outcome B.4 explicitly names penetration testing.

How often do you need a penetration test for GDPR?

Test at least once a year, again after any significant change to your systems or processing, and after a security incident. That is common practice rather than a legal timetable, because UK GDPR sets no fixed interval, it simply says “regularly” and leaves the frequency to your risk.

The ICO likewise does not specify how often to test, stating that it depends on your organisation and the personal data you process. Higher-risk or large-scale processing warrants more frequent testing.

Does a GDPR penetration test need to be CREST-accredited?

No, a GDPR penetration test does not legally need to be CREST-accredited, because UK GDPR names no scheme or accreditation. Your testing does, however, have to be credible, which means competent and independent, and a CREST-accredited provider is widely accepted as strong evidence that this bar is met.

EJN Labs is CREST-accredited and independent, using UK-based testers.

What happens if the ICO investigates and we never tested?

Never testing is itself a shortfall against Article 32, because the Article requires a process for regularly testing the effectiveness of your security measures. If the ICO investigates after a personal data breach, it examines whether you had such a process and whether you acted on what it found.

An untested or unremediated weakness can weigh against you in enforcement, including monetary penalties.

Is penetration testing enough on its own to comply with Article 32?

No, penetration testing alone is not enough to comply with Article 32. Testing evidences the “regularly testing effectiveness” limb, but the Article also expects appropriate measures such as encryption where suitable, confidentiality and integrity, resilience, and the ability to restore data after an incident.

A test proves those controls work. It does not replace having them in place.