Who controls the data, who can reach it. In writing.
Most health data governance questions are settled by where the deployment runs: your cloud account, under your credentials. This page is the rest: what we can reach, and what happens when you leave.
Data ownership
The deployment is yours, and so is what leaves it.
The account is yours
Open Wearables runs in your cloud account under your own credentials. There is no tenant of ours holding a copy, in either operating model.
Provider apps in your name
Garmin, Oura, Whoop and the rest are registered to you, so the relationship with each provider is yours rather than sublet from us.
Leaving changes nothing
If you stop working with us, the deployment and the data stay where they are. There is no export to request and no window to act inside.
What you build is yours
Your data model, your pipeline and your own logic run on MIT-licensed open source in your account.
Data processing
You are the controller. Here is what that means for us.
We are not in the picture: no access, no processing, nothing to agree. Your team is the only one that can reach the deployment.
How it is securedThe contract sets out what we can reach, who on our side can reach it, and when: a named list rather than standing administrative access.
What we signAccess shows in your cloud account's logs, so verifying our answer does not require trusting it. When we work on your system, we act as your processor under a DPA you sign.
Sub-processors
Residency
You pick the region, once, at the start.
A deployment decision
The region is chosen when the deployment is stood up, which settles most of what a regulator or a customer will ask before they ask it.
You can point at it
Where the data sits is a fact about an account you control, so proving it means showing a console rather than citing a policy page.
Per-country detail
The specifics differ by market, and where a named instrument applies, the residency pages say which one.
Data residency
Data integration
Where the data comes from, and where it goes.
- 01
In, from the providers your users already use
Cloud providers connect server to server. On-device sources arrive through an SDK inside your own app. Both land in your deployment, not in ours.
- 02
Kept as it arrived, if you want it
The original provider payload can be written to a bucket you own before normalisation, so a question nobody anticipated can still be answered two years later.
- 03
Out, through your own API
Data leaves on your schema, into your product, through an endpoint that belongs to you. There is no intermediate service holding a copy in transit.
- 04
One honest caveat about timing
Webhooks fire per provider, but the path from a watch to a phone to a provider's cloud is theirs rather than ours. We mirror what they give us and minimise what we add, rather than promise real time.
When the questionnaire arrives
What a security review gets from us.
Most questions on a vendor questionnaire are answered by the architecture rather than by us. This is the short version of who answers what.
| Hosted wearable API | Build it in-house | Open Wearables, self-hosted | |
|---|---|---|---|
| [01] Where is the data stored? | On the vendor's infrastructure | In your infrastructure | Your cloud account, in the region you chose |
| [02] Who has access to it? | Your team and the vendor's | Your team | You. When we work on it, a named list in the DPA |
| [03] Who holds a copy of the data? | The vendor | Your team | Only you. We work in your account under a DPA you sign |
| [04] What happens to the data if we leave? | An export to request | Nothing moves | Nothing moves |
| [05] Can we audit it? | Through the vendor's reports | Your account, your logs | Your account, your logs |
| [06] Do you hold SOC 2 or ISO 27001? | The vendor's, if it holds one | Yours | No. It runs inside your certified environment |
Bring us your review
If your security team has a questionnaire ready, send it. Most of it is answered by where the deployment runs, and the rest is a conversation worth having early rather than at signature.
FAQ
Common questions.
What does health data governance mean for a self-hosted deployment?
Less paperwork than for a hosted one, because several of the usual questions stop applying. Where the data sits and who the controller is are settled by the architecture rather than by policy. What remains is the part this page covers: what we can reach when we work on your system, and what happens when you stop working with us.
Who is the controller and who is the processor?
You are the controller. Where you run the deployment yourself, there is no processor, because nobody else touches it. When we work on your system, we act as your processor under a DPA you sign, with defined access rather than standing access.
Does any health data reach Momentum?
No copy of it does. The deployment runs in your account whoever works on it, so nothing is kept on our side. When we work on your system, what we can reach is defined in the DPA you sign.
What can you actually see when you work on our deployment?
What the DPA defines, and only while it applies. Because the deployment is in your account, what we did shows in your cloud account's logs rather than in a report we produce.
Who are your sub-processors?
When you run the deployment yourselves, it is in your account and we are not involved. When we support or maintain it, we act as your processor under a DPA you sign, and we name the sub-processors we use for that access. The sub-processors page covers both.
Do you hold SOC 2 or ISO 27001?
No. The deployment runs inside your certified environment, which is how most teams answer this in their own audit. If your procurement treats a vendor certificate as mandatory regardless of architecture, say so early and we will tell you honestly whether that works.
What happens to our data if we stop working with you?
Nothing moves. The deployment is in your cloud account, under an MIT license, and where we set it up, built from infrastructure code in your repository. There is no export window because there is nothing to export from.
Our customer asks us to name every sub-processor touching their data. What do we say?
When you run the deployment yourselves, the health data stays in your account and we are not involved. When we support or maintain it, we work in your account as your processor under a DPA you sign, and we name the sub-processors we use for that access.
We are regulated and our contracts have specific requirements. Can you meet them?
That depends on the requirement, and the honest answer sometimes comes with a limit attached. Bring the clause to the conversation early. It is cheaper for both sides to find out at that point than at signature.