Who can reach your data, in each model.
Open Wearables runs in your cloud account, under your credentials. When you run it, we have no access. When we work on your system, we do it under a DPA you sign, and we name the sub-processors we use for that access.
Two models, two answers
It depends on who runs the deployment.
If you run it yourself
We are not in the data path. You deploy from the repository into your own cloud account, under your credentials. We have no access, no tenant and no copy of the data.
If we support or maintain it
The deployment still sits in your account. Our people reach it under a DPA you sign: we act as your processor, on your instructions, and we list the sub-processors we use for that access. Where you process for your own customers, we appear on their list too.
In both models
What stays true either way.
The wearable data stays in one place
It goes from the provider or the phone into your deployment, and out through your own API. Nothing about that path involves a service holding a copy on the way.
Your cloud provider is not something we introduced
AWS, Azure or Google Cloud is your contract, in your account, chosen by you. We do not sit between you and them, which is usually the difference between a short answer in a governance review and a long one.
The sub-processors we use, where we work on it
What we can reach, and the sub-processors we use to do it, are set out in the DPA you sign. Ask and we will send the list with the agreement.
In your customer's review
Who can reach the data, by how you add wearable data.
The same question your customer's governance review asks, answered for each way of adding wearable data to your product.
| Hosted wearable API | Build it in-house | Open Wearables | |
|---|---|---|---|
| [01] Who holds the wearable data | The vendor, in its tenant | You | You, in your own cloud account |
| [02] Who can reach the data | The vendor and its sub-processors | Your team | Your team, and us under a DPA you sign when we work on it |
| [03] Where access shows up | In the vendor's reports | In your own logs | In your own logs |
For your own answer
What to send your customer.
Somebody asked you first. These sentences usually end the conversation.
The wearable data stays in our own cloud account.
It is deployed inside our infrastructure rather than called as a hosted service, so there is no vendor tenant between the device and our systems.
- No vendor tenant
No copy of member data leaves our account.
Nothing in the path keeps a copy elsewhere. The platform runs in our own cloud account, under our own credentials.
- No copy elsewhere
Where the vendor works on it, their access is under a DPA we signed.
It happens in our account, under our instructions, and shows in our own logs. The vendor acts as our processor and names the sub-processors it uses for that access.
- Under a DPA
What is not here
What is never in the path.
No analytics on health data
Nothing samples or profiles your users' health data as it flows through your deployment.
No shared infrastructure
Deployments do not share a database, a queue or a cache with each other or with us.
No model provider in the path
Where you use the MCP server, the assistant you point at it is your choice and your contract. We are not between you and it.
Related
The rest of the review.
Send us the questionnaire
If your customer's security review has landed and sub-processors are the question, bring us the clause. We will answer it for the way you run Open Wearables.
FAQ
Common questions.
Our customer's security review asks about sub-processors. What do we say?
That it runs in your cloud account, under your credentials, so wearable data does not reach a vendor tenant. When we work on your system, we do it under a DPA you sign, as your processor, with access to your deployment rather than a copy of the data, and we name the sub-processors we use for that access.
Are you a processor or a sub-processor?
Neither, where you run it yourself. Where we support or maintain it, we are your processor under a DPA you sign. If you process the data on behalf of your own customers, that also makes us a sub-processor in their chain. What we sign has the agreements.
Does any of your tooling touch our users' health data?
Where you run it yourself, we have no access at all. Where we work on it, what we can reach and the sub-processors we use are set out in the DPA you sign.
What about our cloud provider?
That contract is yours, in your account, with a provider you chose. We do not sit between you and them.
Our governance board has to approve every sub-processor. Does this work?
Yes. The data stays in your estate, so there is no aggregator holding it. Where we support or maintain the deployment, your board reviews us as a processor under a DPA, together with the sub-processors we use for that access.
Can we get this in a signed document rather than a web page?
Yes. The DPA you sign with us covers it, including the sub-processors we use.