SEO
GDPR Article 32: The Cybersecurity Clause Most Companies Quietly Miss
GDPR Article 32 cybersecurity obligations require every controller and processor to put technical and organizational measures in place that match the risk their processing creates for people. The article names four categories of control, expects a documented risk assessment behind your choices, and applies to processors independently, even when a data processing agreement is in place. Article 33 governs what happens after a breach. Article 32 governs what should have prevented it. Regulators cite it in fines more consistently than almost any other clause in the regulation.
Key Takeaways
Article 32 names four specific controls, and clause 32(1)(d) on regular testing is where most enforcement actions build their case.
"Appropriate" means proportional to your processing risk, benchmarked against the state of the art, not the ceiling of what is possible.
Controllers and processors carry independent Article 32 obligations, and a data processing agreement does not transfer them.
The Dutch DPA fined Transavia Airlines 400,000 EUR in 2021 after a breach exposing data of roughly 83,000 customers.
What does GDPR Article 32 actually require?
Article 32 is the security of processing clause. It obliges controllers and processors to implement technical and organizational measures appropriate to the risk their processing creates for data subjects. The law does not hand you a tool list. It sets four categories and expects you to document why the measures you picked are adequate for the risk profile you carry.
The proportionality test is explicit in the text. Regulators weigh the state of the art, the cost of implementation, the nature and scope of processing, and the likelihood and severity of risk to data subjects, as set out in the full text of Article 32 on EUR-Lex. Cost is a permitted factor. It is not a get-out clause for high-risk processing.
Two smaller points catch organizations off guard. Article 32(4) requires you to ensure that anyone acting under your authority processes personal data only on your instructions. And Article 32(2) requires you to be able to demonstrate the effectiveness of the measures you selected, not just claim you have them.
What counts as "appropriate technical measures"?
"Appropriate" is not a maximum. It is proportional. An HR SaaS handling employee scheduling carries a materially different risk profile than a fintech processing account data or a health platform storing clinical records. Supervisory authorities benchmark your controls against what comparable organizations in your sector currently deploy, not what was standard when the regulation entered application in 2018.
State of the art has a moving definition, and the European Data Protection Board publishes guidance to pin it down. The clearest published benchmark is EDPB Guidelines 01/2025 on pseudonymisation, which explains what regulators currently expect from controls that mask identifiers. The UK's ICO Guide to Data Security offers the plainest working definition of the risk-based framing.
Two consequences follow. Encryption of personal data in transit is treated as a near-default expectation, and its absence needs written justification. And "we adopted this control three years ago" is not a defence if the sector has moved on since.
Which four controls does Article 32 name?
Article 32(1) lists four specific measures: pseudonymisation and encryption of personal data; ongoing confidentiality, integrity, availability, and resilience of processing systems; the ability to restore access after an incident; and regular testing and evaluation of security controls. Most organisations can produce evidence for the first two. The fourth is where audits build cases.
In audit work with B2B SaaS teams, the same pattern keeps repeating. Encryption is switched on at rest but not enforced across all internal API endpoints. Backups exist but nobody has timed a restore. Access controls are configured but never reviewed. And "regular testing" turns out to mean one penetration test three years ago that nobody has looked at since.
Article 32 requirement | What it means | Common audit finding |
|---|---|---|
32(1)(a) Encryption and pseudonymisation | Personal data protected at rest and in transit | Storage encrypted; internal APIs still send personal data in plain text |
32(1)(b) Confidentiality, integrity, availability, resilience | Systems resist disruption; access is controlled | Broad internal access; no documented least-privilege model |
32(1)(c) Ability to restore access | A tested recovery capability exists | Backups configured but recovery time has never been measured |
32(1)(d) Regular testing and evaluation | Controls are validated on a defined cycle | No pentest, no audit log, no review schedule on file |
How do regulators enforce Article 32 in practice?
Article 32 fines are evidence-based. A breach gives the supervisory authority a concrete event, and the investigation then works backwards to ask whether the controls that should have prevented it were in place. In January 2021, the Autoriteit Persoonsgegevens fined Transavia Airlines 400,000 EUR after an attacker used weak passwords and excessive internal access rights to reach personal data of roughly 83,000 customers.
The pattern is consistent. Article 33 breach notification triggers the file. Investigators then work through Article 32 to find which measures were missing, undocumented, or untested. A confirmed breach is not required for a fine. Supervisory authority audits and complaint-driven investigations can produce them on their own, and the CMS GDPR Enforcement Tracker lists Article 32 among the most frequently cited articles across EU fines since 2018.
If you hold personal data and you cannot show the paper trail, the fact that "nothing happened yet" is not the defence people assume it is.
Why does the testing clause trip up most organisations?
Article 32(1)(d) requires you to regularly test, assess, and evaluate the effectiveness of your technical and organizational measures. This is the only place in GDPR where testing is explicitly named as an obligation. It means a penetration test or independent security assessment is not an optional line item. It is the documented proof that everything else in Article 32 works as claimed.
"Regularly" is not defined in the text. In practice, EDPB guidance and national DPAs treat annual penetration testing as a minimum for environments handling special category data or large-scale processing. What supervisory authorities look for is a paper trail: scope statement, report, remediation log, and evidence of re-testing against confirmed vulnerabilities. A single dated PDF is not enough. If you rely on subcontractors, your contract and audit-rights documentation has to cover this too.
Two Gravidy posts cover the practical side of building that evidence trail: how to survive your first pentest and the NIS2 practical compliance checklist, which shares most of its testing requirements with Article 32.
How does Article 32 map to ISO 27001, SOC 2, and NIS2?
If your organisation holds ISO 27001 certification, a large share of Article 32 is technically covered. ISO 27001:2022 Annex A 8.24 (cryptography) maps to 32(1)(a). Annex A 5.30 (ICT readiness for business continuity) maps to 32(1)(b) and (c). Annex A 8.8 (management of technical vulnerabilities) and 8.29 (security testing in development and acceptance) speak to 32(1)(d).
The gap is rarely coverage. It is documentation tied to processing activities. ISO auditors accept a control statement. GDPR supervisory authorities want a risk assessment for a specific processing operation, evidence the control is functioning for that operation, and records tied to the personal data flows in your Article 30 register. SOC 2 Type II reports satisfy Article 32 for most SaaS processing patterns, but the mapping to your records of processing has to be written down for a DPA investigator to accept it.
NIS2 Article 21 substantially restates Article 32 with tighter incident-reporting timelines on top. Treat them as one control framework, not two, and read our notes on the ISO 27001 vs SOC 2 tradeoff and DORA compliance for non-financial SaaS for the overlap.
Frequently Asked Questions
What is GDPR Article 32?
GDPR Article 32 is the regulation's security of processing clause. It requires controllers and processors to implement technical and organizational measures appropriate to the risk their processing creates. Its scope covers encryption, pseudonymisation, system resilience, and regular security testing. It applies to every organisation processing personal data of people in the EU, regardless of where the organisation itself is based.
Does GDPR require encryption?
Article 32(1)(a) lists encryption as an example of an appropriate measure, making it one of only two specific technical controls named in the regulation. It is not universally mandatory. If you store or transmit personal data unencrypted, you need a documented justification showing the risk does not warrant it. In practice, supervisory authorities treat unencrypted personal data in transit as a near-automatic Article 32 failure.
How is Article 32 enforced?
Supervisory authorities investigate Article 32 compliance after a breach notification, a data subject complaint, or a proactive audit. Investigators look for a documented risk assessment, the selected controls, and evidence those controls were tested. Fines can be issued without a confirmed breach if audits find controls are absent or untested. The Transavia case is a documented example of the pattern.
The bottom line
Article 32 gets underinvested in because it lacks the deadline urgency of Article 33 and the legal theatre of lawful-basis debates. So it sits at the bottom of the compliance backlog until a supervisory authority opens a file. The testing clause is where organisations that "have encryption and backups" find out those two controls do not add up to a defensible position on their own.
Most B2B SaaS teams we audit have three to five Article 32 gaps sitting in plain sight, usually around API encryption, restore testing, and pentest cadence. If you want a technical review that flags which fixes are draining your traffic and which are quietly building audit exposure, book a Free SEO Audit Call. Thirty minutes, specific findings, no slide decks.
