GDPR penetration testing: what Article 32 asks for

GDPR does not require a penetration test by name. Article 32(1)(d) requires a process for regularly testing, assessing and evaluating how well your security measures work. For a web app or API that holds personal data, a penetration test is a practical way to run that process.

Does GDPR require penetration testing?#

No. The word "penetration" does not appear in Article 32. The article names four example measures, and testing is the fourth. A pentest is one way to meet it, and a regulator may accept other ways.

The duty falls on both roles. Article 32(1) applies to the controller and the processor. If you run a SaaS product that processes customers' personal data, you are usually a processor, and you carry this duty directly.

What is the exact wording of Article 32(1)(d)?#

Article 32(1) says controllers and processors implement "appropriate technical and organisational measures to ensure a level of security appropriate to the risk". It lists, among others, in point (d): "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing."

Three parts of that sentence matter for a pentest decision.

Article 32(1) also tells you what to weigh: the state of the art, the cost of implementation, and the nature, scope, context and purposes of the processing. It adds the likelihood and severity of risk to people. Article 32(2) names accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data as the risks to assess.

What do data protection authorities say about testing?#

The UK ICO says the law "does not specify the type of testing, nor how regularly you should undertake it". Its data security guidance names "vulnerability scanning and penetration testing" as example techniques, says testing can be internal or external, and asks organizations to document the results and act on recommendations or record a reason not to. The UK GDPR is a separate text from the EU Regulation, but it keeps the same Article 32 wording on testing.

We did not find an EU-level rule that fixes a test type or interval. If a national authority has issued guidance for your sector, read it. The EDPB and national authorities may publish more, so check current guidance for your country.

When is a pentest a sensible way to meet Article 32?#

A pentest fits when an attacker could reach personal data through an application. The test tries the access paths the way an attacker would, which a configuration review cannot do.

A vulnerability scan covers known patterns. It does not test business logic. See pentest vs security audit for how the documents differ.

What should you scope when the app holds personal data?#

Scope the places where personal data enters, moves and leaves. Write the scope down and get written authorization from the system owner before testing.

Checklist for the scope:

• Every login method and every role, including admin.
• Each API route that takes an object ID (users, documents, exports, invoices).
• Tenant boundaries, if you serve more than one customer. See multi-tenant isolation testing.
• File upload and download paths.
• Data export and deletion features.
• Third-party scripts and webhooks that receive personal data.
• Test accounts and test data. The tester should not read real users' records.

Say in the scope how the tester treats personal data found by accident: stop, record the location, and tell you through the agreed channel. A pentest that reads real personal data without a basis creates its own GDPR problem.

What evidence should you keep?#

Keep three things: the report, the fixes and the retest. Together they show a process, which is what point (d) asks for.

1. The report, with scope, date, method and findings.
2. A fix log: finding ID, owner, fix date, link to the change.
3. A retest result for each fixed finding. See after the pentest: remediation and retest.
4. Your written decision on test frequency and what triggers an extra test. See how often should you pentest.

If a customer's data processing agreement asks for pentest evidence, share a summary and a statement of fix status. The security questionnaire pentest questions guide lists what buyers ask. An attestation letter has no standard format, and acceptance varies by reader.

How do a pentest, a DPIA and an audit differ?#

They are three separate documents with three separate jobs.

A DPIA can name a pentest as a mitigation. A pentest cannot replace a DPIA. An audit reads your policies, and a pentest attacks the running system.

What should you ask a pentest provider?#

Ask these questions, and treat a promise of compliance as a warning.

• Do you test only with written authorization from the system owner?
• How do you handle personal data found during the test?
• Do you use test accounts and test-owned records for destructive proofs?
• Does every finding link to evidence, such as requests and responses?
• Will you retest fixed findings, and what does a retest cover?
• In what formats do you deliver the report?

Excession Labs is a security lab. We test only with written authorization from the system owner, and every finding in our reports carries evidence. We do not promise that a report will satisfy a regulator. If you want a small, written-scope test, see the free pentest pilot.

Need a pentest you can act on?

Tell us what you need tested and why. We reply to agree scope, and testing starts only after written authorization.

Request a testSee the sample report