Guide · 8 min read
DPDP and health data in India: what it means for your wearable integration
What India's DPDP Act means for wearable and health data: consent, purpose limitation, data principal rights, breach duties and how to design for them.
Published · Updated · By the WearLink engineering team
If you are building a health product for Indian users and pulling data from Oura, WHOOP, Fitbit or Apple Health, you have a data-protection question to answer before you have a scaling question. The Digital Personal Data Protection Act 2023 applies to the wearable data you are collecting, and sleep, heart rate, glucose and body composition are health data by any reading of it.
Most teams discover this late, usually when an enterprise customer or a hospital partner sends a security questionnaire. By then the architecture is set and the wearable aggregator is a foreign-hosted SaaS, which makes the honest answer to “where does this data live?” an uncomfortable one.
What DPDP actually asks of you
Three obligations dominate the engineering conversation. The first is consent. DPDP requires consent that is free, specific, informed, unconditional and unambiguous, given by clear affirmative action and tied to a stated purpose. In practice that rules out bundling “we will read your health data” into a general terms checkbox at signup. It has to be a distinct, purpose-bound choice, and it has to be as easy to withdraw as it was to give, which means a working revocation path, not an email address.
The second is purpose limitation. You may process the data for the purpose the user consented to and not for adjacent things you thought of later. Training a model on aggregate user health data is a different purpose from showing a user their own sleep trend, and consent for one is not consent for the other.
The third, the one that determines your architecture, is where the data sits. Health data on Indian residents is widely expected to be held on infrastructure within India. The precise contours continue to be shaped by rules and sectoral regulators, but in-India storage is the defensible default, and it is the answer that gets through a procurement review without a six-week legal detour.
Why this is a problem with most wearable APIs
The major wearable aggregators are US or EU hosted. Terra, ROOK and Junction run their infrastructure outside India. If you route your Indian users’ sleep and glucose data through one of them, that data leaves the country as a matter of ordinary operation, and the burden shifts to you to justify the transfer, document the consent basis and satisfy whatever sectoral rules apply to your category.
This is not a reason those vendors are bad. For a US-market product they are excellent choices. It is a reason that a compliance requirement specific to your market may not be satisfiable by a vendor that does not serve that market as a priority.
The trap is that this rarely blocks you early. It blocks you at the exact moment you are trying to close a hospital, an insurer or a corporate wellness contract, the customers who read the questionnaire.
What to check before you pick an aggregator
Five questions, all of which a vendor should be able to answer in writing:
- Where is the data physically stored, and can you name the region? "The cloud" is not an answer.
- Does any processing, backup or log shipping cross a border? Backups and observability pipelines leak data out of a region more often than the primary datastore does.
- Can you configure retention per tenant, and can you prove deletion actually happened?
- Is there an audit log of privileged access, and can you export it? A questionnaire will ask.
- What is the sub-processor list, and how are you notified when it changes?
How WearLink answers those questions today
Plainly, because the previous version of this page got it wrong. WearLink runs on isolated single-tenant infrastructure with Asia-Pacific (Malaysia) data residency. That is outside India. For the purposes of the residency question above, WearLink is a foreign-hosted vendor like the others, and sending Indian residents’ health data through it is a cross-border transfer that you would need to justify in the same way.
What WearLink does offer against the checklist: a named hosting region rather than “the cloud”; a single-tenant host with export files on a separate self-hosted object store, so there is no hyperscaler backup pipeline quietly replicating across regions; an append-only audit log of privileged actions exportable as NDJSON in one request; per-user export and hard deletion; EXIF GPS stripped from meal photos before storage; and a sub-processor list published in the privacy policy. In-India hosting can be discussed for Enterprise deployments; it is not a self-serve option.
What WearLink does not have is a SOC 2 Type II report or any other attestation. If your buyer requires one, we cannot satisfy that today, and we would rather tell you now than during procurement.