Health apps: how HDS, GDPR and medical device rules change your project
10 min read
Key takeaways
- Compliance is decided during development, not in a document attached at the end.
- Third-party SDKs are the first source of non-compliance: each one collects data, often without the team knowing.
- Consent must be as easy to refuse as to accept, and revocable at any time.
- Account deletion from within the app is required by the stores as much as by the regulation.
- An up-to-date record of processing and a retention period for each piece of data: that is what is actually checked.
The GDPR is still too often treated as a legal document added to the project a week before launch. That is a methodological error: compliance is played out in technical decisions taken during development, and catching up afterwards costs three to five times more.
Here is what this means in concrete terms for a mobile app, without legal jargon.
What is actually checked
In the inspections we know of, four points come up systematically.
- The inventory of processing: which data, for what purpose, for how long, accessible to whom.
- Consent: obtained before tracking, as easy to refuse as to accept, revocable, and kept in a provable way.
- Transfers: which processors, in which countries, under what contractual framework.
- Individuals' rights: access, rectification, erasure, portability — and the ability to actually exercise them, not just mention them.
The rest — the privacy policy, the notices, the charter — follows from these four points. That is why writing the policy first is pointless: you would be describing a reality you have not yet built.
The point that causes the most problems: third-party SDKs
This is the first source of gaps we encounter, and it is almost always unintentional.
A typical app embeds: an audience measurement tool, a crash tracking tool, a push notification module, sometimes an ad network, an attribution measurement tool, a support chat, a mapping service. Seven libraries, seven data collections, and generally no trace in the record.
The exercise to do once a year: list all your app's third-party dependencies. For each one, answer four questions — what data does it collect, to which country, under what legal basis, and is it conditional on consent? Any line without an answer is a risk, and often also a library nobody needs any more.
Two technical rules follow:
- No non-essential SDK should initialise before the user's choice. Initialising it and then "disabling collection" is not enough: most send a request at startup.
- Crash tracking and strictly internal audience measurement can often rely on legitimate interest, provided they are documented, limited and free of any advertising identifier. Targeted advertising, on the other hand, requires consent.
The technical checklist before publishing
| Requirement | Technical translation |
|---|---|
| Prior consent | No non-essential tracker initialised before the choice |
| Refusal as simple as acceptance | Two buttons of equal visual weight, no refusal hidden at a second level |
| Revocable consent | A "Privacy" entry in the app's settings |
| Proof of consent | Timestamped, versioned choice, stored server-side |
| Right to erasure | Account deletion from within the app, effective within 30 days |
| Right of access and portability | Export of the user's data in a readable format |
| Minimisation | No field collected "just in case" |
| Retention periods | Scheduled automatic purge, per category of data |
| Security | Encryption in transit and at rest, secrets kept out of the app's code |
| Record | Up-to-date document, with processors and transfers |
The "account deletion" line deserves particular attention: it is required by both the regulation and the app stores. Its absence is a frequent reason for rejection, and therefore a scheduling risk as much as a compliance one.
7Third-party libraries collecting data in a typical app
3–5 ×Extra cost of compliance handled after the fact
30 dUsual time to make a deletion request effective
Secrets in the app
A technical point that is not strictly GDPR, but that causes the most serious incidents: a mobile app is not a trusted environment. Everything embedded in the binary can be extracted — API keys, credentials, internal URLs.
The rule is simple: no secret giving access to personal data should be in the app. Sensitive calls go through your server, which handles authentication and authorisations. This is also what lets you revoke access without publishing an update.
The real cost of compliance
On a project scoped from the start, compliance represents 3 to 6% of the budget: the consent screen, account deletion, data export, automatic purge and the record.
On a project where it is handled after the fact, we are talking more like 10 to 20%, because you have to revisit architecture choices, remove dependencies already integrated and sometimes change the data model.
Compliance is not a document to produce, it is a behaviour of the software. If your app cannot delete an account, no privacy policy will make up for it.
Where to start
Three actions, in this order, achievable in a week:
- Inventory your third-party dependencies and remove those nobody uses. It is free, immediate, and reduces the compliance surface.
- Check that no request goes out before consent, by observing network traffic on first launch. It is a one-hour test, and an eye-opening one.
- Implement account deletion if it does not exist. It is the most visible requirement, the most checked, and one of the least costly.
The rest — record, periods, policy — is then documented, on a real basis rather than a theoretical one.
Sources
- Applications mobiles : la CNIL publie ses recommandations (in French) — CNIL (the French data protection authority)
- Cookies et traceurs : que dit la loi ? (in French) — CNIL
- Le registre des activités de traitement (in French) — CNIL
- Exigences de Google Play concernant la suppression de comptes — Google Play Console
