Clinic data security: where patient data lives

Most clinics assume their data security is the software vendor’s problem. It is a comfortable assumption and it is wrong: under GDPR the clinic is the controller. The vendor is a processor. When there is a breach, the clinic is the one that has to notify within 72 hours, the one that answers to the patient, and the one named in the supervisory authority’s decision.

And the breach almost never arrives where people expect it. It is not someone breaking the encryption on a medical record: it is an ultrasound machine running an unpatched Windows on the same network as the front desk, a backup nobody has ever restored, or one shared account used by six people on the morning shift. This article is about where clinical data actually lives, where it breaks, and how to design infrastructure that holds.

What protecting clinical data actually means

Health data is not just another personal data point. GDPR classifies it under Article 9 as a special category: processing is prohibited by default and only permitted under specific exemptions — healthcare provision among them — and always subject to professional secrecy. In practice that means the bar for technical measures sits higher than for any commercial CRM, and a breach here is not judged the same way.

On top of that come layers many clinics discover late. Medical record retention is a legal obligation with minimum periods set at national level, and they are often longer than people expect: this is not data you delete when it becomes inconvenient, and that shapes your retention policy and your backups. The NIS2 directive places healthcare among essential sectors, with risk management and incident reporting duties. And if you provide services under public contract, national public-sector security frameworks can reach you through the contract even as a private entity.

None of this is solved with a checkbox or a certificate framed in reception. It is solved with architecture.

Real scenarios we run into

The flat network: the ultrasound, the guest Wi-Fi and the records server in one place

This is the most common pattern in healthcare environments and the most dangerous. The clinic grew by accumulation: the practice management software went in, then the imaging equipment arrived, then Wi-Fi for the waiting room, then the booking system. All hanging off the same network, because each piece was installed at its own moment and it worked.

The problem is that medical devices — the PACS, the ultrasound, the CT scanner — usually run on old operating systems the manufacturer will not let you patch without invalidating the device’s certification. These are machines you cannot patch and that will still be there in five or ten years. On a flat network, that unpatched device is one hop from the server holding medical records, and a patient’s laptop on the waiting room Wi-Fi sits in the same segment.

The answer is not replacing the ultrasound. It is accepting that the device is insecure by design and isolating it so that compromising it means nothing.

“It’s in the cloud” — but nobody knows which country

When we ask where clinical data is stored, the usual answer is “in the cloud, the vendor handles it”. That sentence says nothing. The cloud is not a place: it is somebody’s data centre, in a specific region, under a specific contract.

There are four questions you need to be able to answer, and it is worth having them in writing: which region the data is stored and processed in, whether there are sub-processors and who they are, what retention and deletion policy the vendor applies when the contract ends, and whether a signed data processing agreement covers all of the above. If your clinical software vendor will not give you those four answers in writing, you do not have a technical problem: you have a compliance problem already in motion.

Watch one detail that gets missed: a vendor can store data in the EU and still support it from outside with remote access to that data. That access is a transfer too, and it has to be covered.

One shared account for the whole front desk

The classic. A single login for the shift, because “it is faster that way”. It works until the day you have to answer who opened a specific patient’s record on a Tuesday afternoon, and the answer is “reception”.

Audit trails are not bureaucracy: with special category data, being able to demonstrate who accessed what and when is part of the security measure, not an extra. Without individual identity there is no meaningful access log, and without access logs there is no way to scope a breach or to demonstrate diligence to the authority.

The backup nobody has ever restored

Healthcare is a favourite ransomware target for a very simple reason: it is a sector where downtime has immediate clinical cost, and that pressures people to pay. The clinic that finds everything encrypted on a Monday morning discovers two things at once: that it did have backups, and that nobody had ever restored them.

And one detail decides the outcome. If the backup is mounted as a network share reachable from the same server that got compromised, the ransomware encrypts it too. A backup the attacker can reach is not a backup: it is one more copy of the problem.

How we approach it

Inventory the data first, architecture second

Before touching networks or servers, we map what data exists, where it lives, who touches it and how long it has to be kept. Places nobody had in mind almost always show up: a waiting list spreadsheet on someone’s desktop, exports for the accountant, images on the local disk of a diagnostic machine. You cannot protect what you do not know exists, and that inventory is also the basis of the record of processing activities GDPR requires.

Segment by function, not by floor

We split the network into segments on risk logic: medical devices that cannot be patched, workstations, guest Wi-Fi, servers. No traffic between segments except what is genuinely needed, declared port by port — the DICOM flow between the imaging device and the PACS, and little else. Guest Wi-Fi reaches the internet and sees nothing internal. The old medical device is still old, but it stops being a door.

Encryption in transit and at rest, and secrets out of the code

Encryption in transit for everything, encryption at rest on disks and backups, and keys managed in a secrets service (Vault, KMS) with rotation and usage auditing — never in a config file or a plain environment variable. Encryption at rest does not protect you from a compromised legitimate user, but it turns a stolen disk or a stolen copy into an incident with no data exposed, which is a very different conversation with your supervisory authority.

Individual identity, least privilege and traceability

One user per person, second factor for administrative and remote access, and role-based permissions: reception does not need to see clinical content to manage an appointment. On top of that, an immutable access log — who, which record, when — stored beyond the reach of the system itself, so that whoever compromises the server cannot erase the trail of what they did.

Isolated backups and a DR plan you rehearse

Simple, non-negotiable rule: at least one copy out of reach of the system it protects, immutable or with locked retention, encrypted. Plus a recovery plan with RTO and RPO agreed with clinic management in business terms — how many hours the practice can run without the system, how much data is acceptable to lose — and rehearsed periodically. A documented DR plan that has never been tested is a document, not a plan.

Mistakes worth avoiding

• Assuming responsibility sits with the vendor. The vendor is a processor; the clinic is the controller. That split cannot be outsourced.
• Confusing “it’s encrypted” with “we’re covered”. Encryption at rest does nothing against a compromised legitimate account, which is the most common vector.
• Backups reachable from the server they protect. If ransomware reaches the server, it reaches the copy. Isolation or immutability, or it does not count.
• Shared accounts per shift. Without individual identity there is no traceability, and without traceability you can neither scope nor prove anything.
• Accepting “it’s in the cloud” as an answer. Without region, sub-processors, retention and a DPA in writing, you do not know where your data is.
• Treating training as a formality. Phishing is still the number one way in, and no architecture compensates for a credential handed over.
• Leaving security until after the migration. Redesigning networks and access with the system already in production costs far more than planning it beforehand.

How to choose who builds it

If someone is going to review or build this for you, watch the order in which they ask questions. A good team asks what data you hold, where it lives and how long it must be kept before proposing a product. They talk about segmentation, identity and recovery before brand-name firewalls. And they tell you plainly what you do not need, because in security overselling is as easy as underselling.

Be wary of anyone offering “GDPR compliance” as a boxed package. Compliance is the result of a well-designed architecture and processes that actually get executed, not a deliverable you buy.

At LMNHUB we design infrastructure for sensitive data with layered isolation, encryption, secrets management, role-based access control and tested recovery, all defined as code so it is auditable and reproducible. The same discipline we apply to financial environments, with the particular demands of health data. If you want to see how we decide what information may leave your systems and what may not, we cover it in our guide on GDPR and AI, and the data residency and isolation criteria also come up when choosing a multi-tenancy model.

If you have had the feeling for a while that your clinical infrastructure grew without a plan, and you could not answer where your data is or who accesses it, tell us about your case and we will get back to you with a concrete assessment and a senior team, not a generic quote.