Health data carries the highest protection the regulation offers, for an obvious reason: a leaked diagnosis can’t be reissued like a card number. Yet the costliest failures in the sector rarely involve a sophisticated attacker. They involve a curious employee, a shared login, and an access model that let hundreds of people open a record only a handful needed. Healthcare and health-tech organisations that pour their privacy budget into the perimeter while leaving the inside wide open are defending the wrong wall.
Special Category Means Start From “No”
Health data is treated differently from the ground up. Under Article 9, processing it is prohibited by default — the starting position is “you can’t,” and an organisation has to find a specific exception that lets it. That means two things have to line up for every use: an ordinary lawful basis under Article 6, and a special-category condition under Article 9, such as the provision of healthcare, a public-health purpose, or explicit consent. Most clinical processing rests on the healthcare-provision condition rather than consent, because consent in a care setting is hard to make genuinely free — a point that catches out many health-tech teams who reach for a consent checkbox by reflex.
The Threat Is Usually Inside
The defining privacy risk in healthcare isn’t the firewall — it’s the trusted insider. Staff opening records out of curiosity, for gossip, or for gain is the recurring pattern behind the sector’s fines, and the defences against it are unglamorous: least-privilege access so that only the people involved in someone’s care can see their record, strong authentication on clinical systems, and audit logging that is actually monitored rather than merely collected. A log nobody reads catches nobody.
| Control | What good looks like | Where it fails |
|---|---|---|
| Access control | Least privilege; only the care team opens the record | Broad access “in case it’s needed”; shared logins |
| Authentication | Strong, two-factor access to clinical systems | A single password guarding a lifetime of diagnoses |
| Audit logging | Monitored access logs that flag anomalies | Logs kept but never read; checks only on complaint |
| Lawful basis | An Article 6 basis plus an Article 9 condition | Relying on consent that isn’t free in a care setting |
HealthTech: New Surfaces, Same Rules
Apps, wearables, telehealth, and AI diagnostics add new ways to collect health data, not new exemptions from the rules. Data a fitness app infers — a likely condition deduced from heart-rate patterns — is still health data, with the full weight of Article 9 behind it. Consent for a consumer health app has to be genuine and specific, not buried in a terms-of-service scroll; sharing data with insurers or employers is a minefield; and training an AI model on patient data raises hard questions about basis and secondary use that have to be answered before the model is built, not after.
When a well-known Dutch reality-TV figure was hospitalised, roughly two hundred staff at the hospital opened her medical record — almost none of whom had any role in her care, and some of whom leaked details to the press. In 2019 the Dutch regulator fined the hospital €460,000, the country’s first GDPR penalty, and the finding had nothing to do with an external attacker. It was that the hospital’s own access was too loose: no two-factor authentication on patient records, and log monitoring so thin — a random check of a handful of files a year — that mass snooping went unnoticed. The regulator’s point generalises across the sector: with health data, the perimeter is rarely the problem. The danger is the trusted insider with more access than the job requires and no system watching what they open. Protecting health data is mostly an internal-access and logging problem wearing a cybersecurity costume.
Consent in a Care Setting Is Fragile
Consent looks like the obvious answer for health data and is usually the wrong one. The regulation requires consent to be freely given, and a patient whose care depends on agreeing cannot freely refuse — the power imbalance makes the consent hollow. So clinical processing leans on healthcare-provision conditions, and consent is reserved for the genuinely optional: taking part in research, receiving marketing, the extra features of a health app. Using consent where it isn’t free doesn’t add protection; it builds the whole programme on a basis that won’t hold.
Looks Secure vs. Actually Protects Patients
Pattern-matching from real health-data reviews — the gap between looking secure and protecting patients tends to follow the same shape:
| Looks compliant | Actually protects patients |
|---|---|
| ✗ Strong firewall, open internal access | ✓ Least-privilege access scoped to the care team |
| ✗ One password for clinical systems | ✓ Two-factor authentication on patient records |
| ✗ Logs collected, never read | ✓ Monitored logs that flag unusual access |
| ✗ Consent ticked at admission for everything | ✓ Care-provision basis; consent only where it’s real |
| ✗ App data “anonymised” but re-identifiable | ✓ Genuine de-identification, or full Article 9 treatment |
| ✗ Patient data quietly reused to train models | ✓ A documented basis for every secondary use |
| ✗ Access reviewed only after an incident | ✓ Access and logs reviewed as routine |
DPIAs Are Not Optional Here
Large-scale processing of health data is exactly the kind of high-risk activity the regulation says must have a data protection impact assessment before it begins. For a hospital, a clinic network, or a health-tech product, that isn’t a formality to produce when a regulator asks — it’s the structured way to find the access, retention, and sharing risks while they’re still cheap to fix, rather than after a patient’s record has travelled somewhere it shouldn’t.
Final Thought
Health data is the category the regulation guards most closely, and the sector keeps learning the same lesson: the expensive failures come from the inside. The discipline that protects patients isn’t a thicker perimeter — it’s tight access, real authentication, logs that are watched, a lawful basis that doesn’t lean on hollow consent, and an impact assessment done before launch. None of it is glamorous, and all of it is what the fines are actually about.
The test: for any patient record, answer three things without a project — who can open it and why, would unusual access be noticed today, and on what condition is the data lawfully processed. If the honest answer is “most staff can see most records and nobody’s really watching,” the next snoop is already the next fine.
Frequently Asked Questions
Yes. Article 9 lists health data as a special category and the starting position for processing it is prohibition. Two things have to line up for every use — an ordinary lawful basis under Article 6, and a special-category condition under Article 9, such as the provision of healthcare, a public-health purpose, or explicit consent.
Consent has to be freely given, and a patient whose care depends on agreeing cannot freely refuse. The power imbalance makes the consent hollow. Clinical processing typically leans on the healthcare-provision condition under Article 9, and consent is reserved for the genuinely optional — research participation, marketing, extra features in a health app.
Three controls do most of the work: least-privilege access so only the people involved in someone’s care can see the record, strong two-factor authentication on clinical systems, and audit logging that is actually monitored — not just collected. A log nobody reads catches nobody.
Almost certainly. Large-scale processing of health data is the prototype of high-risk processing that the regulation requires a Data Protection Impact Assessment to cover. It is not a formality to produce when a regulator asks — it’s the structured way to find access, retention, and sharing risks while they are still cheap to fix.