Years Later, Article 32 Still Isn’t Optional: What “Technical Measures” Actually Means in Practice

Introduction

GDPR has been enforceable for years, and Article 32 remains the single most commonly cited provision in major fines. Not consent banners, not international transfer mechanisms. Security. Organisations that have had nearly a decade to implement “appropriate technical and organisational measures” are still getting this wrong often enough that regulators treat inadequate security as the default explanation whenever a breach happens.

Part of the reason is that Article 32 does not read like a checklist. It names four categories of measure in illustrative terms and leaves “appropriate” to be judged against risk, rather than specifying a fixed technical standard organisations can simply implement once and file away. This article walks through what those four categories actually require in practice, and why treating Article 32 as settled from years ago is exactly the assumption regulators keep finding false.

• Takeaway 1: Article 32 names four illustrative categories of measure, not a fixed checklist. Pseudonymisation and encryption, ongoing system resilience, timely restoration after an incident, and regular testing of effectiveness.
• Takeaway 2: “Appropriate to the risk” means the bar moves as the data and the threat landscape change. A measure that was appropriate for a given processing activity years ago is not automatically still appropriate today.
• Takeaway 3: Security failures dominate major GDPR enforcement, not procedural gaps. Multi-million-euro fines in 2026 continue to cite inadequate technical and organisational measures as the core failure.
• Takeaway 4: Encryption without customer key control satisfies the letter of pseudonymisation weakly. If the processor can decrypt the data as easily as the controller, the protective value of the encryption is limited.
• Takeaway 5: The fourth limb, regularly testing effectiveness, is the one most organisations skip entirely. Implementing a measure once and never verifying it still works is a common, and commonly penalised, gap.

Executive Summary

Article 32 of the GDPR sets out four illustrative categories of technical and organisational measure: pseudonymisation and encryption; ongoing confidentiality, integrity, availability and resilience of processing systems; the ability to restore data availability and access promptly after an incident; and a process for regularly testing and evaluating whether those measures actually work. None of these are satisfied by a one-time implementation. Enforcement patterns through 2026 consistently show that major fines trace back to gaps in exactly these categories, most often inadequate access control, weak encryption practices, or the absence of tested incident-response capability, rather than to novel or exotic failures. For data protection and security leaders, the practical task years into the regulation’s life is not asking whether Article 32 was addressed once, but whether it is still being met against current risk.

Why “Appropriate” Is a Moving Target, Not a Fixed Standard

Article 32 deliberately avoids naming specific technologies or configurations, requiring instead that measures be appropriate to the risk presented by the processing in question. This makes the provision durable across changing technology, and also means compliance is never a one-time achievement.

Risk-Based Language Means the Bar Moves With the Data and the Threat

A measure judged appropriate for a given category of personal data, processed in a given way, against a given threat landscape, does not remain appropriate automatically as any of those three factors change. Processing more sensitive data, facing more capable adversaries, or simply scaling up the volume of processing all raise what “appropriate” requires, even if no specific measure was ever removed or weakened.

Regulators Read “Appropriate” Against What a Reasonable Organisation Would Have Done

Enforcement decisions consistently evaluate whether the measures in place matched what a reasonable organisation handling that kind of data, at that kind of risk, would have implemented, not whether the organisation had some plausible security measures in place. This standard rewards organisations that can point to a considered, current assessment of risk and response, rather than a static policy nobody has revisited.

What Each of the Four Categories Actually Requires

Article 32(1) names four categories explicitly, and each has failed in ways that show up repeatedly in enforcement decisions.

Pseudonymisation and Encryption That Actually Limits Exposure

Encryption satisfies this category weakly if the entity holding the encrypted data can also decrypt it as a matter of course, because the protective barrier the encryption is meant to provide collapses the moment that same entity is compromised or compelled. Pseudonymisation similarly needs to genuinely separate identity from the underlying data, not just relabel it in a way that is trivially reversible by anyone with routine access.

Ongoing Confidentiality, Integrity, Availability and Resilience

This category is explicitly continuous: not “was the system secure when deployed” but “does it remain confidential, intact, available and resilient on an ongoing basis.” Enforcement decisions citing this limb repeatedly involve access controls that degraded over time, unpatched vulnerabilities left unaddressed, or architectural weaknesses that existed for a long window before a breach exposed them.

Timely Restoration After a Physical or Technical Incident

This category asks a specific operational question: if systems go down or data becomes unavailable, how quickly can access be restored. An organisation with no tested disaster recovery capability, or one that has never actually rehearsed restoring from its backups, does not meet this requirement in any meaningful sense, whatever its documentation claims.

Regularly Testing and Evaluating What Was Implemented

This is the limb most commonly skipped entirely. Implementing encryption, access controls and a disaster recovery plan once, and never testing whether any of it still functions as intended, fails Article 32(1)(d) even if the other three categories were addressed correctly at the outset. Regular testing is not optional diligence. It is a named, independent requirement.

Why This Is Still the Article That Produces the Biggest Fines

Years into GDPR’s enforcement life, Article 32 remains the dominant citation in major penalties precisely because it is continuous rather than one-time, and because organisations consistently treat continuous obligations as if they were finished once.

Security Failures, Not Procedural Gaps, Drive the Largest Penalties

Major fines through 2026 continue to centre on inadequate technical and organisational measures following a breach, rather than on documentation or transparency shortfalls. A regulator investigating a breach asks first whether appropriate security measures were in place and functioning, because that question determines whether the breach reflects reasonable risk or a foreseeable gap.

A Measure That Was Adequate Once Is Not Evidence It Is Adequate Now

Organisations that implemented strong measures at the outset sometimes treat that implementation as permanent proof of compliance. Article 32’s continuous framing means the relevant question during an investigation is the state of the measures at the time of the incident, not their state at initial deployment.

Building an Article 32 Programme That Holds Up Years In

The practical response is to treat all four categories as ongoing operational commitments rather than a completed project: verify that encryption and pseudonymisation genuinely limit exposure rather than being trivially reversible by a routine administrator, confirm that access controls and system integrity are being monitored continuously rather than checked once, test disaster recovery capability on a real schedule rather than assuming it works, and document the testing itself as part of the evidence base, since the fourth category exists independently of the other three.

How a Data Control Plane Supports Continuous Article 32 Compliance

Meeting Article 32 as an ongoing obligation, rather than a one-time implementation, requires a platform where encryption genuinely limits who can access data, where access and system activity are continuously monitored across every channel, and where recovery and testing capability is built in rather than assembled separately.

The Kiteworks Data Control Plane supports customer-owned encryption keys through a hardware security module, so encryption limits exposure meaningfully rather than depending on a processor’s own decryption capability, and audit logs are anonymised by default, adding a genuine pseudonymisation layer to activity records. Single-tenant architecture, a hardened virtual appliance, and embedded firewall and intrusion-detection layers support ongoing confidentiality, integrity and resilience, while built-in high-availability and disaster-recovery configurations, together with a node migration capability for operational transitions, support timely restoration after an incident. Kiteworks undergoes regular penetration testing and yearly audits of its own controls, and every action across every channel, including email, file sharing, APIs and AI agents, is captured in a tamper-proof, unthrottled audit log that feeds directly into SIEM tooling, giving organisations the continuous evidence base Article 32(1)(d) actually asks for.

Organisations that want to test whether their current technical and organisational measures would hold up against a fresh Article 32 assessment can schedule a custom demo to see how continuous, evidenced security controls apply to their own environment.