Self-Hosted Nutrition // calorie tracking without the SaaS
#gdpr#ccpa#data-subject-rights#privacy#templates

Practical GDPR (and CCPA) rights against nutrition apps

How to file an access request, what to expect, and what to do when they stall.

By Alex Brennan · Published

What rights you actually have

This is not legal advice. It’s a practical walkthrough by a non-lawyer who has filed roughly 30 of these requests against nutrition apps and adjacent services since 2022.

Under GDPR (EU/EEA, UK), you have:

  • Access (Art. 15): the operator must give you, on request, all personal data they hold about you, in a machine-readable format.
  • Portability (Art. 20): you can ask for the data in a “commonly used” format so you can move it.
  • Rectification (Art. 16): correct inaccuracies.
  • Erasure (Art. 17), the “right to be forgotten.”
  • Restriction (Art. 18): freeze processing while a dispute is pending.
  • Objection (Art. 21): object to processing, particularly for direct marketing.

Under CCPA / CPRA (California), you have similar rights with different naming and a separate “do not sell or share” toggle that’s specifically powerful against ad-network sharing.

Under similar state laws (Virginia VCDPA, Colorado CPA, etc.) and many other jurisdictions: variants of the above.

If you live somewhere with no analogous law: you can still file the request. Many operators apply GDPR-style processes globally because it’s simpler than maintaining different regimes. We have had “no jurisdictional rights” requests honoured anyway.

What to ask for

A good access request should explicitly enumerate:

  1. All personal data held about you, in machine-readable format (JSON or CSV).
  2. The categories of recipients of that data.
  3. The retention period for each category.
  4. Whether automated decision-making or profiling is applied.
  5. The sources of the data if it wasn’t collected from you directly.

Most operator portals only address (1). You have to ask for the rest in plain text.

Template (use freely)

Subject: Data Subject Access Request under GDPR Art. 15 / CCPA §1798.110

Hello,

This is a formal data subject access request. I am [name] and my account is
registered to [email].

Under GDPR Article 15 (and where applicable CCPA §1798.110), I request:

1. A complete copy of all personal data you hold about me, in a machine-readable
   format (JSON or CSV).
2. The categories of personal data processed.
3. The categories of recipients to whom the data has been disclosed,
   including any third parties used for analytics, advertising, or product
   improvement, with specific names of those parties.
4. The retention period for each category, or the criteria used to determine
   retention.
5. Whether automated decision-making or profiling is applied to me.
6. The sources of any data not collected directly from me.

Please confirm receipt within 7 days and respond in full within the 30-day
period required under GDPR Art. 12(3).

Regards,
[name]

Send to the contact listed in their privacy policy as the data controller / DPO. If they don’t list one, send to their general support address with “DSAR” in the subject — they’re required to escalate it.

Real timelines we’ve seen

Recent (2024–2026) request → response timing for nutrition apps:

OperatorAcknowledgedSubstantive responseQuality
MyFitnessPal<48h17 days(1) only, partial
Cronometer<24h7 days(1) full, (2-6) partial
Lose It!5 days28 days(1) only
Noom7 days24 days(1) only, slow
MacroFactor<48h12 days(1) full, (2-6) good

The 30-day window is real. Operators who exceed it without claiming an extension are in violation. Operators who claim a 60-day extension under Art. 12(3) without justification are sailing close to the wind.

When they don’t deliver

Three escalation paths:

1. Their DPO directly

Most operators have a Data Protection Officer email even if it’s not prominent. Search for “data protection officer site:[domain]” on their support pages. Email the DPO directly with a polite escalation.

2. Your country’s Data Protection Authority

EU/EEA: each member state has a DPA. The complaint forms are in the local language; some accept English. UK: the ICO. Filing a complaint costs nothing and tends to extract a response from the operator within 30 days even if you’ve been waiting six.

3. NOYB

For European users: NOYB (None of Your Business, noyb.eu) accepts complaints about persistent operator violations and will sometimes pursue them on your behalf. They are the people who pursued Schrems II and have meaningful enforcement experience.

CCPA “do not sell or share”

For California residents specifically: the CCPA’s “do not sell or share” right is, in our experience, more concretely enforced than the GDPR’s behavioural-ad opt-out. Filing a “do not sell or share” request through an operator’s portal usually results in:

  • Their analytics events to ad networks getting the “limited data use” flag.
  • Behavioural targeting based on your data ceasing within 15 days.
  • Their privacy email confirming the request in writing.

We file CCPA “do not sell or share” requests as a matter of course on every account.

Erasure

The right to erasure is harder. Operators have two arguments they often raise:

  • Legitimate retention for tax / legal records (“we kept your billing records”).
  • Backups that take time to age out (“we deleted you from production but our backups are 90 days”).

Both can be legitimate; both can also be excuses. The right test is whether your data has been removed from the active processing systems. Backups aging out is acceptable up to a reasonable retention window (60–90 days is typical).

We have observed three nutrition apps (one no longer named in this piece because they fixed it) where “erased” accounts continued to receive marketing emails for 30+ days. That is not acceptable, and a DPA complaint reliably resolves it.

What to do with the data once you have it

If you intend to switch trackers, the data you get from the access request is rarely directly importable to a new tracker. Cronometer’s export imports cleanly into Cronometer; MFP’s export does not import cleanly into anything except MFP.

For long-term archival: dump it into a Postgres on your homelab and write a small script that normalises whatever schema you got into a common one. We have a 200-line Python tool for this; it lives in our private homelab repo.

For burning the relationship cleanly: file the access request, save the export, file the deletion, confirm via a follow-up access request that the data is gone.

References