DPDP Compliance for Wearables and Health-Tracking Devices
A wearable collects health signals continuously, syncs them to a companion app, and often forwards a subset to third-party analytics — three links, three sets of duties.
Continuous collection, not a single data point
A fitness or health-tracking wearable collects data essentially continuously — heart rate, sleep stages, step count, sometimes blood oxygen or ECG readings — which is a materially different notice and consent proposition than an app that collects data at discrete moments a user actively chooses. The notice at device setup should reflect that scale honestly: naming the categories of biometric signal collected and roughly how continuously, rather than a generic “we collect health data to improve your experience” line.
Because the DPDP Act does not create a separate legal tier for health data, the lawful basis here is the same consent-or-legitimate-use framework as any other personal data — but the practical sensitivity argues for treating security safeguards and breach response for this data with the same urgency a platform would apply if a distinct sensitive-data tier did exist.
Companion apps and cloud sync widen the data's reach
Most wearables pair with a companion phone app that syncs data to a cloud backend for historical trend charts, and that cloud store is where most of the meaningful data-protection risk actually sits, since the device itself typically holds only a rolling local buffer. Users should be told plainly whether their health data is processed only on-device, synced to the manufacturer's own cloud, or additionally shared with a connected fitness or insurance-wellness programme they've opted into separately.
Where a wearable maker partners with an insurer or employer wellness programme to offer premium discounts or rewards for hitting activity targets, that data-sharing arrangement needs its own explicit, specific consent, distinct from the base consent for using the device — a user tracking their steps for personal interest has not automatically agreed to their employer seeing that data.
Third-party SDKs and the accuracy of health-adjacent decisions
Analytics and crash-reporting SDKs embedded in the companion app can incidentally capture health-metric data alongside ordinary app telemetry if the integration is not carefully scoped, so a genuine audit of exactly what each embedded SDK receives is worth doing rather than assuming a general-purpose analytics tool is health-data-blind by default. Any such SDK provider is a processor under Section 8(2) at minimum, and the contract should explicitly restrict use of any health-adjacent data it happens to receive.
Where wearable data feeds a decision — an insurance premium adjustment, an employer wellness bonus, a clinician's remote monitoring dashboard — the Section 8(3) accuracy obligation applies, and a user should have a way to flag an obviously wrong reading (a device malfunction inflating a heart-rate spike, say) before it becomes the basis for a real-world consequence.
Where to go next
The Data Flow Mapper is a natural fit for tracing exactly how a health signal moves from the device, through the companion app, into cloud storage, and out to any connected wellness or insurance partner. Pair it with a Vendor Assessment of every embedded analytics SDK to confirm none of them are receiving more than they should.