Privacy policy checklist for activity data services
What the privacy policy of a service that collects or receives sports and activity data needs to cover. Beyond the general requirements of the GDPR, it covers the statements that the platforms you connect to require, health and menstrual cycle data, the age of your users, location data and the US health privacy laws that apply to many activity apps.
Most items are based on European law, which applies to any company with users in the European Union, wherever it is established. Where US law adds requirements, the item says so. We treat European law as good practice written into law, so the same items are worth following where it does not bind you. Each item names its source, so you can see which apply to you by law. Why we build on European law.
Platforms change their terms regularly, so always check the version that applies to you.
Founding phase
Our guidance is a working draft, published early so you can put it to use while it matures. It becomes final after review by our members and legal experts. Until then, use it to prepare, not as legal advice.
Before you write: determine your role
The GDPR distinguishes between controllers and processors. Your role determines whose privacy policy must cover the data, and who must ask athletes for consent. It follows from what your company actually does, not from what a contract calls it, and a company can have both roles for different data.
- Controller
- Decides why and how data is processed. The controller needs a privacy policy, a legal basis and, for health data, the athlete's consent, and handles athletes' requests. An app that athletes use directly is normally a controller.
- Processor
- Processes data only on behalf of a controller and on its instructions, such as a hosting, email or AI provider. A processor needs a data processing agreement with each controller and must list its own sub-processors. It does not need its own privacy policy for that data, but must help the controller meet its obligations.
- Joint controllers
- Two companies that decide together on the purposes of processing, for example a co-branded feature. They must agree who handles which obligations, and make the essence of that arrangement available to athletes.
- Data platforms and intermediaries
- A service that retrieves data from other platforms and delivers it to applications through its own API is usually a processor for the applications that use it, and a controller for its own purposes, such as athlete accounts, billing and its own analytics. It is also the party that accepted the source platforms' developer terms, so items 3 and 4 apply to it in full. The applications using it are controllers, and their privacy policies must name the original source platforms.
- Software that reads data directly from devices
- If your software processes data only on the athlete's own device and your company never receives it, you are generally not a controller of that data and need no privacy policy for it. Once data reaches your company, including through analytics, crash reports or cloud synchronisation, you are, and this checklist applies in full.
Map your data
A privacy policy describes what you actually do. Most errors arise because the policy was written before anyone listed what the service does. Before writing, list the following. A spreadsheet is sufficient, and it doubles as your record of processing activities.
- Sources
- Every way data enters your service: the athlete, your own app's sensors, uploaded files, and each platform you connect to, such as Garmin, Strava, Apple Health, Health Connect, Polar, Wahoo, Oura or WHOOP.
- Data types
- Per source, the data you receive: activities, GPS tracks, heart rate, heart rate variability, sleep, weight, menstrual cycle, notes. Mark which reveal information about health.
- Purposes
- Everything you do with the data, including analytics, marketing, support, AI features and model training.
- Recipients
- Every supplier and partner that receives data, including hosting, email, analytics, crash reporting, AI providers and any business customers you pass data to.
- Platform terms
- The developer terms you accepted for each source, with their date. Several of the items below depend on them.
What your privacy policy must cover
Items 1 and 5–11 follow from legislation. Items 2–4 follow from both legislation and the developer terms of the platforms you connect to, which apply to you as a contract.
-
The GDPR lists the information a privacy policy must contain. Leaving out an element is a breach in itself, even if you handle data well.
How to do this
- your company's identity and contact details, and those of your data protection officer if you have one;
- each purpose and its legal basis, and the legitimate interests you rely on, if any;
- the recipients or categories of recipients;
- transfers outside the European Economic Area, and the safeguard used for each;
- how long you keep each category of data, or the criteria you use;
- athletes' rights, the right to withdraw consent at any time, and the right to complain to a supervisory authority;
- whether providing data is required, and the consequences of not providing it;
- any automated decision-making with legal or similarly significant effects, and the logic involved.
Common mistake: copying a template from another type of business. A template for a web shop does not mention health data, connected platforms or sensor data, which are central to an activity data service.
-
Where data comes from another source, the GDPR requires you to state the source and the categories of data. Apple, Strava, Polar, Google and Oura also require it in their developer terms.
How to do this
- For each platform, list the data types you request, using the scopes or permissions you actually ask for.
- Explain how the athlete connects and disconnects the platform, and what happens to the data when they do.
- Keep the list in a table, so that it can be updated when you add an integration.
Model text: connected services Data from services you connect
When you connect another service to [Service], we receive data from it on your behalf. We only receive the data listed below, and only for as long as the connection is active.
Garmin Connect: activities, including GPS tracks, heart rate and power; daily heart rate; sleep. Apple Health: workouts, heart rate, heart rate variability, sleep, body weight.
You can disconnect a service at any time under Settings › Connections. We then stop receiving data from it and delete the data we received from it within [48 hours].
Note: it is not settled whether data an athlete imports through a connection counts as collected from the athlete or from another source. Naming each source and the data received meets both readings.
-
Most platforms set conditions on the privacy policy of every service that uses their API. These obligations cascade: by accepting a platform's terms, you take them on, and your own privacy policy must reflect them. They also limit what you can promise athletes elsewhere in the policy.
How to do this
Read the developer terms of each platform you connect to and list every requirement that affects your privacy policy. The table shows examples from published terms, checked in October 2026. It is not complete and terms change, so check the current version yourself.
Examples of requirements that affect your privacy policy Platform What your privacy policy must contain Conditions that limit what you may say or do Garmin Connect Developer Program A conspicuous AI transparency statement explaining the nature and purpose of any AI processing of Garmin data. Explicit consent from each athlete before AI processing, which they can easily withdraw. Data may only be passed to third parties Garmin has approved. Strava API A lawful privacy policy, and a statement that Strava may collect and use usage data about your application. No use in AI applications, including sending data to a language model. Data may only be shown to the athlete it belongs to. Deletion within 30 days of disconnection. Apple HealthKit The specific health data you collect, how you use it, and how athletes can withdraw consent and request deletion. No use for advertising or data mining. Explicit permission before sharing with third parties, including third-party AI. No health information in iCloud. Google Health Connect and Google Health API Data types, use, sharing, retention and deletion. A statement that your use complies with Google's Limited Use requirements. A prominent disclosure in the app itself, not only in the policy. No advertising, sale or credit decisions. Oura and WHOOP A privacy policy covering collection, use, sharing, retention and deletion. No training of AI models. Data shown only to the athlete unless they agree otherwise. Oura: deletion within 72 hours of a request. Polar and Wahoo Which data you retrieve and store. Polar: credit Polar as the source. Explicit authorisation from the athlete. Wahoo: data visible only to the athlete, deletion within 48 hours of Wahoo's request. Common mistake: a single statement about AI or sharing for the whole service, when one connected platform allows it and another prohibits it. Where requirements differ, describe them per source, and build the product to match (see the guide to AI and athlete data).
Tip: keep a record of the terms you accepted and their date, as described in item 15 of the checklist for early-stage companies. Platforms can change their terms unilaterally, often with continued use counting as acceptance.
-
When you pass data to a supplier or a business customer, the platform's conditions travel with it. Most platform terms require you to bind recipients to protections that are no less strict, and some do not allow passing data on at all. Your privacy policy may only list recipients that are actually permitted.
How to do this
- For each recipient, check per source platform whether passing the data on is permitted, and under which conditions.
- Include the platform's restrictions in your data processing agreements and customer contracts, for example no model training, no advertising and deletion on disconnection.
- When an athlete disconnects a platform, make sure recipients delete the data too, within the same period.
- List recipients in your privacy policy accurately, by name or by category.
If you provide data to other businesses: check this item first. Several platforms do not allow their data to be passed through an intermediary or exposed through your own API without their written approval. Strava's terms prohibit it outright.
-
Data from which conclusions about health can be drawn is health data, even if it is collected for sport. It may only be processed with explicit consent, which must be specific to each purpose. Your privacy policy must name each category of health data and each purpose.
How to do this
- Treat heart rate, heart rate variability, sleep, body weight, VO2max, recovery scores, illness and injury notes, and menstrual cycle, fertility and pregnancy data as health data.
- Name these categories in the policy. A general statement that you "may process health data" is not sufficient.
- Ask for explicit consent with a separate, unticked choice in the app, per purpose, before you start processing. Do not bundle it with acceptance of your terms.
- Explain in the policy how athletes withdraw consent, and what happens to their data when they do.
Note: the Court of Justice of the EU interprets health data broadly, including data from which health can be inferred indirectly. Changes to this definition have been proposed in the EU, but were not adopted in October 2026.
-
Cycle tracking is common in training apps, and is among the most sensitive data an app can hold. In the United States, reproductive health data is subject to specific state laws, and the enforcement against period-tracking apps has been among the most significant in the industry.
How to do this
- Ask for cycle data with its own consent, separate from other health data, explaining what it is used for.
- Never send cycle, fertility or pregnancy events to advertising or analytics tools. Check what your software development kits send automatically (item 9).
- Do not use cycle data for marketing, including advertising for fertility products.
- Do not share it with anyone for their own purposes. State this explicitly in the policy.
- Consider storing it with additional protection, and allowing athletes to delete it separately from their account.
- If you have users in the United States, publish a consumer health data policy (item 7) and do not use location-based advertising near health care facilities.
Model text: cycle data Menstrual cycle data
If you choose to log your menstrual cycle, we use it only to adjust your training plan and to show your cycle alongside your training. We do not use it for advertising, we do not share it with anyone for their own purposes, and we never sell it. You can delete your cycle data at any time under Settings › Health data, without deleting your account.
Background: in 2021 the US Federal Trade Commission took action against a period-tracking app that had shared data with Facebook and Google contrary to its privacy policy. In 2025 a US jury found Meta liable for collecting data from that app through its software development kit.
-
Washington's My Health My Data Act covers data about bodily functions and vital signs, which includes most wearable data. It requires a separate consumer health data privacy policy, linked prominently from your homepage. Nevada and Connecticut have similar rules, and other states treat health and precise location data as sensitive.
How to do this
- Publish a consumer health data privacy policy as a separate page, and link it from your homepage.
- Obtain consent before collecting consumer health data, unless it is necessary to provide the service the user requested.
- Obtain a separate consent before sharing it. Selling it requires a signed authorisation, which expires after one year.
- Do not set up geofences around health care facilities, for example for advertising.
- Check whether the Health Breach Notification Rule applies to you. It covers health and fitness apps that combine data from several sources, such as a wearable and the user's own input. Sharing health data without authorisation counts as a breach that must be notified.
Note: Washington's law gives individuals the right to sue. US state privacy law changes quickly; ask a US lawyer which states' laws apply to your service.
-
Where you rely on consent, children below the age set in their country need a parent's consent, and you must make reasonable efforts to verify it. The age differs per country, from 13 to 16. In the United States, collecting data from children under 13 is subject to COPPA.
How to do this
- Decide whether your service is intended for children. Youth sport is common, so make a deliberate choice.
- Ask for date of birth at sign-up, neutrally, without suggesting an answer or revealing the threshold.
- Apply the age that applies in the athlete's country. Below it, either refuse the account or use a parental consent flow.
- State the minimum age in your privacy policy and terms. If you learn that a user is below it, delete their data.
- Do not use advertising tools for accounts of minors.
Age of digital consent, as reported in October 2026 Age Countries 13 Belgium, Denmark, Estonia, Finland, Latvia, Malta, Portugal, Sweden; Iceland, Norway; United Kingdom 14 Austria, Bulgaria, Cyprus, Italy, Lithuania, Spain 15 Czechia, France, Greece, Slovenia 16 Croatia, Germany, Hungary, Ireland, Luxembourg, Netherlands, Poland, Romania, Slovakia; Liechtenstein Note: confirm the age in national law for the countries where you operate. Spain has proposed raising its age to 16. Under COPPA, the amended rule has applied since April 2026, and applies where your service is directed at children or you know a user is under 13.
-
Analytics, crash reporting and advertising kits in your app may collect data without anyone noticing. Accessing a device requires consent unless it is strictly necessary. Your privacy policy, Apple's privacy label and Google Play's data safety form must describe the same practices.
How to do this
- List every kit in your app and website, what it collects, and where it sends data.
- Configure kits so that they do not receive health data, location or cycle data, including through event names such as "period_logged".
- Ask for consent before loading kits that are not strictly necessary.
- Compare your privacy policy with your App Store privacy label and Google Play data safety form at every release.
Common mistake: an analytics event that reveals health information. Regulators in the United States and Europe have treated this as unauthorised disclosure.
-
State which features use AI, which data they use, which providers process it, and whether you train models on athletes' data. Some platforms require a specific AI transparency statement, and an AI chat feature must make clear that the athlete is talking to an AI.
How to do this
The guide to AI and athlete data explains what you may do, how to ask for consent, and what an AI transparency statement contains.
-
A company outside the European Union that offers its service to people in the EU must appoint a representative in the EU in writing and name it in the privacy policy. The exemption for occasional processing does not apply to health data processed at scale. The United Kingdom has an equivalent requirement.
What makes a privacy policy work in practice
These practices go beyond the legal minimum. They make your policy easier to read and easier to keep accurate.
-
Show a short explanation when an athlete connects a platform, enables a feature or logs sensitive data, with a link to the relevant section of the full policy.
-
Platforms set different deletion periods, ranging from 48 hours to 30 days. A single period of 48 to 72 hours after disconnection or a deletion request meets them all, and is easy to explain.
-
Show the date of the current version, keep earlier versions available, and tell athletes in the app what changed. Where a change requires new consent, ask for it.
-
Add a review of the privacy policy, store labels and consent texts to your release checklist whenever you add a data source, a purpose, a supplier or a country.
Working with a lawyer
A review is faster and less expensive when you arrive prepared. Bring the following:
- your data map or record of processing activities, as described at the top of this page;
- the developer terms of each platform you connect to, with the version you accepted;
- screenshots of your sign-up, consent and connection screens;
- your list of suppliers and software development kits;
- the countries where you offer your service.
Ask in particular for advice on the questions that require legal judgement: whether your data is health data, which countries' laws apply, whether you need an impact assessment, and how to handle requirements of platform terms that conflict with each other or with the law.
Further guidance
See also the checklist for early-stage companies, the terms and conditions checklist and the guide to AI and athlete data. Questions and suggestions are welcome at hello@opensportsdata.org.