🛡️ Pentest from €539 · Compliance from €89. See All Services →
Optimum Web
GDPR · Article 32

Does GDPR Require Penetration Testing? What Article 32 Actually Says

Quick Answer

GDPR does not literally require "penetration testing" — those words never appear in the Regulation. Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of security measures, and the UK ICO explicitly names penetration testing and vulnerability scanning as practical ways to do that. No frequency is set in the text — it is risk-proportionate. Article 32 binds processors as well as controllers, so a SaaS company processing customer data has its own obligation, independent of its customers.

The Four Measures in Article 32(1)

Article 32(1) requires controllers and processors to implement technical and organisational measures appropriate to the risk, and lists four examples — the list is illustrative, not exhaustive (the text says "including inter alia as appropriate").

§Measure
(a)Pseudonymisation and encryption of personal data
(b)Ability to ensure ongoing confidentiality, integrity, availability and resilience of processing systems and services
(c)Ability to restore availability and access to personal data in a timely manner in the event of a physical or technical incident
(d)A process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing

Source: Regulation (EU) 2016/679, Article 32(1) — EUR-Lex · gdpr-info.eu

What Regulators Say About Testing

The UK Information Commissioner's Office (ICO), in its guidance on security, confirms that Article 32 requires a process of regularly testing the effectiveness of security measures, that the appropriate extent of testing depends on what and how the organisation processes personal data, and that this is commonly done through vulnerability scanning and penetration testing among other methods. The European Data Protection Board's (EDPB) guidance on Article 32 similarly frames testing as risk-based rather than prescribing a fixed method or schedule. Neither source sets a mandatory frequency — the obligation is to have a genuine, regularly-exercised process, sized to your actual risk.

How Often? There Is No Number in the Regulation

This is where most competing pages get it wrong, and it is worth being precise about. Article 32(1) sets a standard — measures "appropriate to the risk," taking into account "the state of the art, the costs of implementation and the nature, scope, context and purposes of processing" — not a cadence. Nowhere does the text say "annually," "every 12 months," or any other fixed interval.

In practice, what determines frequency is your own risk assessment: how sensitive the data is, how much your system changes, whether you've had an incident, and what your customers' contracts or your cyber insurance renewal specifically ask for. Annual testing is a common industry convention, not a GDPR requirement — treat it as a reasonable default, not a legal citation.

If You Are a Processor, This Is Your Obligation Too

Article 32(1) opens with "the controller and the processor shall implement..." — it names both roles explicitly. A SaaS company processing its customers' end-user data is a processor, and its Article 32(1)(d) testing obligation exists independently of whatever its own customers do on their side.

In practice, this usually surfaces first as a contractual requirement: your customer's Data Processing Agreement asks you to demonstrate that you test your own security measures, sometimes with a specific evidence format. This is the same document category covered by our vendor security questionnaire page — the questionnaire is usually where the Article 32(1)(d) obligation becomes concrete and time-bound.

Testing by a Supplier Outside the EEA

We are based in Moldova, which is not on the European Commission's list of countries with an adequacy decision. In practice this means every engagement with an EU-based client is set up through a Data Processing Agreement and Standard Contractual Clauses (SCCs) before any testing begins — not as an exception, but as our standard onboarding step for cross-border work.

For your own evidence file, this is what typically gets kept alongside the test report: the signed DPA, the executed SCCs, and confirmation of the specific data categories (if any) the testing provider could access during the engagement. If your legal or security team wants to review these before contracting, we provide them in advance of any scoping call.

What Evidence Looks Like

A written, agreed scope document defining what was tested and what was explicitly excluded
Signed Rules of Engagement authorising the test
A named, independent tester — not solely an internal team
Findings scored with CVSS v3.1 and classified by CWE
A signed Attestation Letter with testing dates, scope, and methodology reference
Evidence of retesting after remediation, where retesting was in scope

A Web App Vulnerability Assessment produces a scored report and a signed Attestation Letter in 5 business days.

Start with Vulnerability Assessment — €539

Penalties

Article 32 infringements are assessed under the lower of the two GDPR fining scales — do not confuse it with the higher scale that applies to different obligations.

ScaleApplies toMaximum fine
Article 83(4) infringementsObligations of controllers and processors, including Article 32 security measuresUp to €10,000,000 or 2% of total worldwide annual turnover of the preceding financial year, whichever is higher
Article 83(5) infringementsBasic principles of processing, data subject rights, international transfers (a different, higher scale — not the one Article 32 falls under)Up to €20,000,000 or 4% of total worldwide annual turnover of the preceding financial year, whichever is higher

This page explains our understanding of Article 32 and is not legal advice. We are a security testing provider, not a law firm — for a binding interpretation of your specific obligations, consult your Data Protection Officer or legal counsel.

Frequently Asked Questions

Does GDPR require penetration testing?+
Not literally. The Regulation never uses the words "penetration testing". 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 the processing". A penetration test is a common, practical way to document that process — but it is a means of demonstrating compliance, not a named legal obligation.
How often does GDPR require testing?+
There is no number in the text. Article 32 requires the testing process to be risk-proportionate to "the state of the art, the costs of implementation and the nature, scope, context and purposes of processing", not a fixed annual (or any other) cadence. Anyone telling you GDPR mandates yearly penetration testing is stating an industry convention as if it were the regulation itself — it isn't in Article 32.
Is a vulnerability scan enough?+
It can be part of the answer, depending on your risk profile — Article 32(1) also lists encryption, ongoing confidentiality/integrity/availability, and incident recovery as illustrative (not exhaustive) measures. For higher-risk processing, or where a customer's DPA specifically asks for independent penetration test evidence, a scan alone is unlikely to be accepted as sufficient.
We are a processor, not a controller — does this apply to us?+
Yes. Article 32 explicitly binds "the controller and the processor" — it is not a controller-only obligation. If your company processes personal data on behalf of clients (which describes most B2B SaaS), you have your own Article 32(1)(d) obligation independent of what your customer does on their side, and your customer's DPA with you will typically ask you to demonstrate it.
Our supplier is outside the EU — is that a problem?+
Not by itself. Using a supplier established outside the EEA for testing (or any other processing) is addressed through a Data Processing Agreement and, where the destination country has no European Commission adequacy decision, Standard Contractual Clauses. This is a routine contractual mechanism, not a barrier to using a non-EEA testing provider.
What documentation should we keep?+
At minimum: the signed scope document and Rules of Engagement, the test report with severity-classified findings, a signed Attestation Letter, and — where remediation was needed — evidence of retesting. This is what a customer's security team or a supervisory authority would expect to see if asked to demonstrate your Article 32(1)(d) process.
What are the fines?+
Article 32 infringements fall under the Article 83(4) scale: up to €10,000,000 or 2% of total worldwide annual turnover of the preceding financial year, whichever is higher. This is a different, lower scale than Article 83(5) (up to €20,000,000 or 4%), which covers breaches of core processing principles and data subject rights — do not confuse the two when discussing Article 32 exposure.
Does an ISO 27001 certificate cover Article 32?+
It's strong supporting evidence — Annex A.8.29 (security testing in development and acceptance) covers similar ground — but ISO 27001 certification and GDPR Article 32 compliance are legally distinct. Certification does not automatically constitute Article 32 compliance on its own.
Is a €539 vulnerability assessment enough for GDPR?+
It depends on your risk profile and what your DPA or auditor specifically asks for. A Vulnerability Assessment gives you a scored baseline and an Attestation Letter, which can support a lower-risk Article 32(1)(d) case. Where a customer or auditor specifically asks for "a penetration test", start from our Focused tier instead — a vulnerability assessment is a different, narrower deliverable and we say so plainly on its own page.

Document Your Article 32(1)(d) Process

Fixed prices, published on every tier's own page. No sales call required to see a number.

Start with Vulnerability Assessment — €539 Book a 30-min scoping call
📞Call Us💬Get Free Quote