Healthcare Security Measures Regulators Still Flag

GDPR has been enforceable for years, and Article 32 remains the single most commonly cited provision in major fines. Health systems handling special category patient data face a proportionally higher bar under “appropriate to the risk.”

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. This article walks through what those four categories actually require in practice for health systems.

Executive Summary

Article 32 of the GDPR sets out four illustrative categories of technical and organisational measure. None of these are satisfied by a one-time implementation. For health systems, 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.

Key Takeaways

1. Article 32 names four illustrative categories of measure, not a fixed checklist.
2. “Appropriate to the risk” means the bar moves as patient data sensitivity and threat landscape change.
3. Security failures dominate major GDPR enforcement, not procedural gaps.
4. Encryption without customer key control satisfies pseudonymisation weakly.
5. The fourth limb, regularly testing effectiveness, is the one most health systems skip entirely.

Why “Appropriate” Is a Moving Target for Patient Data

Article 32 deliberately avoids naming specific technologies, requiring instead that measures be appropriate to the risk presented by the processing in question.

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

A measure judged appropriate for a given category of patient data does not remain appropriate automatically as sensitivity or the threat landscape changes.

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

Enforcement decisions evaluate whether the measures in place matched what a reasonable health system, handling that kind of patient data, would have implemented.

What Each of the Four Categories Actually Requires

Each category 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 patient data can also decrypt it as a matter of course.

Ongoing Confidentiality, Integrity, Availability and Resilience

This category is explicitly continuous, not a state assessed once at deployment.

Why This Is Still the Article That Produces the Biggest Fines

Major fines through 2026 continue to centre on inadequate technical and organisational measures following a breach, rather than documentation shortfalls.

Building an Article 32 Programme That Holds Up Years In

The practical response is to treat all four categories as ongoing operational commitments: verify encryption genuinely limits exposure, confirm access controls are monitored continuously, and test disaster recovery on a real schedule.

How a Data Control Plane Supports Continuous Article 32 Compliance

The Kiteworks Data Control Plane supports customer-owned encryption keys through a hardware security module, so encryption limits exposure meaningfully, and audit logs are anonymised by default, adding a genuine pseudonymisation layer. Single-tenant architecture and built-in disaster-recovery configurations support ongoing confidentiality, integrity and resilience, while every action across every channel is captured in a tamper-proof, unthrottled audit log feeding directly into SIEM tooling.

Health systems that want to test their current measures against a fresh Article 32 assessment can schedule a custom demo.