Health Data Retention and Deletion: A Developer's Guide

If you collect health or fitness data, you cannot keep it forever "just in case" — and when a user asks you to delete it, you generally have to honor that. GDPR's storage limitation principle says don't hold personal data longer than you actually need it, and the right to erasure lets users require deletion in defined situations. On top of that, Apple and Google both make in-app account (and data) deletion a store requirement. The catch most teams underestimate: deletion has to reach backups, caches, logs, and third-party processors, not just your main database. This is general engineering guidance, not legal advice — the details vary by jurisdiction and by what your app does, so confirm your own obligations with a qualified professional.

The short answer

Two different obligations sit on top of each other here, and it helps to keep them separate:

• Retention — GDPR's storage limitation principle (Article 5(1)(e)): keep personal data no longer than necessary for the purpose you collected it for, then delete or anonymize it.
• Deletion — the right to erasure (Article 17): users can require you to delete their data in specific circumstances, "without undue delay."

And running alongside GDPR: app-store rules. Apple and Google require an in-app deletion path regardless of where your users live. These are contractual store requirements, related to but distinct from GDPR law.

Retention: storage limitation and data minimization

GDPR's storage limitation principle (Article 5(1)(e)) is the core rule: don't keep personal data longer than you need it for the stated purpose. Importantly, GDPR sets no fixed retention periods — there is no universal "delete after N days." Instead, you as the controller have to define, document, and justify a retention schedule for each category of data, and then delete or anonymize that data once the purpose ends.

This works hand in hand with data minimization (Article 5(1)(c)): collect less, and keep less. Data you don't hold can't be breached, and it stays out of scope for a deletion request. For sensitive health data, that "collect less, keep less" posture is one of the highest-leverage things you can do.

A practical way to make this concrete is a retention schedule mapped per data type. The values below are illustrative, not legal minimums — you have to set and justify your own based on your actual purposes.

The point isn't the specific numbers; it's that you can point to a documented, justified reason for each period.

Deletion: the right to erasure (Article 17)

Under Article 17, a user can require you to delete their personal data "without undue delay" in situations including:

• the data is no longer necessary for the purpose it was collected,
• they withdraw consent and there's no other legal basis,
• they object to the processing, or
• the data was unlawfully processed.

But the right to erasure is not absolute — don't design (or market) it as "users can always force instant, total deletion of everything." Article 17(3) sets out exceptions where you may lawfully retain data despite an erasure request:

The discipline here: honor the deletion request except where a lawful retention basis genuinely applies — and when one does, document the exception, retain only the minimum data it actually covers, for the specific reason, and delete it once the hold or obligation ends.

The in-app deletion requirement (Apple and Google)

Independent of GDPR, the app stores impose their own deletion rules:

• Apple (guideline 5.1.1(v), verify current subsection) requires apps that support account creation to offer account deletion — and the associated data — from within the app. A link to email support isn't enough.
• Google Play requires an in-app account deletion path and an option to delete data without deleting the account, plus a web-accessible deletion route, all disclosed in the Play Data safety form. Verify the exact current wording and scope, as Google's deletion-flow requirements have evolved.

These are contractual store requirements that can bite before any statute does. For the full platform picture see our Apple App Store health-data rules and Google Play health-data policy pages.

The hard part: propagating deletion everywhere

A deletion isn't done when the row leaves your primary database. To actually erase a user's data, deletion has to reach:

• backups and replicas,
• caches,
• logs and analytics (a frequent place health data leaks into),
• and every third-party processor and sub-processor you've sent data to.

Two things make this a real engineering problem. First, processors: under GDPR Article 28 you should contractually require your processors (analytics, cloud, aggregators, SDK vendors) to delete data on your instruction — and you need a way to actually issue and confirm that instruction. Second, backups: they're the classic gap. Deletions can lawfully lag against a backup cycle if you document how deletions reconcile against backups and keep access to those backups restricted in the meantime — but you have to have a plan, not a silent gap. Design a deletion pipeline, not a single DELETE statement.

For how you store the data in the first place — including why backups need their own retention and deletion coverage — see store health data securely.

What this means for a fitness app

• Write down a retention schedule per data type and justify each period. "We keep everything indefinitely" is the posture regulators push back on.
• Minimize first. The less you collect and keep, the smaller your breach surface and your deletion workload.
• Ship deletion as a real feature, in-app, covering both the account and its data — you need it for the stores anyway, and it's how you operationalize Article 17.
• Build deletion to fan out to backups, caches, logs, analytics, and processors — and put Article 28 delete-on-instruction terms in your processor contracts.
• Handle legal holds explicitly. Have a documented way to retain the minimum necessary when a lawful exception applies, and to delete it when the reason ends.
• State your retention and deletion practices in your privacy policy — see our health app privacy policy guide — and keep those statements matching what your systems actually do.

Limits and nuance

Retention periods are context-specific: avoid committing to a universal number of days or years, and set yours against your actual purposes. The right to erasure is real but bounded by the Article 17(3) exceptions. And remember the two tracks are distinct — the platform in-app-deletion requirements are store rules, while GDPR erasure and storage limitation are law; you generally have to satisfy both. For how erasure fits into the wider set of EU obligations, see GDPR for fitness apps. Use this as a starting map, not a compliance sign-off, and get advice from a qualified professional for your specific case.