GDPR requires security testing. Most organizations underdeliver.
GDPR has been enforceable since May 2018. Eight years later, the Belgian Data Protection Authority (Gegevensbeschermingsautoriteit / Autorité de protection des données) has issued fines totaling tens of millions of euros, and “insufficient technical measures” is one of the most common grounds for enforcement action.
Article 32 of the GDPR requires controllers and processors to implement “appropriate technical and organisational measures to ensure a level of security appropriate to the risk.” It then lists specific measures, including one that matters here:
“a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.”
— GDPR Article 32(1)(d)
That is a legal obligation to test your security controls. Not once. Regularly. And not just check a box: you must assess and evaluate their effectiveness.
Penetration testing is the most rigorous way to do this.
What Article 32 demands
The risk-based approach
GDPR does not prescribe specific technologies or testing methods. Instead, it requires measures “appropriate to the risk,” taking into account the state of the art, the cost of implementation, the nature and scope of processing, and the risk to individuals’ rights.
In practice, this means the testing program for an organization processing health records for millions of Belgian citizens should look substantially different from one processing newsletter subscription emails. But both need testing of some kind.
Article 32’s four categories
Article 32(1) lists four categories of measures:
(a) Pseudonymisation and encryption of personal data. A penetration test can verify that encryption is properly implemented: that data at rest is actually encrypted, that TLS configurations are sound, that key management doesn’t have obvious weaknesses.
(b) Confidentiality, integrity, availability, and resilience of processing systems. This is the broadest category. Penetration testing directly tests confidentiality (can an attacker access data they shouldn’t?) and integrity (can they modify it?). Resilience testing includes whether systems survive attack attempts without losing data.
(c) Restoring availability and access to personal data in a timely manner following an incident. Backup and recovery testing, including scenarios where an attacker has compromised backup systems.
(d) Regular testing, assessing, and evaluating the effectiveness of security measures. This is the explicit testing obligation. The word “regularly” means it is not a one-time exercise.
How penetration testing supports each obligation
Protecting personal data in transit and at rest
A web application penetration test for a Belgian e-commerce platform, healthcare portal, or government service will directly test whether personal data can be intercepted in transit (TLS configuration, certificate validation, mixed content issues), whether access controls prevent unauthorized access (IDOR vulnerabilities, broken authentication, privilege escalation), whether personal data leaks through error messages, debug endpoints, or misconfigured APIs, and whether data minimization controls are effective (are APIs returning more data than necessary?).
These are not theoretical concerns. The Belgian DPA has repeatedly cited insufficient access controls and data exposure through API vulnerabilities in enforcement decisions.
Authentication and access control
Belgian organizations processing personal data under GDPR must ensure that only authorized individuals can access that data. Penetration testing specifically probes authentication mechanisms (password policies, MFA bypass, session management), authorization controls (horizontal and vertical privilege escalation, RBAC bypass), and administrative interfaces (default credentials, exposed management panels, insecure remote access).
A common finding in Belgian environments: multilingual applications where the Dutch, French, and English versions have inconsistent access control enforcement. The same API endpoint might enforce permissions differently depending on which language the user interface is set to.
Data breach prevention
GDPR Articles 33 and 34 require notification of personal data breaches to the DPA (within 72 hours) and to affected individuals in high-risk cases. The best breach notification strategy is not having a breach.
Penetration testing identifies the attack paths that lead to data breaches before a real attacker exploits them. SQL injection vulnerabilities that allow database extraction, SSRF enabling access to internal data stores, insecure direct object references that let someone enumerate personal records, misconfigured cloud storage exposing data publicly, API vulnerabilities allowing bulk data extraction. These are common findings, and each one prevented is a breach that doesn’t happen.
Supply chain and processor security
Article 28 requires controllers to use only processors that “provide sufficient guarantees to implement appropriate technical and organisational measures.” If you are a controller engaging a SaaS provider that processes personal data on your behalf, you need assurance that their security is adequate.
Penetration testing of the integrations between your systems and your processors’ systems tests the actual security of data flows, not just the contractual guarantees in your data processing agreement.
Belgian-specific considerations
The Belgian DPA’s enforcement pattern
The Belgian Data Protection Authority has established clear enforcement patterns relevant to penetration testing.
On insufficient access controls: multiple decisions have cited organizations for failing to implement adequate access controls on systems containing personal data. In several cases, the DPA specifically noted that regular security testing would have identified the vulnerabilities before they were exploited.
On missing documentation: when investigating breaches, the DPA routinely asks for evidence of security measures, including testing records. Organizations that cannot demonstrate a structured testing program face additional scrutiny.
On proportionality: the DPA has indicated that organizations processing sensitive data (Article 9 categories, things like health, biometric, and genetic data) are held to a higher standard. For Belgian healthcare organizations, social security institutions, and any entity processing special category data, a solid penetration testing program is effectively mandatory.
Belgian eID and CSAM integration
Many Belgian organizations processing personal data integrate with the national eID infrastructure or the CSAM (Common Secure Access Management) platform for authentication. These integrations create specific attack surface: token handling and session management for eID-authenticated sessions, attribute release validation (ensuring only requested personal data attributes are received and stored), fallback authentication mechanisms that may be weaker than the eID primary flow, and integration with CSAM’s OAuth/OpenID Connect flows and proper validation of claims.
Penetration testing of these integrations requires familiarity with the Belgian identity infrastructure. A testing firm without experience in this area will miss vulnerabilities specific to these systems.
Cross-border data processing
Belgium’s position in the EU means many Belgian organizations process personal data across borders. GDPR’s one-stop-shop mechanism means the Belgian DPA may be the lead supervisory authority, or it may be cooperating with another member state’s authority.
Penetration testing for cross-border processing should cover data transfer mechanisms and their security, whether the testing scope is sufficient for all processing locations, and consistency of security controls across different national environments.
Building a GDPR-aligned testing program
Scope your personal data processing
Before defining a testing program, map where personal data lives in your systems. This is a requirement under GDPR anyway (Article 30, records of processing activities), but it also defines your testing scope. Every system that processes personal data is a potential penetration testing target.
Prioritize by volume and sensitivity of data (systems processing special category data under Article 9 get tested first), internet exposure (public-facing applications processing personal data are highest risk), recent changes (new applications, major updates, infrastructure migrations), and processor integrations (data flows to and from third parties).
Define testing frequency
“Regularly” is not a specific number, but reasonable interpretations based on DPA guidance and industry practice point to annual comprehensive penetration tests for all systems processing personal data, tests after significant changes to applications or infrastructure, quarterly automated security testing or focused tests of high-risk components, and continuous vulnerability scanning between penetration tests.
If you have experienced a breach or near miss, increase the frequency.
Document for compliance
Your penetration testing documentation should directly support GDPR accountability under Article 5(2). That means a testing policy connected to your Data Protection Impact Assessments, scope justification explaining why tested systems were prioritized, full technical reports with findings mapped to personal data risks, remediation evidence showing findings were addressed within defined timelines, management reporting showing board awareness of testing outcomes, and retest results confirming remediation was effective.
This documentation does double work: it satisfies GDPR accountability requirements and gives you evidence for the DPA if they come asking.
Integrate with your DPIA process
Article 35 requires Data Protection Impact Assessments for high-risk processing. Penetration testing should feed into DPIAs and vice versa. The DPIA identifies processing activities that present high risks to data subjects. Penetration testing validates whether the security measures identified in the DPIA are effective. Testing findings update the residual risk assessment. The cycle repeats as processing activities change.
The cost of not testing
The Belgian DPA can impose fines up to 20 million euros or 4% of global annual turnover. But fines are not the only cost.
A breach involving personal data triggers notification obligations (72 hours to the DPA, without undue delay to data subjects in high-risk cases), investigation costs (forensics, legal, regulatory response), remediation costs (fixing the vulnerability, notifying affected individuals, credit monitoring where appropriate), reputational damage (particularly painful in Belgium’s relatively small business community), and civil liability under Article 82, which gives data subjects the right to compensation.
Regular penetration testing is cheap relative to these costs.
Where this leaves Belgian organizations
GDPR Article 32(1)(d) is not ambiguous. Belgian organizations processing personal data have a legal obligation to regularly test the effectiveness of their security measures. Penetration testing is the most thorough way to meet that obligation. The Belgian DPA has consistently enforced against insufficient technical measures, and the pattern is not slowing down.
If your organization needs penetration testing that accounts for GDPR requirements and the Belgian regulatory environment, contact us.
