Patient data is among the most sensitive information any organisation holds, and healthcare providers in the Netherlands handle it every minute of the day. Diagnoses, imaging, prescriptions and referral letters move between clinicians, laboratories, insurers and public bodies, and each movement is a chance for something to go wrong.
The concrete problem is that GDPR Article 32 asks for security that is "appropriate to the risk", yet gives no product list and no fixed checklist. A hospital group has to decide for itself what appropriate means, defend that decision to auditors, and keep it current as workflows change.
This article explains what Article 32 asks of healthcare providers, where patient data is most exposed, and how to turn the requirement into controls you can operate, measure and evidence.
Executive Summary
GDPR Article 32 requires controllers and processors to implement technical and organisational measures that match the risk to patients' rights. For healthcare providers, that means protecting patient data at rest and in motion, limiting who can reach it, keeping systems available, and testing the whole arrangement regularly. The weakest point is rarely the database. It is the email, file transfer and partner exchange that carries patient data out of the building. Decision-makers who treat Article 32 as an operating discipline, with enforced access rules and trusted audit logs, can reduce attack surface, respond faster to incidents and show supervisory authorities a defensible record.
Key Takeaways
- Article 32 sets a risk-based standard, not a checklist. Providers must justify their chosen measures against the nature of the patient data, the processing context and the likely harm to individuals.
- Data in motion is the exposure most providers underestimate. Email attachments, shared folders and partner transfers carry patient data beyond systems that posture tools already monitor, so they need their own enforced controls.
- Confidentiality depends on least-privilege access and strong authentication. Users should start with no access, receive only what their role needs, and prove identity with multi-factor authentication before any patient data is opened.
- Integrity and availability need engineering, not assumptions. Clustering, replication, tested backups and tight change control keep patient data accurate and reachable when systems fail or are attacked.
- Evidence is part of the control. Trusted audit logs, streamed to SIEM and SOAR tools, turn security measures into a record that auditors and incident responders can rely on.
What GDPR Article 32 Requires From Healthcare Providers
Article 32 applies to both controllers and processors, so a hospital, a clinic network and the cloud or transfer services they use all carry duties. The text asks them to consider the state of the art, the cost of implementation, the nature, scope, context and purposes of processing, and the risk to individuals. Health data raises that risk level, because exposure can cause real harm to patients and cannot be undone.
A Risk-Based Standard Instead of a Fixed Checklist
The article does not say "use product X". It asks for a level of security appropriate to the risk, which means the provider owns the reasoning. In practice, a risk assessment should link each category of patient data to the threats it faces, such as accidental disclosure, unlawful access, loss or alteration, and then record why each chosen measure is proportionate. Reviewers tend to ask for that reasoning first, so keep it written down and keep it current.
The Measures the Article Names
Article 32 gives examples rather than orders. It lists pseudonymisation and encryption of personal data, the ability to ensure ongoing confidentiality, integrity, availability and resilience of systems, the ability to restore access to data promptly after an incident, and a process for regularly testing and evaluating the effectiveness of the measures. It also notes that adherence to approved codes of conduct or certification mechanisms can help demonstrate compliance. Taken together, those examples describe a cycle of protect, withstand, recover and verify, and a healthcare provider should be able to point to an owner and an evidence source for each step.
Where Patient Data Is Most Exposed in Healthcare Workflows
Most security budgets concentrate on the systems where patient data lives, such as electronic health records and imaging archives. Exposure grows once that data leaves those systems. Referrals travel to specialists by email, laboratories return results as attachments, and research teams share datasets with external partners. Each of these paths sits outside the controls of the original system.
Email and File Exchange With External Parties
Picture a regional hospital group where an administrator emails a discharge summary to the wrong recipient with a similar name. Nothing was hacked, yet patient data has been disclosed, and the group now has an incident to assess. Misdelivery of this kind is common precisely because the workflow is routine. Controls that scan attachments, require authenticated recipients and allow access to be revoked after sending turn that mistake from an irreversible disclosure into a manageable event.
Clinical Research and Third-Party Collaboration
Research partnerships, insurers and outsourced laboratories all need some patient data, but rarely all of it. The risk comes from copies that persist long after a project ends. Providers reduce that exposure when partner access is time-limited, role-based and logged, so that the question "who opened this file, and when?" always has a precise answer.
Turning Article 32 Into Operational Controls
Good intentions do not satisfy the article. Controls must be enforced by the systems that move patient data, and they must generate evidence without manual effort from clinical or IT staff.
Encryption and Pseudonymisation for Patient Data
Encryption protects patient data in storage and in transit, and the strength of the result depends on key management as much as on the algorithm. Organisations should expect to control their own keys, consider hardware security module integration for the most sensitive repositories, and set minimum transport protocol versions deliberately. Pseudonymisation, by contrast, usually belongs upstream in the data platforms that prepare datasets for research, so the exchange layer should preserve it rather than undo it.
Confidentiality Through Access Controls and Authentication
Confidentiality fails when access is granted broadly and reviewed rarely. A least-privilege model starts every user with no access and extends it through roles and explicit invitations. Multi-factor authentication, single sign-on through the organisation's identity provider and session timeouts then reduce the damage from stolen credentials. Describe these rules in policy, enforce them in the platform, and test them on a schedule.
Integrity, Availability and Recovery
Integrity means patient data arrives and remains unaltered, and availability means clinicians can reach it when care depends on it. Both need engineering: clustered services, replicated storage, encrypted scheduled backups, and a recovery process that has been rehearsed. Measure mean time to detect and mean time to recover across drills, and treat any gap as a finding to close before a real incident exposes it.
Regular Testing and Evidence
Article 32 expects effectiveness to be tested, not assumed. Audit logs that capture who accessed, shared, downloaded or changed patient data give testers and auditors something concrete to examine. When those logs feed a SIEM in real time and trigger SOAR playbooks, detection and remediation speed up, and the record supports a credible account of what happened and how the organisation responded.
How DSPM, IAM and Zero Trust Fit With Data in Motion
Several tool categories already contribute to Article 32 readiness. DSPM tools discover and classify sensitive data where it sits, so teams know which repositories hold patient records. IAM governs identities and entitlements across applications. A zero trust approach assumes no user, device or network is trusted by default and verifies each request.
None of these categories, on its own, governs what happens when a referral letter leaves the building as an email attachment or a research dataset is sent to a partner. That is the gap a dedicated layer for sensitive data in motion fills. It does not replace posture, identity or network tools. It complements them by enforcing rules at the point where data is sent, shared or received. For a healthcare provider, that complementary layer turns classification and identity decisions into outcomes that can be audited.
How Zivver Helps Address This Challenge
Zivver helps healthcare organisations protect patient data when they send email and files, with zero-knowledge AES-256 email encryption, ML-based human error prevention such as wrong-recipient detection, message recall with no time limit, secure file transfer up to 5TB, and audit logs and reporting. Contact us for a demo.
