--- title: "Sub-processors: Who Can Reach Your Data" description: "Who can reach your users' wearable data when you run Open Wearables yourself, and when Momentum supports it under a DPA you sign." canonical_url: "https://openwearables.io/sub-processors" --- # Who can reach your data, in each model. Sub-processors 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. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) 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. [See Pro and Enterprise](https://openwearables.io/pricing#pro) 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. ### [Security](https://openwearables.io/security) ### [What we sign](https://openwearables.io/what-we-sign) ### [Data residency](https://openwearables.io/data-residency) ### [Data governance](https://openwearables.io/data-governance) ## 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. [Book a demo](https://openwearables.io/book) 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](https://openwearables.io/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.