How often does GDPR require penetration testing?

The GDPR sets no interval for penetration tests; it asks for regular testing and names no method. I run a penetration test once a year and after changes to login, roles or data exports, because the Polish authority ruled that testing only on suspicion is not regular.

What does Article 32 of the GDPR say about security testing?

Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of the measures that protect personal data. The article names no method, so recorded access tests, scans and penetration tests can all serve.

Is a vulnerability scan enough for GDPR?

No, not for an application with customer accounts: a vulnerability scan finds known flaws in versions and settings and misses a missing access check in your own code. Add access tests in CI and a scheduled penetration test.

Do I need a penetration test before launch?

Book the first penetration test before real personal data reaches the application, and run it on a copy with invented records. Invented records are not personal data, so the GDPR does not apply to them.

Does GDPR require penetration testing?

Answer

Yes in practice: the GDPR does not name penetration testing, but Article 32(1)(d) requires regular testing of security measures, so a web application that holds customer personal data needs access tests in CI and a penetration test on a fixed schedule, such as once a year, with the results written down.

Verdict on the code under testYes

Why

Blast radiussafety-or-legal
Change frequencyregularly
Detectabilitynever
Reversibilityimpossible
Test costheavy

Yes in practice: the GDPR never names penetration testing, but Article 32(1)(d) requires "a process for regularly testing, assessing and evaluating the effectiveness" of security measures. The typical case is a web application that stores customer addresses. Blast radius is safety-or-legal, because a hole exposes personal data, and Change frequency is regularly, because endpoints change monthly. Detectability is never, because a missing access check leaks records through requests that look normal, and Reversibility is impossible, because leaked records cannot be recalled. Test cost is heavy, because a penetration test books a tester for days, and rule R2 still gives Test mandatory.

When the decision changes
When	Decision	Why
A change adds an endpoint that returns customer records	Test mandatory: a CI test logs in as one customer and asserts a 404 for another customer's record	Test cost falls to moderate for one access check while Blast radius stays safety-or-legal
A public static site has no accounts, forms or cookies	Do not book a penetration test; keep the host and dependencies patched	Blast radius falls to users, Detectability to same-day and Reversibility to trivial, because a defacement is visible and a redeploy removes it
The application runs only on your laptop with invented records	Do not test for the GDPR yet; book the first penetration test before real personal data arrives	Blast radius falls to none, because no real person's data exists and only you use the build
Customer data lives only in a hosted CRM whose terms forbid testing the platform	Test it differently: sign a data processing agreement, check the vendor's ISO/IEC 27001 certificate, require multi-factor login and review who has access	Test cost rises to prohibitive, because you may not test the vendor's platform, while the risk stays high
A legacy system with customer records has no test copy, and a scan could take production down	Test it differently: cut the system off from the internet and alert on unusual record reads	Test cost rises to prohibitive, because no copy exists to test against

What breaks if you don't test

An endpoint returns a customer profile by its ID without checking the owner. The tests pass, and a script counting through the IDs downloads every customer's address. Article 33 then gives you 72 hours to notify the authority, and Article 83(4) allows fines for Article 32 failures of up to 10 million euros or 2% of worldwide annual turnover, whichever is higher.

What you lose if you over-test

A penetration test after every release spends days of tester time on a barely changed scope, and a report with no findings covers only the build the tester saw. A scanner pointed at production can fill tables with junk records.

How to test

The ICO's guide to data security notes that the law sets neither the type nor the frequency of testing, and names penetration testing as one way. My minimum set:

Access tests in CI for every endpoint that returns personal data, driven by a role matrix as in the OWASP Authorization Testing Automation Cheat Sheet.
Dependency scanning on every build.
A penetration test once a year and after changes to login, roles or data exports, on a copy with invented data, scoped with the OWASP Web Security Testing Guide.
A written record of date, scope, findings and fixes: the proof of compliance Article 5(2) asks for.

Procedure and references

When the answer changes

A contract or a standard such as PCI DSS demands a penetration test report, and that evidence comes first.
Personal data lives only in a platform you may not test.
The application holds no personal data yet.

Real incident + Code example

The fine for testing only on suspicion

In December 2019 an attacker used a broken parameter check in the Virgin Mobile Polska service that issued registration confirmations for prepaid cards, and took the names, national ID numbers and ID document numbers of 114,963 customers. That check had not been tested before release. The Polish authority, UODO, found that the last comprehensive review dated from May 2018 and that later checks ran only on suspicion or after organisational changes, which it ruled is not regular testing under Article 32(1)(d). UODO fined the company PLN 1,968,524 in 2020; after a court sent the amount back, a new fine of about PLN 1.6 million was upheld in 2023.

A CI test covers that kind of check on every change:

# tests/test_customer_access.py (pytest-django), runs in CI on every change
import pytest

@pytest.mark.django_db
def test_customer_cannot_read_another_customers_profile(client, customer_factory):
    alice = customer_factory(email="alice@example.test")
    bob = customer_factory(email="bob@example.test")

    client.force_login(alice.user)
    response = client.get(f"/api/customers/{bob.id}/")

    # 404, not 403: the response must not confirm that the record exists
    assert response.status_code == 404
    assert b"bob@example.test" not in response.content

Sources

Does SOC 2 require penetration testing?Code under test: Yes
Does HIPAA require penetration testing?Code under test: Yes
Should I anonymize data before testing?Yes
Should I test API endpoints?Yes
Should I test with production data?Test it differently

FAQ

How often does GDPR require penetration testing?: The GDPR sets no interval for penetration tests; it asks for regular testing and names no method. I run a penetration test once a year and after changes to login, roles or data exports, because the Polish authority ruled that testing only on suspicion is not regular.
What does Article 32 of the GDPR say about security testing?: Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of the measures that protect personal data. The article names no method, so recorded access tests, scans and penetration tests can all serve.
Is a vulnerability scan enough for GDPR?: No, not for an application with customer accounts: a vulnerability scan finds known flaws in versions and settings and misses a missing access check in your own code. Add access tests in CI and a scheduled penetration test.
Do I need a penetration test before launch?: Book the first penetration test before real personal data reaches the application, and run it on a copy with invented records. Invented records are not personal data, so the GDPR does not apply to them.