What Art. 32 GDPR Actually Requires
Art. 32(1) GDPR obliges controllers and processors to implement “appropriate technical and organisational measures” to ensure a “level of security appropriate to the risk”. This is deliberately open-ended: the legislator names four reference points against which the level of protection must be calibrated – 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 to the rights and freedoms of data subjects.
Points (a)–(d) of Art. 32(1) flesh this out with a non-exhaustive list: pseudonymisation and encryption (point a), the ongoing assurance of confidentiality, integrity, availability and resilience of systems (point b), the ability to restore availability and access promptly following an incident (point c), and a process for regularly testing, assessing and evaluating the effectiveness of these measures (point d). Importantly, “where appropriate” does not mean “optional at will” – it means “insofar as relevant to the specific processing”.
A Risk-Based Approach, Not a Checklist
Art. 32(2) GDPR makes clear what the risk assessment must address: destruction, loss, alteration, unauthorised disclosure of, or access to, personal data – whether accidental or unlawful. This is the benchmark against which every single measure must be assessed.
In practice, this means a firewall or an encryption solution is not an end in itself but a response to a specific, identified risk. Anyone drawing up TOMs without a prior risk analysis will struggle to justify why exactly these measures are “appropriate” – and risks doing either too little or disproportionately too much. Both are problematic under Art. 32(1), which explicitly requires a balancing exercise between effort and protection needs.
Art. 32(3) GDPR additionally allows approved codes of conduct under Art. 40 or an approved certification mechanism under Art. 42 to be used as a factor in demonstrating compliance. This does not replace an organisation’s own risk assessment, but it can ease the documentation burden.
Typical Gaps in Practice
In advisory practice, the same weaknesses recur time and again:
- No review process in place: point (d) requires a process for “regularly” testing, assessing and evaluating effectiveness. A TOM document drawn up once and never updated for years does not meet this requirement.
- No proven recovery capability: point (c) requires the ability to restore availability and access “promptly”. Without tested backup and recovery procedures, there is no evidence that this capability actually exists – a paper contingency plan is not enough.
- Encryption applied only “here and there”: point (a) lists pseudonymisation and encryption as examples, not mandatory measures for every processing operation. Organisations often apply them selectively without documenting the underlying risk assessment – making it hard to demonstrate appropriateness if challenged.
- Staff instructions not properly regulated: Art. 32(4) requires that persons with access to data only process it on the controller’s instructions. Missing confidentiality undertakings or unclear access rights are a frequent focus of supervisory authority audits.
In processing relationships in particular, it is often overlooked that Art. 32(1) directly obliges both the controller and the processor – the duty cannot simply be delegated “downstream” by contract without the controller itself assessing the appropriateness of the measures.
What This Means for Documentation
Robust evidence under Art. 32 GDPR typically consists of three elements: a documented risk analysis per processing activity, a clear mapping of specific technical and organisational measures to the identified risks, and a traceable schedule for review and updates. If any of these elements is missing, the accountability obligation under the Regulation is only partially fulfilled – regardless of how good the technical measures themselves may actually be.
If you’d like to assess where your organisation stands on Art. 32 GDPR and other obligations under the GDPR, DORA and the EU AI Act, use our free risk check at /einstufung.