"GDPR-compliant" appears on nearly every healthcare software vendor's homepage, usually beside a padlock icon nobody clicks on. For a buyer, that phrase should trigger a specific verification, not reassurance. GDPR compliance is a set of checkable facts about data location, processing basis, and breach accountability - not a certification a vendor holds once and reuses forever.
The claim covers several separate obligations, not one
A vendor can satisfy some GDPR obligations and fail others while still using the same one-line claim. Lawful basis for processing, data minimisation, the right to erasure, and breach notification are each independent requirements. Patient data specifically falls under Article 9 - the GDPR category covering health data, biometric data, and a small number of other sensitive categories, which requires stricter safeguards than standard personal data. In practice, "GDPR-compliant" from a vendor usually means "we have a data processing agreement and encrypt data in transit." That is a small part of the actual requirement.
The unresolved question is where the data goes after collection
A large share of patient engagement software marketed into Europe is built and hosted in the United States, where a US company can be compelled to disclose data under US law regardless of where the server is physically located. After the Schrems II ruling struck down the EU-US Privacy Shield in 2020, most vendors moved to Standard Contractual Clauses to justify these transfers. That mechanism is not settled law. The framework that replaced it, the EU-US Data Privacy Framework, was challenged in the EU General Court as recently as September 2025. A vendor built on this dependency is built on a legal basis that has already failed once.
Enforcement in this sector is active, not theoretical
EU data protection authorities have issued 265 fines totalling roughly EUR 32.3 million against hospitals, pharmacies, and physicians for data protection failures. Two recent cases involved vendors, not the healthcare provider directly: the CNIL fined health software supplier Cegedim Santé EUR 800,000 in 2024 for failures in how patient records were processed, and the UK ICO fined an IT services provider EUR 3.49 million for security failures that disrupted NHS operations - the first time that regulator fined a processor rather than the provider itself. A vendor's compliance gap becomes the buyer's incident.
Four questions that separate a verifiable answer from a claim
A vendor with a real compliance posture can answer each of these directly:
- Which country, and which specific data centre, is patient data hosted in - not "the EU" as a region
- Who are the subprocessors, and where are they located
- Can the buyer choose to host on its own infrastructure if required
- What is the documented breach notification process, not a clause referencing one
A vendor without a specific answer to each of these is describing an intention, not an architecture. The same gap shows up further down the stack: when patient information is spread across disconnected systems, nobody can say with confidence where all of it lives, which makes the first question impossible to answer honestly.
Self-hosting removes the question instead of answering it
A self-hosted deployment, or one running on infrastructure the buyer controls, means patient data does not depend on a cross-border transfer mechanism at all. There is no Standard Contractual Clause to defend and no exposure to the next legal challenge against the EU-US framework. For buyers with strict data-residency requirements, this converts compliance from a claim to a fact that can be shown directly to a security reviewer.
Holty is built on this model: patient data hosted on the buyer's own infrastructure or a named EU cloud environment, with the compliance architecture stated explicitly rather than asserted. It is the same principle that decides whether telemedicine runs inside your own app or a marketplace's - who holds the data, and under whose name.
Walk through your environment with us
Book a 15-minute technical review and we'll go through the specific requirements of your setup.
Frequently asked questions
What does "GDPR-compliant" actually require from a patient app?
A documented lawful basis for processing patient data, a named hosting location, disclosed subprocessors, and a tested breach-notification process. A privacy policy referencing GDPR is not equivalent to an architecture built to satisfy it.
Can a US-based vendor be GDPR-compliant?
Only if data transfers rely on a currently valid legal mechanism, such as the EU-US Data Privacy Framework or Standard Contractual Clauses. Both have already faced legal challenges, which makes this a moving target rather than a settled guarantee.
What is healthcare data residency?
A contractual or regulatory requirement that patient data physically remains within a defined jurisdiction, typically the EU or a specific member state, removing dependency on cross-border transfer mechanisms that can be struck down.
Does self-hosting alone guarantee compliance?
No. Self-hosting removes the cross-border transfer question, which is the largest source of ambiguity in most vendor claims, but the buyer still needs correct access controls, encryption, and internal processes.
What should a buyer ask before accepting a compliance claim?
The specific hosting location, the subprocessor list, whether self-hosting is available, and the exact breach notification process. A vendor with a direct answer to all four has a verifiable posture. A vendor without one has a claim.
