Overview
Article 32 asks for a process for regularly testing technical measures. This is that process, evidenced.
Framework reference
- Regulation
- EU GDPR and UK GDPR, Article 32, security of processing
- Direct requirement
- Art. 32(1)(d): regular testing, assessing and evaluating effectiveness
- Related
- Art. 25 data protection by design and by default; Art. 33/34 breach notification
- Processor obligations
- Art. 28, processors must provide sufficient guarantees of appropriate measures
- Regional overlap
- NIS2 and DORA import comparable testing expectations for in-scope entities
- Cadence
- Annual at minimum, plus after changes affecting processing
What the framework requires
Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of security measures. Independent testing on a defined cadence is the clearest way to show the process exists and runs.
Article 25 requires data protection by design and by default. Testing reveals where the default is not protective, API responses returning full records, exports carrying more than the interface shows, logs retaining what the privacy notice says is discarded.
Articles 33 and 34 turn on risk to data subjects. A tested understanding of what an attacker can reach makes that assessment evidential rather than speculative when a 72-hour clock is running.
What the engagement delivers
Article 32 evidence
A documented, repeatable testing process with dated results, which is what a supervisory authority or a DPIA reviewer asks for.
Data exposure mapping
What personal data is reachable, by whom, through which path, including the responses that return more than the interface displays.
Data minimisation in practice
Where APIs, exports and logs carry personal data beyond what the stated purpose requires.
Processor assurance
Evidence for the Article 28 guarantees your controllers are contractually required to obtain from you.
Breach-risk input
Findings framed in terms of risk to data subjects, which is the language notification decisions are made in.
International transfer context
Where personal data moves, including third-party services observed during testing that may not appear in the record of processing.
Questions
Does GDPR require penetration testing?
Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures. It does not name penetration testing, but it is the standard way to satisfy the requirement with evidence rather than assertion.
We are a processor, not a controller. Does this apply?
Yes. Article 28 requires processors to provide sufficient guarantees of appropriate technical measures, and controllers are obliged to verify those guarantees, which is why processors are asked for test evidence during procurement.
Does this cover NIS2 or DORA?
Both import comparable expectations for in-scope entities, and DORA adds threat-led penetration testing for significant financial entities. Where either applies, the report is mapped to the relevant obligations at scoping.
Can testing itself breach GDPR?
Testing is performed under a written agreement with defined scope and data handling. Synthetic data is preferred; where real personal data is unavoidable, access is minimised, evidence is redacted in the report, and all engagement data is destroyed on closure.
How much does GDPR-focused penetration testing cost?
Cost follows scope rather than the regulation. Article 32 framing is included in the report. A fixed quote follows a short scoping call, and scoping asks where personal data actually reaches rather than where the diagram says it does.
What does Article 32 mean by regular testing?
It requires a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures, without naming a frequency. Annually plus after significant change is the defensible reading, and what matters more is that the process is documented and its results are tracked to closure.
Can a report be used in a breach investigation?
Yes, and it is one of the first documents a supervisory authority asks for. A dated test with tracked remediation demonstrates that measures were evaluated rather than assumed. The absence of one is what turns a technical failure into a finding about your governance.
Does testing help with a DPIA?
Yes. A Data Protection Impact Assessment has to describe the measures addressing the risks it identifies, and testing is how those measures are shown to work. The report identifies what personal data is reachable, by whom and through which path, which is the section DPIAs are usually weakest on.