--- title: "Health Data Residency in the UAE" description: "UAE law requires health data to stay in the country. What that means for a hosted wearable API, and what a deployment in your own account does about it." canonical_url: "https://openwearables.io/data-residency/uae" --- # Health data has to stay in the country. Data residency ยท UAE UAE law keeps health data inside the country. Open Wearables runs in your own cloud account, in a UAE region, so the data never leaves. [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. ### The rule is statutory. UAE law requires health data to stay in the country. Moving it abroad needs an exception from the health authority. ### A problem for hosted platforms. If a vendor processes the data on servers outside the country, the problem is structural and no contract term fixes it. ### Self-hosting answers it directly. Open Wearables runs in your own cloud account, in a UAE region. The data goes from the provider into it and stays. ### 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. ### 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. The detail ## Three ways to build it. What each approach looks like under a rule that keeps health data in the country. | | Hosted wearable API | Build it in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] Where the data is processed | On the vendor's servers, usually outside the UAE | In your own infrastructure | In your own account, in a UAE region | | [02] Under the rule | A structural problem, not a configuration one | Works | Works | | [03] The integrations | Written by the vendor | Yours to write and maintain | Already written, MIT licensed | | [04] What it takes | A transfer to justify | Integration work and ongoing maintenance | A deployment in your own account | ## How it works in practice. Residency is settled when the deployment is set up, not negotiated afterwards. ### The cloud and the region You choose both, in the account you already have. AWS and Azure both operate regions inside the UAE. ### Credentials in your name Provider credentials are issued to you, so the relationship with each wearable provider is yours. ### In writing When we set up the deployment for you, the cloud account and the region it runs in are stated in writing. ### Moving later Where we set it up, the infrastructure is code in your repository, so a region change is engineering work. ### Free zones DIFC, ADGM and Dubai Healthcare City run their own data regimes, and the federal rules may apply too. Counsel decides. 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 UAE 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. ## Tell us what you are building We will tell you what it takes to run it inside the country. [Book a call](https://openwearables.io/book) FAQ ## Common questions. ### Does this apply to wearable data? The law covers health data related to health services provided in the country, and wearable data collected by a health product often sits inside that. Whether it reaches your particular case is for your counsel. What we can tell you is what the architecture does either way. ### Our company is in a free zone. Does the federal rule reach us? Possibly both apply, and they are not identical. A deployment in a UAE region keeps the data in the country under the federal rule; whether a free zone adds conditions of its own is a question for your counsel. ### Which UAE regions can we deploy in? AWS runs one and Azure runs two. Google Cloud has none inside the UAE today. If your cloud provider has no UAE region, raise it early, because that changes the shape of the answer rather than the configuration. ### Can we keep a copy outside the country for analytics? Only where the health authority has decided an exception applies, so settle it before you build. The deployment itself does not need a second copy anywhere. ### Do you give legal advice? No. We tell you what the architecture does. Whether a rule applies to your product is for your counsel.