On this page
Process EU or UK personal data? Run the free scan at scan.sumrite.com for a first look at your external exposure, then scope testing around the systems that hold personal data.
GDPR is often summarised as “GDPR requires an annual pentest”. It does not say that. It also does not leave testing optional: a company that has never tested its security cannot show it has a process for regularly testing it, and regulators read Article 32 that way after a breach.
What Article 32 says
Article 32 requires controllers and processors to implement “appropriate technical and organisational measures to ensure a level of security 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. It lists four measures “as appropriate”:
| Article 32(1) | Measure | Where testing fits |
|---|---|---|
| (a) | Pseudonymisation and encryption of personal data | Testing checks that encryption is applied where it should be, such as data in transit and backups |
| (b) | Ongoing confidentiality, integrity, availability and resilience of systems | Testing finds the access-control and injection flaws that break confidentiality and integrity |
| (c) | Ability to restore availability and access in a timely manner after an incident | Restore and incident exercises, rather than penetration testing |
| (d) | A process for regularly testing, assessing and evaluating the effectiveness of the measures | The direct basis for penetration testing and vulnerability scanning |
Two other provisions make testing hard to avoid. Article 5(2), the accountability principle, requires you to be able to demonstrate compliance, and a test report with remediation records is evidence a regulator can read. Article 35 requires a data protection impact assessment for high-risk processing, and test findings are the concrete input that turns a DPIA’s security section from assertion into evidence.
How regulators read “regularly testing”
The ICO’s guide to data security says the UK GDPR requires a process for regularly testing, assessing and evaluating your measures, lists techniques such as vulnerability scanning and penetration testing, and states that the law “does not specify the type of testing, nor how regularly you should undertake it”. Testing can be internal or external.
That flexibility cuts both ways. You choose the method and the interval, but you must be able to justify both against the risk of your processing. “We have never tested” is not a justification. “We test our customer-facing applications annually and after major releases, and scan monthly” is.
Enforcement looks at what you did before the breach
In March 2025 the ICO fined Advanced Computer Software Group £3.07 million after a ransomware attack disrupted NHS and social care services. It was the ICO’s first fine against a processor under the UK GDPR, and the security gaps it cited included incomplete multi-factor authentication, insufficient vulnerability scanning and inadequate patch management. Testing and scanning records are exactly what regulators ask for after an incident.
Controllers and processors are both on the hook
Article 32 applies directly to processors, not only to the controllers that hire them. And Article 28 requires controllers to use only processors that provide “sufficient guarantees” of appropriate security, with the processor contract requiring it to take the Article 32 measures.
For a SaaS company serving European customers, that means two pressures at once: your own Article 32 duty, and customers’ due-diligence teams asking for a recent penetration test report before they sign. A current report with a retest usually answers both.
UK GDPR and EU GDPR
The UK GDPR keeps the same Article 32 wording, so the same testing expectation applies to organisations processing UK personal data, with the ICO as regulator. Within the EU, each country’s supervisory authority enforces GDPR, and sector rules can add explicit testing duties on top: financial entities under DORA and essential and important entities under NIS2 face more specific security testing requirements than GDPR alone sets.
What the Digital Omnibus may change
The European Commission’s Digital Omnibus proposal (November 2025) would amend parts of GDPR. On 21 October 2026, the Council of the EU adopted its negotiating position, supporting a longer breach notification deadline, 96 hours instead of 72, a higher threshold for which breaches must be reported to regulators, and a single EU-level list of high-risk processing.
Three points matter for security testing:
- It is not law yet. The European Parliament has not adopted its position; its committee vote is expected in early 2027. Until a final text is adopted, the 72-hour rule in Article 33 applies.
- No change to Article 32 has been reported. The duty to regularly test, assess and evaluate your security stays as it is.
- Breach rules are where it bites. A longer notification window does not reduce the security you are expected to have before a breach happens.
What to test for GDPR
Scope follows the personal data. Typical in-scope systems:
- Customer-facing web applications, portals and sign-up flows
- Public and partner APIs that return personal data
- Mobile apps and their back-end services
- Cloud storage, databases and data warehouses holding personal data
- Identity providers, single sign-on and admin consoles
- Internet-facing infrastructure: VPNs, email and remote access
- Integrations with processors and sub-processors that receive personal data
Weight the scope toward access control. Broken access control and insecure direct object references, where one user can read another’s records, top the OWASP Top 10 as the most common serious web application risk, and they lead straight to reportable breaches. Our IDOR case study shows how one exposed customer records.
A sensible GDPR testing cadence
- Map personal data. List the systems that store, process or transmit personal data, including processors and backups. Your records of processing are the starting point.
- Rate the risk. Rank systems by the volume and sensitivity of the data and how exposed they are.
- Scan regularly. Vulnerability scanning at least quarterly, and monthly or continuously for internet-facing systems.
- Penetration test annually. Test high-risk applications, APIs and infrastructure at least once a year, and after significant change.
- Remediate and retest. Close high and critical findings, retest, and record the dates.
- Keep the evidence. Store reports, remediation records and retests with your Article 30 records and DPIAs, so you can demonstrate compliance under Article 5(2).
Our guide to how often to run a penetration test covers risk-based cadence in more detail.
How Sumrite helps
Sumrite tests the systems that process personal data: web applications, APIs, cloud environments and networks, with risk-rated findings, fixes and a retest you can file as Article 32 evidence. Reports map findings to GDPR alongside ISO 27001, SOC 2 or NIS2 where those apply. Our GDPR compliance page sets out how we run the engagement. Begin with the free check at scan.sumrite.com.
Evidence Article 32 before a regulator asks
Tell us which systems hold personal data. We will scope testing that shows a regular, risk-based testing process. Get a quote or run the free scan first.
Related reading: Which compliance frameworks require penetration testing? · NIS2 penetration testing requirements · What makes a VAPT report worth paying for
Frequently asked questions
Does GDPR require penetration testing?
Not by name. Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of your technical and organisational security measures. The UK ICO lists vulnerability scanning and penetration testing as ways to do that, and for internet-facing systems that process personal data, a penetration test is the most common way to evidence it.
How often does GDPR require security testing?
GDPR does not set an interval. The ICO says the law does not specify the type of testing or how regularly you should do it. Annual penetration testing of systems that process personal data, plus testing after significant changes, is the common baseline, adjusted to the risk of the processing.
Does GDPR apply to processors as well as controllers?
Yes. Article 32 applies to both, and Article 28 requires controllers to use only processors that give sufficient guarantees on security. In March 2025 the ICO fined a processor, Advanced Computer Software Group, £3.07 million after a ransomware attack, citing gaps in multi-factor authentication, vulnerability scanning and patch management.
What are the fines for failing Article 32?
Breaches of Article 32 fall under Article 83(4), with fines of up to €10 million or 2% of worldwide annual turnover, whichever is higher. Regulators also weigh the security measures you had in place when setting fines for other breaches.
Will the Digital Omnibus change GDPR security testing rules?
The Digital Omnibus proposal would change breach notification, including a 96-hour deadline and a higher reporting threshold in the Council's position of 21 October 2026, but no change to Article 32 has been reported. It is not yet law, and the current 72-hour rule still applies.
How do we begin?
Run Sumrite's free scan at scan.sumrite.com for a first look at your external exposure, then map the systems that process personal data and scope penetration testing around them.
