GDPR Article 32 and Security Testing: What You Need to Do

Most people think of GDPR as a privacy law about consent banners and data subject requests. But it also contains a security obligation that directly affects engineering teams, and it explicitly mentions testing.

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." It lists examples, including encryption and pseudonymisation, and one item that matters here:

Article 32(1)(d): a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.

So GDPR does not just require security. It requires you to test that your security works, regularly.

What counts as appropriate

GDPR is risk-based. What is appropriate depends on the nature, scope and context of processing, the risks to individuals, and the state of the art. A small newsletter tool and a platform processing health data have very different obligations. Factors that raise the bar include:

• Large volumes of personal data.
• Special category data, such as health, biometrics or political opinions.
• Data about children.
• Internet-facing systems with many users.

For most SaaS products processing customer personal data, regular application security testing is a reasonable baseline.

Why testing matters after a breach

If you suffer a personal data breach, supervisory authorities will ask what measures you had in place and whether you tested them. Several enforcement decisions have criticised organisations for failing to identify vulnerabilities that testing would have found, such as unpatched systems or injection flaws. Documented, regular testing does not prevent every breach, but it shows you took Article 32 seriously.

Processors have obligations too

If you are a B2B SaaS company, you are usually a processor for your customers. Article 28 requires your data processing agreement to commit you to Article 32 measures, and customers often ask for evidence such as penetration test summaries during procurement.

Building a GDPR-friendly testing process

1. Map where personal data lives: databases, file storage, logs, backups and third-party services.
2. Test the systems that expose it: web apps, APIs and admin interfaces, including authenticated testing.
3. Check for unintended exposure: public buckets, verbose error messages, debug endpoints and leaked keys.
4. Record findings and fixes to show the "assessing and evaluating" part.
5. Repeat on a schedule and after significant changes.

Testing without creating new risk

Testing itself should respect data protection. Use test accounts, avoid extracting real personal data beyond what is needed to prove a finding, and make sure reports do not contain unnecessary personal data.

SecurityInfinity agents verify each finding with minimal evidence and provide a fix, producing records you can use for Article 32 documentation. Start free.

Frequently asked questions

Does GDPR require penetration testing specifically?

Not by name. It requires a process for regularly testing the effectiveness of security measures, and penetration testing is one of the most common ways to meet that requirement.

How often is "regularly"?

GDPR does not define it. Annual testing plus testing after significant changes is a common baseline, with continuous testing for higher-risk systems.

Does GDPR apply to companies outside the EU?

Yes, if you offer goods or services to people in the EU or monitor their behaviour, GDPR can apply regardless of where you are based.