Are wearable health apps GDPR compliant? What to actually check before installing one

GDPR compliance is not a yes-or-no badge you can read off an App Store listing. It's a determination about whether the company running an app — the "controller," in the language of the General Data Protection Regulation — is meeting its obligations to you under EU law. This guide walks through what to actually verify in a wearable health app's privacy policy before you install it, with a side-by-side look at four wearables you've probably heard of.

TL;DR

No wearable health app is universally "GDPR compliant." Compliance is a controller-level call, not a label, and the Apple App Store and Google Play do not certify it. Before installing a wearable health app, read its privacy policy and verify seven things: who the data controller is and where they sit, what lawful basis they claim for processing your health data, where the data physically goes and under which transfer mechanism, who the sub-processors are, how you can actually exercise your rights, whether your data is used for profiling, advertising or AI training, and how deletion and retention work. The shorthand "GDPR compliant" is shorthand for a list — not a verdict.

What does "GDPR compliant" actually mean?

The General Data Protection Regulation — formally Regulation (EU) 2016/679 — applies whenever an organisation processes personal data of people in the EU and the EEA. "Personal data" is anything that can identify you, directly or indirectly. "Processing" covers nearly anything a service does with that data: collecting it, storing it, analysing it, sharing it, deleting it. Compliance means that the company doing the processing — the controller — can demonstrate that every processing activity has a lawful basis under Article 6, respects the principles in Article 5 (lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, accountability), and gives you the rights set out in Articles 12 to 22 (transparency, access, rectification, erasure, restriction, portability, objection, and rights related to automated decisions).

Two consequences flow from this that App Store listings tend to obscure.

The first is that compliance is per controller, not per app. An app that is offered in the EU is not automatically compliant; the company behind it has to do work to be compliant. There is no global stamp, no central registry, no Commission seal that confirms an app's compliance. The European Data Protection Board and national data protection authorities can issue guidance and impose fines, but they don't pre-clear products. You're left to read the policy.

The second is that compliance and good practice are different things. A company can technically tick every GDPR box and still process more of your data than you would prefer. Compliance is a floor, not a ceiling.

A note on scope: this article is general information, not legal advice. If you are a controller assessing your own compliance, or a journalist alleging that a specific company is non-compliant, that needs a lawyer.

Why health data is in a category of its own

Heart rate, sleep stages, weight, menstrual-cycle entries, blood-oxygen readings, recovery scores — these are not just "personal data" under GDPR. They are special category data under Article 9, which prohibits the processing of "data concerning health" unless one of ten exceptions applies. For a consumer wearable, the only realistic exception is the first one in Article 9(2): your explicit consent. That is a stricter standard than the ordinary "freely given, specific, informed and unambiguous" consent in Article 4(11). The European Data Protection Board's Guidelines 05/2020 on consent spell out what "explicit" means in practice: a separate, clearly worded affirmative action — typically a checkbox you tick yourself, with the purpose of the processing visible right next to it.

This is why most wearables ask you, separately from the main terms, to grant consent for health data. The architecture matters: if the policy bundles your health-data consent into a single "I accept the Terms" tickbox, that is not the explicit consent Article 9 requires. The EDPB has been clear that consent under GDPR must be granular and that pre-ticked boxes, inertia, or scrolling do not count.

The seven things to check before you install

What follows is a practical checklist you can run through in about ten minutes per policy. None of it requires legal training. All of it can be answered from the privacy policy text and the data-transfer section in particular.

1. Who is the data controller, and where are they established?

The first thing you want to find is the name and address of the EU controller. Companies headquartered outside the EU that target EU users usually have an EU subsidiary that is the controller for European users; that subsidiary is the entity you address GDPR requests to. Apple's Health app, for example, is controlled in the EEA, the UK and Switzerland by Apple Distribution International Limited in Ireland (Apple Privacy Policy, EEA controller statement). Fitbit's EU controller is Fitbit International Unlimited in Dublin (Fitbit Privacy Policy, "Your Data Controller"). Oura's controller for service data is Oura Health Oy in Finland (Oura Privacy Policy, "Controller contact information"). WHOOP states that it processes personal data in the United States (WHOOP Full Privacy Policy).

Why this matters: the address of the EU controller determines which national data protection authority handles complaints against the company under the "one-stop-shop" mechanism (for example, the Irish Data Protection Commission for Apple and Fitbit, the Finnish Data Protection Ombudsman for Oura). If a policy lists only a US address with no EU establishment named at all, that is a signal — not automatically a violation, but a structural difference that affects where you'd lodge a complaint.

2. What lawful basis are they using for your health data?

For ordinary personal data (your email, your account ID), there are six possible lawful bases in Article 6: consent, contract, legal obligation, vital interests, public task, and legitimate interests. For your health data, only the Article 9 exceptions are available, and in a consumer-wearable context the realistic one is explicit consent.

Read the "lawful basis" or "legal basis for processing" section. A solid policy distinguishes between the bases used for different categories of data. Oura, for example, separates the bases by purpose: contract for providing the service, consent for sensitive personal data, legitimate interest for marketing and product development, and legal obligation for tax and statutory record-keeping (Oura Privacy Policy, "Legal basis for processing"). Fitbit applies the same Article 9 logic: it asks for explicit consent when collecting health data, pegged to actions like pairing your device or enabling female health tracking (Fitbit Privacy Policy, "Health and Other Special Categories of Personal Data").

What to flag: a policy that names "legitimate interests" as the basis for processing health data is doing something that needs scrutiny. Legitimate interests is not, on its own, a valid Article 9 basis for health data.

3. Where does your data physically go, and under which transfer mechanism?

This is the single most informative section of any privacy policy. Chapter V of GDPR (Articles 44 to 49) restricts transfers of personal data to "third countries" outside the EEA. After the Court of Justice's Schrems II judgment in July 2020, transfers to the United States in particular need a specific legal mechanism plus, in many cases, supplementary measures. The European Data Protection Board's Recommendations 01/2020 describe how exporters should assess the legal environment of the destination country and add safeguards where the third-country law falls short of the EU standard.

There are three mechanisms you will commonly see in 2026:

• Adequacy decision. The European Commission has decided, under Article 45, that a specific country's data-protection laws are "essentially equivalent" to the EU's. The current US-relevant adequacy decision is Commission Implementing Decision (EU) 2023/1795 of 10 July 2023, under which transfers to US importers self-certified to the EU–US Data Privacy Framework are permitted. The DPF replaced the Privacy Shield invalidated by Schrems II. Note that the adequacy decision is itself subject to ongoing legal challenge; whether it survives long-term is a question for the Court of Justice.
• Standard Contractual Clauses (SCCs). Contractual terms approved by the Commission and signed between the data exporter and the data importer, committing the importer to EU-equivalent protections. Schrems II confirmed that SCCs are still a valid transfer tool but require a case-by-case assessment of the destination country's surveillance laws, plus supplementary technical and organisational measures where needed.
• Binding Corporate Rules (BCRs) for transfers within a corporate group.

You want a policy that names the mechanism. Apple states that for users in the EEA, the UK and Switzerland, "Apple's international transfer of such personal data is governed by Standard Contractual Clauses" (Apple Privacy Policy, EEA transfers). Fitbit lists adequacy decisions, the EU–US DPF (Fitbit LLC is DPF-certified through Google), and SCCs (Fitbit Privacy Policy, "Our International Operations and Data Transfers"). Oura's policy says EU users' data is "primarily transferred within the European Economic Area" and, where it leaves, Oura participates in the EU–US Data Privacy Framework and applies safeguards under applicable privacy laws (Oura Privacy Policy, "Legal frameworks for international transfers"). WHOOP states that it transfers personal data to the United States in accordance with European data protection laws and relies on Standard Contractual Clauses (WHOOP Full Privacy Policy).

What this section should let you answer: if my data goes to the United States, what mechanism is being used, and is the importer DPF-certified, signed up to SCCs, both, or unspecified?

4. Who are the processors and sub-processors?

Article 28 GDPR requires the controller to use only processors that provide "sufficient guarantees" of GDPR compliance, with a written contract that spells out the obligations. Reputable wearable companies publish a sub-processor list — the third-party companies (cloud providers, customer-support tools, analytics platforms, AI providers) that handle your data on the controller's behalf.

This is where the gap between "we comply with GDPR" and "we have read our own sub-processors' policies" tends to open. Look for:

• A named sub-processor list, or a clear pointer to one.
• The category of service each provides (cloud hosting, analytics, AI inference, support).
• The location where each operates.

A wearable that publishes a current sub-processor list is significantly more transparent than one that says only "we use trusted third-party service providers." Trust is not a transfer mechanism.

5. What rights are spelled out, and how do you actually exercise them?

Articles 15 to 22 give you a set of rights: access (Article 15), rectification (16), erasure (17), restriction (18), portability (20), objection (21), and rights related to automated decision-making (22). Articles 13 and 14 require the controller to tell you about these rights up front, in clear language. A policy that lists the rights but offers no operational path to exercise them is doing only half the job.

What to look for:

• A dedicated email or contact (often privacy@, dpo@, or dataprotection@) for GDPR requests.
• A self-serve export tool inside the app, particularly for portability.
• A self-serve deletion path that doesn't require you to dig through customer support.
• A defined response window (Article 12(3) says one month, extendable by two months for complex requests).

Oura, for example, names a DPO contact (dataprotection@ouraring.com), commits to a 45-day window for verifiable consumer requests, and points users to in-app and web tools for access, deletion and export (Oura Privacy Policy, "Your rights as a data subject"). Fitbit similarly publishes a DPO contact and links to self-serve export and deletion tools (Fitbit Privacy Policy, "Your Rights to Access and Control Your Personal Data").

6. Profiling, advertising, and AI training: opt-in or hidden?

Three uses sit in a grey zone where the policy text matters a lot more than the marketing:

• Profiling and advertising. Many health apps separate health data from advertising data. A policy that explicitly states health and wellness data is kept separate from advertising is a meaningful commitment — even so, it is worth checking independently how the company handles cookies and advertising identifiers on its website and in its SDK.
• AI and machine-learning training. Increasingly, health apps train models on aggregated or de-identified user data, or pass live data to a third-party large language model for features like coaching or summarisation. The policy should tell you whether your raw or derived health data is used to train models, whether that use is opt-in, and whether any external model providers can retain or train on your data. WHOOP's published privacy policy addresses this directly: its LLM partner operates under a "Zero-Retention/Zero-Training Policy," meaning the partner "will not store or retain any of your Personal Data nor use any WHOOP metrics for training any algorithms or LLM technology," and WHOOP "will only share de-identified WHOOP metrics" with that partner (WHOOP Full Privacy Policy, accessed 17 May 2026).
• Sale or "share" of personal data. Under GDPR the question is whether processing has a valid lawful basis — there is no special concept of "sale." But under US state laws (California's CCPA, Washington's My Health My Data Act) "sale" and "share" are defined terms, and a global privacy policy will usually disclose them. Wearables marketed in Europe almost universally say they do not sell personal data. If yours doesn't, that's a hard signal.

What to flag: any clause that lets the company use your data for "future product development," "research," or "personalised advertising" without a separate opt-in. Bundled consents do not meet the Article 9 standard for health data.

7. Retention, deletion, and what happens if you stop paying

Article 5(1)(e) requires that data is kept "for no longer than is necessary." The privacy policy should tell you, for each category of data, how long it's retained and what triggers deletion. Beyond the legal text, there are three practical questions:

• What happens when you delete the app? Are server-side records deleted, or only the local copy on your phone?
• What happens when you delete your account? Most policies cite a window (commonly 30 to 90 days) during which deletion propagates through backups.
• What happens if you cancel a subscription but don't delete the account? Some wearables keep your historical data behind a paywall — meaning the data is still there but you can't see it. That is not, by itself, a GDPR violation, but it's a fact worth knowing before you start a multi-year health timeline you may later be unable to read.

A real walk-through: four wearables compared

Below is what a fifteen-minute read of four current privacy policies surfaces. This is descriptive, based on each company's own published text as of May 2026. Use it as a model for how to read your own; not as a ranking.

Apple Health app

The Health app is built around on-device processing, and Apple states that when two-factor authentication is enabled, "Apple will not be able to read your health and activity data synced to iCloud" (Apple Health App & Privacy). For EU users, the controller is Apple Distribution International Limited in Ireland; international transfers are made under Standard Contractual Clauses (Apple Privacy Policy). Third-party apps that read or write to HealthKit must request access and have their own privacy policies, which the Health app surfaces. The data architecture pushes most processing to the device; the privacy policy reflects that.

Fitbit (Google)

Fitbit's EU controller is Fitbit International Unlimited in Dublin (Fitbit Privacy Policy). The policy distinguishes ordinary personal data (lawful basis: contract, legitimate interest, or consent depending on context) from special-category health data (lawful basis: explicit consent, obtained separately when you take an action that produces such data, like pairing a device). Transfers to the US rely on three mechanisms in parallel: adequacy decisions where relevant, the EU–US DPF (Fitbit LLC is certified through Google), and Standard Contractual Clauses. From June 2023 onwards Fitbit users have been able to move their accounts to Google; the policy describes a joint-controller arrangement between Fitbit and Google entities for the limited profile-sharing this requires. Fitbit states that it does not sell personal data — its policy reads verbatim: "We never sell the personal information of our users."

Oura

Oura's controller for service data is Oura Health Oy, a Finnish company, with Ouraring Inc. (San Francisco) as a co-controller for marketing-related processing (Oura Privacy Policy). The policy is explicit that EU users' personal data is "primarily transferred within the European Economic Area" and that, where data does leave, Oura participates in the EU–US Data Privacy Framework, the UK Extension, and the Swiss–US DPF, with safeguards under applicable privacy laws. Oura states that it does not sell or rent personal data and does not share Oura app data with third-party advertisers. Sensitive personal data is processed only with consent. The policy names a DPO at dataprotection@ouraring.com and commits to 45-day response windows for verifiable requests.

WHOOP

WHOOP's privacy policy states that WHOOP processes personal data in the United States and relies on Standard Contractual Clauses for transfers from the EU (WHOOP Full Privacy Policy). The policy describes sharing categories — service providers, certain third-party laboratory and clinical providers, law-enforcement requests where applicable, and successor entities in a business transfer. WHOOP's privacy policy describes its AI-feature handling in detail: de-identified WHOOP metrics are shared with an LLM partner under a "Zero-Retention/Zero-Training Policy," meaning the partner "will not store or retain any of your Personal Data nor use any WHOOP metrics for training any algorithms or LLM technology" (WHOOP Full Privacy Policy, accessed 17 May 2026).

What the four-way comparison shows is not who "wins." It shows that the four companies make different architectural choices — Apple leans on on-device processing, Oura emphasises EU hosting, Fitbit relies on a layered set of US-transfer mechanisms, WHOOP relies on SCCs — and that those choices are visible in the privacy policy if you read past the marketing language.

Common red flags

Five patterns turn up often enough to be worth naming.

1. No named EU controller. A policy that lists only a US address and does not name an EU establishment for EU users is structurally different from one that does.
2. One bundled consent for everything. If the only consent you give is "I accept the Terms," and there is no separate granular consent for processing your health data, that is below the Article 9 standard.
3. Vague transfer language. Phrases like "we may transfer data to servers around the world" without a named mechanism (adequacy decision, DPF, SCCs, BCRs) are not enough to evaluate.
4. "We use trusted third parties." No sub-processor list, no categories, no locations. This is the most common opacity pattern in mid-tier wearable apps.
5. A self-serve export tool but no deletion path. Article 17 isn't satisfied by a contact form that may or may not be answered. The policy should commit to a process and a timeline.

Common false reassurances

Three claims sound stronger than they are.

• "DPF-certified." Useful, but only relevant to US transfers, and only as long as the adequacy decision stands. It does not mean the company is otherwise GDPR compliant for the rest of its processing.
• "HIPAA-compliant." HIPAA is US healthcare-sector law. It does not apply to most consumer wearables, and being HIPAA-compliant — or claiming to be — says nothing about GDPR.
• "End-to-end encrypted." Strong technical security is a part of Article 32 (security of processing), but encryption protects data in transit and at rest. It does not, by itself, answer questions about lawful basis, transfers, profiling, or retention.

Where Sam Health fits in

Sam is a wellness app designed for people in Europe who want their health-tracking data to stay within an EU privacy regime. Sam is EU-hosted and built around the same checklist this article walks through: an EU controller, granular consent for any health-data processing, transparent processor disclosures, and a clear deletion path. Sam is a wellness app, not a medical device — it surfaces your own signals and patterns so you can have a richer conversation with the people who help you look after your health. Learn more about how Sam handles your data and the Sam product overview.

Try Sam Health

Sources

• Regulation (EU) 2016/679 (General Data Protection Regulation), consolidated text, EUR-Lex. URL: https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng. Accessed 15 May 2026.
• Judgment of the Court (Grand Chamber) of 16 July 2020 in Case C-311/18 (Schrems II), EUR-Lex. URL: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62018CJ0311. Accessed 15 May 2026.
• Commission Implementing Decision (EU) 2023/1795 of 10 July 2023 on the adequate level of protection of personal data under the EU–US Data Privacy Framework, EUR-Lex. URL: https://eur-lex.europa.eu/eli/dec_impl/2023/1795/oj/eng. Accessed 15 May 2026.
• EDPB, "Guidelines 05/2020 on consent under Regulation 2016/679," European Data Protection Board, 4 May 2020. URL: https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en. Accessed 15 May 2026.
• EDPB, "Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data," 18 June 2021. URL: https://www.edpb.europa.eu/our-work-tools/our-documents/recommendations/recommendations-012020-measures-supplement-transfer_en. Accessed 15 May 2026.
• Apple, "Health App & Privacy," Apple Legal. URL: https://www.apple.com/legal/privacy/data/en/health-app/. Last updated 11 February 2026. Accessed 15 May 2026.
• Apple, "Privacy Policy," Apple Legal. URL: https://www.apple.com/legal/privacy/en-ww/. Accessed 15 May 2026.
• Fitbit (Google), "Fitbit Privacy Policy," Google Product Documentation. URL: https://support.google.com/product-documentation/answer/14815921?hl=en. Last updated 27 February 2026. Accessed 15 May 2026.
• Oura, "Oura Health Privacy Policy." URL: https://ouraring.com/privacy-policy. Dated 20 April 2026. Accessed 15 May 2026.
• WHOOP, "Full Privacy Policy." URL: https://www.whoop.com/us/en/full-privacy-policy/. Accessed 15 May 2026.