The healthtech founder is technical, well-meaning, and usually wrong about GDPR.
They have built an app that tracks symptoms, stores medical histories, or connects patients with clinicians. They have read the GDPR summary on a legal blog. They have added a consent checkbox to the signup flow. They believe they are compliant.
They are not. And the mistake is not a missing cookie banner. It is a fundamental misunderstanding of what health data is and how the law treats it.
At Metaluxo we work with healthtech companies across the EU and UK — symptom trackers, telemedicine platforms, clinical trial software, and AI diagnostic tools. The compliance gaps we find are remarkably consistent. This post covers the three mistakes that appear in almost every engagement.
Mistake 1: Thinking consent is enough
The founder adds a checkbox: “I consent to the processing of my health data.” They believe this satisfies GDPR.
It does not, for three reasons.
First, health data is special-category data under GDPR Article 9. Special-category data cannot be processed on the basis of ordinary consent alone. You need both a lawful basis under Article 6 and an additional condition under Article 9. Consent can satisfy Article 9, but it is rarely the right choice for health data because it can be withdrawn at any time — and if the patient withdraws consent, you must delete their data, including any analytics or models derived from it.
Second, consent must be freely given, specific, informed, and unambiguous. In a health context, where the user may need the service to manage a condition, consent is often not considered freely given. Regulators view this as a power imbalance.
Third, most healthtech apps do not actually rely on consent as their legal basis. They rely on healthcare provision, public health interest, or scientific research — each of which has its own conditions and safeguards. If you claim consent but your actual processing relies on a different basis, your privacy policy is misleading and your GDPR documentation is wrong.
The fix: Identify the real legal basis for each processing activity. Document it in your records of processing activities. Write the privacy policy to match the reality, not the checkbox.
Mistake 2: Not knowing where patient data lives
The founder knows the application is hosted on AWS in Frankfurt. They do not know that:
- The error-logging service stores stack traces in Virginia
- The customer support tool retains chat transcripts in Ireland
- The analytics platform processes events in Singapore
- The backup snapshot replicates to a secondary region automatically
- The developer’s local machine has a copy of the production database from last month’s debugging session
GDPR Article 44–49 restrict transfers of personal data outside the European Economic Area. Health data — as special-category data — faces even higher scrutiny. A transfer to a non-adequate country requires safeguards: Standard Contractual Clauses with a transfer impact assessment, or Binding Corporate Rules, or an explicit derogation.
Most healthtech founders we meet have not conducted a transfer impact assessment. Many do not know what a TIA is. When we map their data flows, we usually find three to five unexpected third-country transfers, each of which requires documentation that does not exist.
The fix: Map every data flow — not just the primary database, but every service that touches personal data. For each, document: the provider, the location, the legal basis for transfer, and the safeguard in place. This is the core of your records of processing activities, and it is the first thing a regulator will ask for.
Mistake 3: Treating a health app like any other SaaS
A standard SaaS company needs an information security policy, a privacy policy, and a terms of service. A healthtech company needs all of those plus:
- A data protection impact assessment (DPIA) — mandatory under GDPR Article 35 for high-risk processing, which includes systematic monitoring of health data. Most healthtech apps require a DPIA before launch.
- A clinical safety case — if the app influences clinical decisions, you need evidence that it is safe, accurate, and validated. This is not a GDPR requirement, but it is a requirement of medical device regulation (MDR/IVDR in the EU, MHRA in the UK) and clinical governance.
- A breach notification procedure — GDPR requires notification to the supervisory authority within 72 hours. For health data, the threshold for notification is lower because the risk to data subjects is higher. You need a procedure that can assess and notify within 24 hours, not 72.
- A data retention and deletion schedule — health data cannot be kept indefinitely. You need a clear policy: how long you keep each category of data, why, and how you delete it securely when the period expires.
The founder who treats a health app like a standard SaaS will have a privacy policy that mentions cookies but not clinical safety, a security policy that covers passwords but not access logging for patient records, and an incident response plan that assumes a phishing email is the worst-case scenario.
The fix: Run a health-specific gap assessment that covers GDPR, clinical governance, and medical device regulation together. The frameworks overlap, but they are not the same, and compliance with one does not guarantee compliance with the others.
What regulators actually check
When the ICO, the UODO, or another EU supervisory authority investigates a healthtech company, they do not start with the code. They start with the paperwork.
- Records of processing activities — Can you produce a complete list of what data you process, why, where, and with whom?
- Data protection impact assessment — Did you conduct a DPIA before launch? Did you review it when you changed the product?
- Data subject rights log — How many access requests have you received? How long did you take to respond? Did you verify identity before disclosure?
- Breach register — Have you had any breaches? How did you assess risk? Did you notify within 72 hours?
- Third-party contracts — Do your processors have data-processing agreements? Do your sub-processors? Can you produce them?
The regulator is checking that you have a management system for data protection, not that your encryption is perfect. A company with AES-256 encryption and no DPIA will fare worse than a company with basic encryption and complete documentation.
How to fix it
If you are a healthtech founder and you recognise one or more of these mistakes, the fix is not to panic. It is to priorities.
Month 1: Map your data flows and write your records of processing activities. This is the foundation everything else builds on.
Month 2: Conduct a data protection impact assessment. If you already launched without one, do it now and document any mitigations you have already implemented.
Month 3: Review your legal bases. If you are relying on consent for health data, get legal advice on whether a different basis is more appropriate.
Month 4: Audit your third-party services for unexpected data transfers and sign data-processing agreements with every processor.
Month 5: Train your team. Health data handling is not intuitive. Staff need to know what constitutes a breach, how to report it, and what they must never do with patient data.
At Metaluxo we run GDPR and health data compliance programmes for healthtech startups and SMEs, typically delivering a gap assessment in four weeks and a remediation roadmap in eight. If you are preparing for a clinical partnership, a funding round, or a regulatory inspection, book a free 30-minute consultation and we will tell you exactly where you stand.
The companies that survive regulatory scrutiny are not the ones with the most complex systems. They are the ones with the clearest documentation. Start with the map. Everything else follows.
Common questions
Can a healthtech app rely on user consent for processing patient data?
Usually no. GDPR Article 9 requires a specific legal basis for special-category data, and consent can be withdrawn. Most healthtech apps process data under a different basis, such as healthcare provision with appropriate safeguards, or public health interest.
What is the maximum GDPR fine for a health data breach?
Up to €20 million or 4% of global annual turnover, whichever is higher. Health data breaches tend toward the upper end because the data is classified as high-risk.
Do we need a Data Protection Officer?
Yes, if your core activity involves large-scale processing of special-category data. For a healthtech startup, this threshold is usually reached once you have more than a few thousand patient records.
