GDPR Article 32: Is Regular Security Testing Mandatory?

A testing process, yes, where appropriate to the risk. A penetration test by name, no.

Article 32(1) requires the controller and the processor to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, “including inter alia as appropriate”, among four listed measures. Point (d) reads: “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.”

Three words carry the weight. Process: an ongoing, organized activity, not a one-off test. Regularly: repeated, at an interval the Regulation does not set. As appropriate: the listed measures apply according to the risk, which is why the article opens with the state of the art, the costs of implementation, the nature, scope, context and purposes of processing, and the likelihood and severity of the risk for people's rights and freedoms.

So the honest answer has two halves. Nobody can point to a GDPR article that says “annual penetration test”. And a controller whose systems process personal data at scale, with no process that tests whether its security measures actually work, is hard pressed to show that its measures are appropriate.

• Article 32(1): appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including as appropriate (a) pseudonymisation and encryption, (b) ongoing confidentiality, integrity, availability and resilience of processing systems and services, (c) timely restoration of availability and access after an incident, and (d) the process for regular testing, assessing and evaluating quoted above.
• Article 32(2): in assessing the appropriate level of security, account shall be taken in particular of the risks of accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.
• Article 32(3): adherence to an approved code of conduct or an approved certification mechanism may be used as an element to demonstrate compliance with paragraph 1.
• Article 24(1): the controller implements appropriate measures to ensure and to be able to demonstrate compliance; those measures shall be reviewed and updated where necessary.
• Article 5(1)(f) and 5(2): personal data processed with appropriate security (integrity and confidentiality), and the controller responsible for, and able to demonstrate, compliance (accountability).
• Article 28(3)(c) and (h): the processor's contract requires it to take all measures required under Article 32, and to make available the information needed to demonstrate compliance and allow for and contribute to audits, including inspections, by the controller or an auditor it mandates.
• Article 83(4)(a): infringements of the obligations in Articles 25 to 39 can be fined up to EUR 10 000 000 or, for an undertaking, 2% of total worldwide annual turnover of the preceding financial year, whichever is higher.

Recital 83 adds that the controller or processor should evaluate the risks inherent in the processing and implement measures to mitigate them, taking into account the state of the art and the costs of implementation in relation to the risks and the nature of the personal data.

The clearest statements on testing from the European Data Protection Board are in its Guidelines 01/2021 on Examples regarding Personal Data Breach Notification (version 2.0, adopted 14 December 2021), in the measures it recommends after the case studies:

• Ransomware: the fact that an attack could take place is usually a sign of vulnerabilities in the controller's system, and the identified weaknesses and security holes are to be documented and addressed without delay. The advisable measures include vulnerability and penetration testing on a regular basis, and reviewing, testing and updating the risk analysis when assessing countermeasures.
• Data exfiltration through services exposed to the internet: periodic IT security audits, vulnerability assessments and penetration tests are also required in order to detect these kinds of vulnerabilities in advance and fix them. The list of advisable measures includes systematic IT security audits and vulnerability assessments (penetration testing).

The guidelines frame these as advisable measures, and state that the list is not exclusive or comprehensive: every processing activity is different, and the controller decides which measures fit. They still tell you what a supervisory authority is likely to regard as the state of the art when a breach exploits a known, testable weakness.

Two recent decisions by Sweden's supervisory authority, IMY, show Article 32 being applied to the quality of security measures and to the absence of processes that would have found the problem:

• Sportadmin, SEK 6 million (28 January 2026). After an attack in January 2025 that exposed data on more than 2.1 million people, mostly children and young people, IMY found an Article 32 infringement. It noted that the company had known about certain weaknesses and elevated risks for a long time and had not done enough, and that it lacked the routines required to detect deficiencies in existing security measures and had no system to detect intrusions and attempted intrusions in real time.
• Miljödata, SEK 1.8 million (22 September 2026). After an August 2025 attack that, according to the company, affected 2.2 million people, IMY found the level of technical and organisational security insufficient for the data processed. It noted that the company had not carried out sufficient checks when installing new software and had no automatic real-time monitoring of its systems, and fined it for infringing Article 32(1).

Neither decision says “penetration test”. Both describe missing processes that test and monitor whether measures work, which is the gap Article 32(1)(d) addresses. For the enforcement story, see our analysis GDPR Article 32: the fine for the security test you didn't run.

Because Article 32 is risk-based, the controller sets the method and the interval, and must be able to explain them. A defensible process usually answers five questions in writing:

1. Which processing, which systems? Start from the record of processing activities and map each high-risk processing to the systems that support it, especially those exposed to the internet and those holding special categories of data.
2. Which tests, why? Vulnerability scans for known weaknesses, penetration tests where exploitability is the question, restore tests for Article 32(1)(c), access reviews and configuration checks. The EDPB examples point to regular vulnerability and penetration testing for services exposed to the internet.
3. How often? Tie the interval to the risk and to change: on a schedule, and before new software goes into production, which is the gap IMY cited in Miljödata.
4. Who tests? The GDPR does not require an external tester. Record who ran each test, their qualifications and why they are objective about the systems in scope.
5. What happens next? Findings, remediation, re-test and accepted risks, reviewed and updated as Article 24(1) requires.

If a DPIA under Article 35 covers the processing, the testing plan belongs in the measures it describes. Processors should expect controllers to ask for the same records under Article 28(3)(h).

Written in the Regulation:

• A process for regularly testing, assessing and evaluating the effectiveness of security measures, as appropriate to the risk (Art. 32(1)(d)), for controllers and processors.
• Measures reviewed and updated where necessary, and the ability to demonstrate compliance (Arts. 24(1) and 5(2)).
• Processors' duty to take all Article 32 measures and to allow for and contribute to audits (Art. 28(3)(c) and (h)).

Risk-based, decided by the controller or processor:

• Which tests, how deep, how often, and by whom, following the state of the art, the costs, the processing and the risk to people.

Guidance, not law:

• EDPB Guidelines 01/2021: regular vulnerability and penetration testing and periodic security audits as advisable measures.

Not written anywhere:

• A mandatory penetration test, a fixed frequency, a required tester certification or a GDPR security certificate that replaces the controller's own assessment.

Zero Hunt is an autonomous AI red team for networks and infrastructure: automated penetration testing on an on-premise appliance, on private AI, with a human in the loop. It does not decide what is appropriate under Article 32, is not a supervisory authority or a certification mechanism, and does not replace your DPIA, your DPO's advice or an independent tester. GDPR is not one of the 34 frameworks the engine maps to; exported reports cite Article 32 as a regulatory cross-reference, and the same signed record documents the regular testing Article 32 asks for.

• Regular by design. Black-box and gray-box campaigns run once, daily, weekly, monthly or on a custom schedule, and before or after changes, so the interval in your testing process is the one that actually runs.
• Evidence of effectiveness, not only of existence. Each finding records whether the weakness was actually exploited, which is the difference between knowing a measure exists and knowing it works. Each fix can be re-tested with the same proof.
• Personal data stays on premises. No customer data leaves the appliance: models run on it with no external AI service, so the personal data a test touches, and the map of what is exploitable, are not sent to another processor.
• Human approval of risky steps. Five autonomy levels decide what waits for an operator, useful where testing touches production systems holding personal data. See human in the loop.
• Records that demonstrate compliance. Every attack attempt is an Ed25519-signed entry in a SHA-256 hash chain, and exported reports are ECDSA-signed, which supports the accountability of Article 5(2).

To see how this fits your Article 32 process, book a 30-minute readiness call.

• Regulation (EU) 2016/679 (GDPR), Arts. 5, 24, 28, 32 and 83 and recital 83 (EUR-Lex)
• EDPB Guidelines 01/2021 on Examples regarding Personal Data Breach Notification, version 2.0 (EDPB)
• Administrative fine against Sportadmin, 28 January 2026 (IMY)
• Sanktionsavgift mot Miljödata för bristande säkerhet, 22 September 2026 (IMY, Swedish)