No. The words "penetration testing" appear nowhere in the GDPR. What Article 32(1)(d) requires is "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing." That is a process obligation, not a product one. An annual pen test can satisfy it. So can several other things, and a pen test alone sometimes does not.
This article covers what Article 32(1)(d) requires and what each of its three verbs is doing, why frequency is not specified and how to decide yours, the difference between a scan and a test when someone asks you which you did, why the market requirement is usually stricter than the legal one, and the specific failure that turns a penetration test into evidence against you.
What Article 32(1)(d) Requires
Three verbs, and they are not synonyms. You must test, assess and evaluate the effectiveness of your measures.
Testing is the activity: you probe the system and find out what happens. Assessing is the interpretation: you decide what the findings mean for the personal data you hold, which is not the same as reading a severity rating off a report. Evaluating effectiveness is the question the other two exist to answer — are the controls you put in place actually doing the job you assumed they were doing?
The subject of the sentence matters too. It is not "a process for testing your systems," it is a process for evaluating the effectiveness of your technical and organisational measures. Organisational measures are in scope. Whether your access review actually happens each quarter, whether leavers actually lose their accounts, whether your incident procedure works when someone follows it at two in the morning — these are testable, they are covered by 32(1)(d), and no penetration test will tell you about them.
And it says "a process." Not an event. A single test performed once, with no defined trigger for the next one and no route from a finding to a fix, is not a process, however good the report looks.
Nobody Specifies A Frequency, Including The Regulation
"Regularly" is the only guidance the text offers, and it is deliberate. The ICO's position on the same words is that what the tests look like, and how often you run them, will depend on your own circumstances — a regulator declining to set a number rather than a regulator being vague. The same risk-based logic that governs the whole of Article 32 governs its testing limb: appropriate to the nature, scope, context and purposes of the processing, and to the risk. It is the identical structure that makes encryption an example rather than a requirement two sub-paragraphs earlier.
That gives you two triggers rather than one. Calendar-driven testing is the obvious one, and annual is a common landing point because it aligns with audit cycles and buyer expectations rather than because a regulator picked it. Change-driven testing is the one teams forget: a new authentication flow, a migration to a new hosting provider, a significant change to how personal data moves through the system. A test performed in January says very little about the architecture you shipped in June.
If your processing is high-risk enough to require a Data Protection Impact Assessment under Article 35, the expectations rise with it. The DPIA documents the measures you rely on to bring risk down to an acceptable level, and a measure you have never tested is a measure you are asserting rather than demonstrating.
A Scan Is Not A Test, And The Difference Shows
Three things get called "testing" and they are not interchangeable.
Automated vulnerability scanning runs continuously or on a schedule, compares your stack against known issues, and produces volume. It is cheap, repeatable and genuinely useful, and for a low-risk product with a small attack surface a well-run scanning programme with tracked remediation can be a defensible answer to 32(1)(d) on its own.
Penetration testing is a human being attempting to reach something they should not, within an agreed scope and window. It finds the class of problem scanners cannot: chained logic flaws, broken authorisation between tenants, the endpoint that works exactly as designed and should not exist. For multi-tenant SaaS, tenant isolation is the finding that matters most and the one only a person will surface.
Red teaming is a goal-directed exercise against your detection and response, usually unannounced. It tests whether you would notice, which is a different question again.
The reason to be precise about which you did is that someone will eventually ask, in writing. Answering "yes, we perform penetration testing" when you run a monthly scanner is a misstatement in a contractual document, and a reviewer who asks for the report will find out. If you scan, say you scan, and say what else you do alongside it.
The Market Asks For More Than The Law Does
This is the part that reorders most teams' priorities. The GDPR asks for a process. Your customers ask for an artefact.
Enterprise buyers routinely require a penetration test report as a condition of purchase, and they are entitled to: Article 28(3)(h) gives controllers audit rights over their processors, and most DPAs turn that into a contractual right to evidence. Security frameworks push the same way — an ISO 27001 programme will drive you toward regular technical testing as part of demonstrating that Annex A controls work, and our ISO 27001 readiness guide covers what that involves. A pen test summary also sits in the standard document pack that arrives alongside a vendor security questionnaire, next to the SOC 2 report and the DPA, which is covered in what buyers request alongside a security questionnaire.
So the honest sequencing for a small SaaS is this: you will almost certainly end up commissioning a penetration test, and the reason will be a procurement team rather than a regulator. That is fine. Just do not confuse the two obligations, because they have different scopes. The buyer wants a report about your product. Article 32(1)(d) wants evidence that the measures protecting personal data — including the organisational ones no external tester will look at — are working.
What To Share, And What To Keep
An executive summary is the normal unit of disclosure, covering the date, scope, tester, severity counts and remediation status. Full reports contain reproduction steps for live weaknesses, and circulating them widens your exposure rather than narrowing it. Buyers who know the field expect the summary and do not push for more; one who insists on the full report is usually one who has not reviewed many vendors.
Common Mistakes With GDPR Security Testing
Believing an annual penetration test is the requirement. It is a common answer to the requirement, not the requirement itself. Teams that adopt it as a rule tend to test on the calendar and skip the architectural change that actually warranted a look.
Testing and not remediating. Article 32(1)(d) asks you to evaluate effectiveness. A report listing unresolved critical findings from eighteen months ago demonstrates that you tested, assessed, and then did nothing — which is worse evidence than never having tested, because it establishes that you knew.
Scoping around the risk. Excluding the authentication service, the admin panel or the tenant-isolation boundary produces a clean report about the parts nobody was worried about. Scope decisions belong in the record alongside the findings.
Calling a vulnerability scan a penetration test. It is an inaccurate statement in a document a customer relies on, and it is trivially exposed the moment someone asks who performed it and over what period.
Testing only the technology. Access reviews, offboarding, backup restoration and incident response are organisational measures inside the scope of 32(1)(d), and they are usually where the untested assumptions are.
FAQ
How often does GDPR require penetration testing?
It sets no frequency, because it does not require penetration testing. Article 32(1)(d) requires regular testing of the effectiveness of your measures, with "regular" determined by your risk. Most teams settle on annual technical testing plus a test after significant change, and document why that cadence suits their processing.
Does the test have to be performed by an external company?
Nothing in the GDPR says so. Independence strengthens the evidence and is often what buyers and certification schemes want, but an internal team with the right skills and genuine independence from the system under test can produce valid results. The constraint is usually commercial rather than legal.
Do we need a penetration test to be GDPR compliant?
No. You need a defensible process for evaluating whether your security measures work, and a record of having run it. For a small, low-risk product, continuous scanning with tracked remediation plus tested organisational controls can meet that. Whether it satisfies your customers is a separate question, and often the binding one.
Can we share the full report with a customer?
You can, but the convention is not to. An executive summary giving date, scope, tester, severity counts and remediation status is standard and widely accepted, and it is what most procurement teams mean when they ask for your penetration test.
Closing Thought
The interesting thing about Article 32(1)(d) is that it asks a question almost nobody answers: not "did you test," but "did the test tell you whether your controls work." Those come apart more often than they should. A penetration test scoped to the marketing site, or a scan whose findings nobody triages, satisfies the letter of an activity while leaving the actual question untouched — and a regulator reading your file after an incident will be looking at the gap between the two.
ComplyDog will not test your systems. What it will do is hold the evidence trail that surrounds the testing — your records of processing, your subprocessor list, DPAs and a security page buyers can read for themselves — on a portal hosted on your own domain, so the recurring "can you send us your documentation" thread becomes a link. You can try it free for 14 days, no credit card required.
