--- title: "Health Data Residency by Jurisdiction" description: "Where health data has to stay, what says so, and what a self-hosted deployment does about it, in the UAE, Singapore, Germany, France and the Netherlands." canonical_url: "https://openwearables.io/data-residency" --- # Where health data has to stay. Data residency Residency questions arrive as a clause, a questionnaire or a procurement condition, and each market has its own. Open Wearables runs in your own cloud account, in the region you pick. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) Why it runs in your cloud ## The layer has to be yours before what you build on it can be. A hosted API keeps the data, and every score computed from it, in a vendor's account. Running the layer yourself keeps it where HIPAA, GDPR and your own policy say it belongs. ### Sovereignty Your regulator, your board or your own policy says health data does not sit in a third party's cloud. ### Residency The data has to stay in a country or region you choose, and you have to prove where it is. ### Control You run the deployment under your own credentials and decide who gets access. What you build on top of Open Wearables is yours. ### Your own reasons No regulator forcing it and no security review coming. You want the data in your own account anyway. ## The short answer. ### You choose the region. The region is set when the deployment is, in your own cloud account. Not a preference we honour, a choice you make. ### The data sits in your account. Self-hosted, no copy lands in a Momentum tenant. The data stays in your account, in the region you chose. ### Provable rather than promised. You evidence residency by pointing at your own cloud account, not at a vendor's policy page or a contract clause. ### Each market works differently. A statute in one, a contract clause in another, a certified host in a third. The pages below take them one by one. ### No vendor tenant in the path. Self-hosted, the data goes from the provider or the phone straight into your own account, in the region you chose. By jurisdiction ## Pick your market. What applies, in a sentence, and a page each with the detail and the answers a reviewer asks for. ### UAE The law keeps health data in the country, and moving it abroad needs the health authority's approval. [The UAE page](https://openwearables.io/data-residency/uae) ### Singapore Public healthcare contracts can bar a vendor from processing data outside Singapore without written approval. [The Singapore page](https://openwearables.io/data-residency/singapore) ### Germany Healthcare providers and insurers may only process health data in cloud services with a C5 attestation. [The Germany page](https://openwearables.io/data-residency/germany) ### France Hosting health data for someone else needs HDS certification, and certified hosts now store it in the EEA. [The France page](https://openwearables.io/data-residency/france) ### Netherlands Care providers have to work to NEN 7510, and buyers ask their suppliers to show the same. [The Netherlands page](https://openwearables.io/data-residency/netherlands) ## When the region gets chosen. Residency is settled at deployment rather than negotiated afterwards, which is why it rarely becomes a contract argument. ### The cloud and the region You choose both, in the account you already have, wherever your cloud provider operates. ### Several markets Users in several countries may need one region or several. Which rules reach the data decides, not office locations. ### Credentials in your name Provider credentials are issued to you, so the relationship with each wearable provider is yours. ### Moving later Where we set it up, the infrastructure is code in your repository, so a region change is engineering work. The data path ## Where the data goes, step by step. Every step runs inside your deployment, in the region you chose. Nothing passes through a Momentum tenant on the way. [See the platform](https://openwearables.io/platform) 01 ### Collect Cloud providers connect server to server, and the mobile SDKs read the stores that live on the phone. Every source ends up in the same deployment, in your account. 02 ### Store Everything lands in one schema in your own database, in your chosen region, with the original payload kept underneath if you switch that on. 03 ### Compute With Pro, health scores from our science team, computed inside your deployment. 04 ### Use Your product reads it over the REST API, reacts to webhooks, or asks questions through the MCP server, all against the same deployment. ## Bring us the clause you are working against Your market is not listed, or your question is specific? Send the instrument, the customer requirement or the questionnaire wording, and you will get a straight answer about what a deployment in your own account does. [Book a call](https://openwearables.io/book) FAQ ## Common questions. ### Which regions can we deploy in? Wherever your cloud provider operates, because the deployment runs in your account rather than ours. That is the practical difference from a hosted API, where the answer is limited to the regions that vendor has chosen to open. ### Do you hold data on your side at all? Self-hosted, no. The data sits in your own cloud account, and nothing is copied to a Momentum tenant. ### Our regulator has not published anything specific. Does that help us? Less than it sounds. Nothing published is not the same as nothing required, and enterprise customers apply their own standards regardless of what a regulator has said. Some markets also restrict conditionally rather than outright, depending on how the data is classified. If no requirement reaches you and no customer review is coming, a hosted API is probably the better tool, and we would say so. ### How do we evidence residency? By pointing at your own cloud account and the region it runs in, which is a fact about infrastructure rather than a policy statement. ### We operate in several countries. Does that mean several deployments? Not necessarily. What matters is which rules reach your data, not where your offices are: a company with users in five countries may need one region, and a company in one country may need two. ### Is the region something we can change later? Yes. Moving a deployment is engineering work you schedule, not a commercial negotiation. ### Do you give legal advice? No. We name what applies, say how it works, and describe what a deployment does about it. Whether a rule applies to your product is for your counsel.