Buy a wearable API and you become the controller. Did you mean to?
Wearable integrations look like a connector problem. They turn out to be a controllership problem, and the contract usually settles it in one line that nobody reads until the security review.
- Aggregator contracts typically make you the controller and the vendor your processor.
- That makes you responsible for the lawful basis, the DPIA, subject access, deletion, and your processor’s compliance.
- The role follows the facts. A contract calling you a processor does not make you one.
- There is one shape where none of this lands on you: the end-user consents to the vendor directly.
Not legal advice. This is a summary for someone making a decision without a lawyer in the room. Your own counsel and your regulator have the final word.
This is not hypothetical. A leading wearable aggregator’s published data processing agreement states it plainly:
“Customer is the Controller, and Vendor is the Processor or Service Provider.”
Terra, Data Processing Agreement, as published. Their model is not unusual — it is the category standard, and it is a reasonable way to build an aggregator. The point is that most buyers do not notice they are agreeing to it.
Then the regulator attaches the heavy end to whoever that is. A controller determines the purposes and means, and is responsible for the compliance of its processors. And status follows substance: organisations determining purposes and means are controllers regardless of how a contract describes them.
| Obligation | What it means here |
|---|---|
| Lawful basis | An Article 6 basis and an Article 9 condition, because this is health data |
| DPIA | The ICO lists health and fitness monitoring, data matching from multiple sources, and processing not obtained directly from the person. A wearable integration hits all three |
| Transparency | Your privacy notice has to cover special category health data |
| Individual rights | Access, deletion and portability requests land on you, for readings you did not generate |
| Retention | You decide and defend how long readings are kept |
| Breach | Your notification, including for your processor’s breach |
| Security review | Health data in your estate changes the scope of every questionnaire you answer |
None of that is unreasonable. It is simply a different project from the one most teams scope when they estimate "add wearable support".
| Shape | Controller | What you sign | What you hold |
|---|---|---|---|
| You collect, vendor stores | You | A DPA with the vendor | Readings, and every obligation above |
| End-user connects to the vendor | The vendor, for the health data | A services agreement | The output only |
| Joint | Both | A joint-controller arrangement | Shared duties, and the hardest to explain to a reviewer |
The second is lighter for one reason: no readings in your database means nothing to produce on a subject access request, nothing in your security review, and nothing to notify about.
End-users authenticate their wearable directly with us and consent to our processing. We are a controller in our own right, not your processor. You receive ranked product identifiers, a confidence indicator and a short non-clinical reason. No readings, no scores.
The honest caveat: if your implementation involves sending us end-user personal data, the analysis changes and a processing agreement is needed. Say so at design stage. It is far easier to resolve then than at contract.
Can we just sign a DPA to be safe?
A DPA where there is no processor relationship does not create one, and it confuses a reviewer looking at the facts. Establish the shape, then sign the matching instrument.
Are we joint controllers with Humotron?
Not in the standard integration. We determine purposes and means for the end-user health data; you do for the recommendation output once it reaches your product.
Can we store the recommendations?
Yes — that output is yours and your privacy notice applies. What is prohibited is attempting to re-identify end-users or infer health status from recommendation patterns.
Where is data processed?
We aim to host in the UK and EU. Where a provider processes outside, we use the UK IDTA or equivalent standard contractual clauses. Sub-processor list on request.