Does GDPR Require Penetration Testing? Article 32 Explained

No. Article 32 of GDPR never names penetration testing, a test method or a fixed interval. Article 32(1)(d) of Regulation (EU) 2016/679 lists, as appropriate, “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.” GDPR penetration testing is one practical way to check that those measures work.

For systems that hold personal data, a pentest gives you evidence for your own risk assessment or an auditor’s review. We don’t certify compliance. For other frameworks, see penetration testing requirements under PCI DSS, DORA and NIS2.

What does GDPR Article 32 say about testing?

Article 32 asks for security appropriate to the risk, and regular testing is one item on its list.

• Article 32(1) measures: Appropriate technical and organizational measures, including, as appropriate, pseudonymization and encryption, ongoing confidentiality, integrity, availability and resilience, timely restoration after an incident, and regular testing of those measures.
• Article 32(1) factors: The state of the art, implementation costs, the nature, scope, context and purposes of processing, and the risk to people’s rights and freedoms.
• Article 32(2) risks: Risks such as accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data.
• What it doesn’t say: Which test to run or how often. Your risk assessment decides those.

Is a vulnerability scan enough for GDPR security testing?

It depends on the risk. Article 32 doesn’t choose between a scan and a pentest, so for GDPR security testing, pick the test that shows whether a measure works against that risk.

A scan checks your systems against known patterns. A pentest goes further: a tester tries to exploit weaknesses. Take an API where changing an ID in a request returns another customer’s record. A scan can miss this, because the response looks normal. A tester checks whose record came back, and that’s the unauthorized access to personal data Article 32(2) asks you to weigh. Our guide to penetration testing vs vulnerability scanning covers the difference in more detail.

How often should you run a GDPR pentest?

Article 32 sets no testing interval. It says “regularly” and leaves the frequency to your risk assessment (see how often to run a pentest). Consider these triggers:

• After a significant change: A new application, API or move to AWS or Azure changes how personal data is processed.
• On a schedule you already follow: If PCI DSS also applies, PCI SSC guidance says penetration testing must be performed “at least annually and after any significant change.” That rule is PCI’s, not GDPR’s.
• More often for higher-risk data: Health or financial records raise the stakes, so consider testing those systems more often.

What should GDPR pen testing evidence show?

It should show what was tested, what was found and whether it was fixed. Article 32 sets no report format, so treat this as advice:

• Scope tied to personal data: Name the systems that process personal data (web application testing or API testing) and agree the scope in writing first.
• Findings with proof: An Executive Summary for management and a Technical Report for IT with vulnerabilities, exploitation evidence and step-by-step remediation. See a sample pentest report or a GDPR and HIPAA test of a medical SaaS platform. If you also handle US patient data, see HIPAA penetration testing requirements.
• Critical issues during the test: We report critical vulnerabilities while testing is still running.
• Fixes confirmed: A retest is available after fixes.

Our standard web application or API test costs $2,500–$5,500, quoted in tester-days (see penetration testing pricing).

Sources: Regulation (EU) 2016/679 (GDPR), Article 32; PCI SSC Penetration Testing Guidance v1.1 (September 2017), §2.6.