.png)
The question looks simple. In practice, it is one of the more consequential compliance questions facing digital health companies, insurers, and research platforms working with wearable data today. Get it wrong, and you are either processing special category health data without the legal basis required to do so, or you are applying restrictions to data that does not require them. Neither is a good position.
The honest answer is: it depends. Whether wearable data constitutes special category data under GDPR is not determined by the device that generated it. It is determined by what the data reveals, what it can be used to infer, and the context in which it is being processed. Understanding that distinction matters for anyone building products or programs on wearable data in the European market.
Article 9 of the GDPR identifies specific categories of personal data that carry heightened protection because of the sensitivity of the information they contain or the risks their processing poses to individuals. These include genetic data, biometric data processed for the purpose of uniquely identifying a person, and health data.
Health data is defined in Article 4(15) as personal data related to the physical or mental health of a natural person, including the provision of healthcare services, which reveals information about their health status.
The implications of a dataset falling under Article 9 are significant. Processing special category data is prohibited by default unless one of the specific conditions in Article 9(2) applies. In practice, most digital health applications rely on explicit consent from the data subject, under Article 9(2)(a), as their processing condition. This is a stricter standard than the ordinary lawful bases available under Article 6: the consent must be specific, informed, unambiguous, and freely given, and it must explicitly reference the health data processing in question.
A platform that collects wearable data without correctly identifying whether that data falls under Article 9 may be processing special category data without the required legal basis without knowing it.
Modern wearable devices generate two types of output: raw sensor data and derived metrics.
Raw sensor data comes directly from the device hardware: accelerometer readings that capture movement and orientation, photoplethysmography signals used to derive heart rate, gyroscope data, and in newer devices, electrical signals for ECG and optical sensors for blood oxygen estimation.
Derived metrics are the numbers users see in their apps: step counts, resting heart rate, heart rate variability, sleep stages and duration, blood oxygen saturation, skin temperature trends, calorie estimates, and on medical-grade devices, blood pressure readings and ECG interpretations.
The critical observation is that these metrics sit at different points on a spectrum. Some are unambiguously health-related by any reasonable definition. An ECG reading or a blood pressure value is clinical data. But where does a daily step count sit? Or a sleep duration? Or a resting heart rate trend observed over three months?
Not all wearable data is health data by default. The GDPR definition is context-dependent, not category-dependent. Three factors determine whether a given wearable metric should be treated as special category health data.
Some metrics are inherently health-related regardless of how they are used. ECG data, blood oxygen saturation, blood pressure readings, and HRV measurements directly concern physiological function. A strong argument can be made that these are health data in any processing context.
This is where the analysis becomes more complex. Step counts, sleep duration, and resting heart rate are individually more ambiguous. But they are not neutral. A persistent decline in step count combined with elevated resting heart rate over several weeks is a meaningful cardiovascular signal. Disrupted sleep patterns may indicate a mental health condition, a chronic illness, or recovery from an acute event. The capacity of a metric to reveal health status does not depend on whether it was labeled as health data when collected.
The same step count data processed to power a fitness leaderboard occupies a different regulatory position than the same data processed to assess mobility decline in an older adult or to inform a health insurer's risk model. Purpose matters. A platform that collects step data for wellness purposes and then uses it to draw conclusions about a user's health status has likely crossed into special category territory, regardless of how the data was originally characterized.
The challenge that most organizations underestimate is that combining individually innocuous signals can produce outputs that are clearly health data, even when no single input would qualify on its own.
The European Data Protection Board has been explicit on this point. Data that allows conclusions to be drawn about a person's health status falls under Article 9, regardless of whether it was collected with that purpose in mind. The EDPB's guidance on connected devices confirms that health data includes data that can reasonably be used to reveal health information, not only data explicitly framed as medical.
This matters in practice because many wearable data platforms aggregate signals precisely to generate health insights. A platform that combines sleep quality, HRV, resting heart rate, and activity levels to produce a wellness score or a risk indicator is generating health data at the output level, even if each input metric might be characterized as non-health data in isolation. The legal basis needed to collect each metric does not automatically cover the processing required to combine them into a health inference.
European data protection authorities have consistently interpreted the definition of health data broadly when wearable and fitness data is concerned.
The EDPB's Opinion 04/2022 on the use of personal data for connected devices and wearable technology clarified that fitness data processed in a health-relevant context should be treated as health data under Article 9, even where no explicit medical claim is made. The opinion reinforced the position that the capacity to reveal health status is the operative test, not the intent of the data collector.
National DPAs have followed this direction. German authorities apply a conservative interpretation that treats biometric health metrics as special category data when processed by health-adjacent organizations. The CNIL in France has taken a similar position on fitness data used in contexts where health conclusions can be drawn. The trend across European jurisdictions is toward a broad interpretation of what constitutes health data, not a narrow one.
Organizations that have assumed wearable data falls outside Article 9 because it comes from a consumer fitness device rather than a clinical system are operating on a premise that regulators have repeatedly challenged.
For digital health companies, insurers, and research platforms processing wearable data, the practical implication is straightforward: the safer and more defensible assumption is that wearable health metrics are special category data, and processing should be structured accordingly.
In practice, this requires:
Purpose limitation deserves particular attention. A platform that collects wearable data for one purpose cannot silently repurpose it for another. Data gathered under a wellness consent cannot be fed into a clinical risk model or shared with an insurer without a separate, explicit legal basis covering that use.
At Thryve, we build wearable data infrastructure on the assumption that health metrics are special category data. This is the defensible position, and it is the one that protects the organizations building on our platform.
Our infrastructure includes:
If you are building digital health products that process wearable data and want to understand how your data infrastructure maps to GDPR requirements, book a demo with Thryve.
Friedrich Lämmel is CEO of Thryve, the plug & play API to access and understand 24/7 health data from wearables and medical trackers. Prior to Thryve, he built eCommerce platforms with billions of turnover and worked and lived in several countries in Europe and beyond.
.png)
.png)