Resource · GDPR Compliance

GDPR Article 32 — What Security Testing Evidence Actually Satisfies

Reviewed: 2 August 2026 — reviewed quarterly · This is general information, not legal advice

Quick Answer

GDPR Article 32(1)(d) requires a process for regularly testing and evaluating the effectiveness of security measures, without naming a specific method. In practice, a documented, recurring Vulnerability Assessment or penetration test programme is a common and defensible way to demonstrate this — supervisory authorities generally favour organisations with a repeated cadence and a dated paper trail over a single historic test.

What Article 32(1)(d) actually says

Article 32(1)(d) requires controllers and processors to have "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of processing." It doesn't name a specific method — no mention of penetration testing, vulnerability scanning, or a required frequency. It's a process obligation: you need a recurring testing practice, and you need to be able to show it exists.

How security testing is typically used to satisfy it

In practice, a documented, recurring Vulnerability Assessment or penetration test programme is one of the most direct ways to demonstrate this obligation — it's a testing process, it evaluates the effectiveness of technical controls, and it produces a dated record. Supervisory authorities and DPOs generally look favourably on organisations that can point to a defined cadence and a paper trail, rather than a single test run once, years ago.

What a supervisory authority typically wants to see after an incident

Following a personal-data breach, a supervisory authority commonly asks what technical and organisational measures were in place, and whether they were being tested. As a rule, being able to produce dated test reports, a findings register showing remediation, and evidence of a repeated cadence is viewed more favourably than having no testing history — though the specific weight given to this varies by case and jurisdiction, and this is not a guarantee of a particular regulatory outcome.

What testing alone doesn't cover

Article 32 as a whole is broader than technical testing — it also covers pseudonymisation and encryption, ongoing confidentiality/integrity/availability/resilience of processing systems, and the ability to restore availability after an incident. Security testing evidence supports the testing-and-evaluation limb of the article specifically; it isn't a substitute for the organisation's wider technical and organisational measures.

Evidence Checklist for Article 32(1)(d)

A documented, recurring security testing process — not a single one-off test

Dated reports showing what was tested and when, for at least the current audit/review period

A findings register showing issues were triaged and remediated, not just identified

A stated testing cadence you can justify against your own risk assessment

Evidence tied to the specific systems that process personal data, not just the network generally

Our Vulnerability Assessment produces a dated report and findings register — see the attestation letter format DPOs and auditors typically accept. Terminology reference: our security testing glossary.

Start with Vulnerability Assessment

Frequently Asked Questions

Does GDPR require penetration testing specifically?+

No — GDPR Article 32 does not name penetration testing, vulnerability scanning, or any specific method. It requires a process for regularly testing, assessing and evaluating the effectiveness of security measures, leaving the method up to the organisation based on its own risk assessment. Security testing is a common and defensible way to satisfy this, but it's not the only conceivable one.

How often does testing need to happen to satisfy Article 32?+

The regulation doesn't set a fixed interval — it says "regularly," without defining what that means numerically. In practice, organisations generally align testing frequency with their own risk assessment and with expectations from other frameworks they follow (e.g. annual testing is a common baseline), and should be able to explain why the chosen frequency fits their risk profile if asked.

Can a vulnerability scan alone satisfy Article 32(1)(d)?+

An automated scan on its own is a weaker form of evidence than a Vulnerability Assessment or penetration test, because it typically lacks the manual review step that confirms findings are genuine rather than noise. A documented process combining regular scanning with periodic, more thorough assessment is generally viewed as stronger evidence of an effective testing programme.

Does a small business need to do this too, or only large enterprises?+

Article 32 applies based on the risk of the processing activities, not the size of the organisation — a small business processing sensitive personal data at scale can have a higher obligation than a larger one processing low-risk data. Proportionality is part of the article's own wording ("taking into account the state of the art, the costs of implementation... as well as the risk"), so the appropriate level of testing should be assessed against your actual data-processing risk, not a headcount threshold.

What happens if a breach occurs and no testing evidence exists?+

It's generally viewed unfavourably by supervisory authorities as a sign the required ongoing evaluation process wasn't in place, and this is a commonly cited factor in enforcement discussions — though outcomes depend heavily on the specific facts, the nature of the breach, and the jurisdiction, and this is not a substitute for legal advice on a specific situation.

Is a signed attestation letter useful evidence for Article 32?+

Yes — a signed attestation letter confirming that testing was performed, by whom, and covering what scope and date range, is a compact way to demonstrate the process obligation when a full technical report isn't the right document to share (for example, with a DPO or during a compliance review rather than a technical audit).