5 October 2026 · 8 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
GDPR Penetration Testing: What Article 32 Requires and How to Evidence It
The GDPR does not list specific security controls. It requires you to test the ones you chose. Article 32(1)(d) is the sentence that turns penetration testing into a data-protection obligation for every controller and processor in the EU.
Does the GDPR require penetration testing?
Not by name, but by effect. Article 32 of Regulation (EU) 2016/679 requires controllers and processors to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. Paragraph 1(d) then requires a process for regularly testing, assessing and evaluating the effectiveness of those measures. A measure you have never tested is a measure whose effectiveness you cannot evidence, and that is the gap supervisory authorities and auditors probe first after a breach.
In the Netherlands the GDPR is applied through the Uitvoeringswet AVG and supervised by the Autoriteit Persoonsgegevens (AP). Fines for breaching Article 32 fall under the lower tier (up to EUR 10 million or 2 percent of global annual turnover), but the costs that follow a breach, including Article 33 notification within 72 hours and Article 34 communication to affected individuals, are usually larger than the fine.
The GDPR articles a penetration test gives evidence for
Testing supports more than Article 32. These are the provisions a well-scoped test documents.
Article 32(1)(d): regular testing of effectiveness
The direct obligation. An independent penetration test, repeated on a defined cadence and after significant change, is the clearest evidence of a process for regularly testing, assessing and evaluating security measures.
Article 32(1)(b): confidentiality, integrity, availability and resilience
A test demonstrates whether an attacker can read personal data (confidentiality), alter it (integrity) or take systems down (availability), which is exactly the property set this paragraph names.
Article 5(1)(f) and Article 25: integrity, confidentiality, and data protection by design
Application tests against OWASP categories show whether authorisation, input handling and session management protect personal data by default, which is what data protection by design requires in practice.
Article 35: data protection impact assessment
A DPIA must assess the risks to data subjects and the measures envisaged to address them. Penetration test findings feed the risk assessment with real, demonstrated weaknesses rather than assumptions.
Articles 28 and 32 for processors
Processors must offer sufficient guarantees of appropriate measures. Controllers increasingly write annual penetration testing into data processing agreements. A current report answers the due-diligence question in one attachment.
Scoping a GDPR penetration test
Scope follows personal data. Start from your record of processing activities (Article 30) and test the systems that hold the highest-risk categories first.
- Customer-facing applications and portals where data subjects log in, tested for broken access control between accounts, the most common cause of reportable breaches
- APIs and integrations that move personal data between systems and to processors
- Identity and access: single sign-on, MFA enforcement, privileged access to databases and backups holding personal data
- External perimeter and remote access, where most ransomware incidents that lead to Article 33 notifications begin
- Internal network segmentation between systems holding special-category data (Article 9) and the rest of the estate
- Backup and export paths: whether personal data can be extracted in bulk by an attacker with ordinary user access
- Retest after remediation, so the file shows measures were made effective, not just identified as weak
What "regular" means in practice
The GDPR does not set a frequency. These are the cadences supervisory authorities and auditors accept as reasonable, scaled to risk.
| Processing risk | Example | Accepted cadence |
|---|---|---|
| High (Article 9 special categories, large scale, profiling) | Health platforms, HR and payroll providers, fintech, large e-commerce | Annual full test plus application tests at each major release |
| Medium | B2B SaaS with customer personal data, membership organisations | Annual full test, retest after remediation |
| Lower | Small-scale processing, limited categories | Test at launch and after significant change; at least every 24 months |
| Any, after a breach | Any organisation that has filed an Article 33 notification | Test the affected systems before closing the incident |
GDPR testing alongside NIS2, ISO 27001 and DORA
Most organisations do not need a separate GDPR penetration test. They need one testing programme whose scope statement names the personal-data systems explicitly, so the same report serves Article 32, the ISO 27001 controls on vulnerability management and security testing, the NIS2 requirement to assess the effectiveness of measures, and for financial entities the DORA testing programme. The mapping is in the scope and the report, not in running four tests.
What changes under the GDPR is the breach-readiness angle. A test that shows how an attacker reaches personal data also shows what you would have to notify, to whom, and how fast. Running that scenario before an incident costs far less than discovering it during the 72-hour window.
How we run GDPR-scoped tests
We scope from your Article 30 record, test the systems holding the highest-risk categories from the outside and from an authenticated user position, and report every finding with the personal-data impact stated in plain terms: which data, how many records, which article. The report includes a one-page summary written for your data protection officer and a retest appendix for the file.
Our testers are OSCP-certified and named in the report, and all engagement data is handled under a signed agreement that itself complies with Article 28.
Frequently asked questions
Processing personal data at scale?
We test the systems that hold it, report the data-protection impact of every finding, and give your DPO the evidence Article 32 asks for. Talk to an expert.