Health data residency is the question of where patient data is allowed to be stored and processed. For hospitals moving to cloud HMS, adopting AI tools or using offshore support teams, it has become one of the first questions to answer, and India and the UAE answer it very differently.
The UAE starts from a default of localisation: health data must stay in the country unless a specific exception applies. India starts from a default of permission: personal data may be transferred abroad unless the government restricts a destination, with sector rules layered on top. A hospital group operating in both, or a vendor like us serving both, has to design for the stricter case without breaking the more flexible one.
This guide explains both regimes as of late 2026, how they affect common hospital technology decisions, and gives a practical checklist. For the broader privacy obligations in India, see our DPDP Act checklist for hospitals.
The UAE: localisation by default
The UAE's Federal Law No. 2 of 2019 on the use of information and communications technology in health fields (the Health Data Law) is the starting point. Its Article 13 provides that health data relating to health services provided in the UAE may not be stored, processed, generated or transferred outside the country, except in cases set by a decision of the health authority in coordination with the Ministry of Health and Prevention.
Those cases were set out in Ministerial Resolution No. 51 of 2021, which lists permitted exceptions for cross-border transfer and overseas processing, such as treatment of patients abroad, medical samples and pharmacovigilance (Baker McKenzie summary). Several exceptions carry conditions, including encryption to recognised standards and keeping a copy of the data inside the UAE.
Key points from legal commentary:
- Scope: the law applies to health data from UAE patients relating to healthcare services provided in the UAE.
- Exceptions are narrow: unless a transfer clearly fits a listed exception, it needs further approval from the relevant health authority.
- Emirate rules add detail: Abu Dhabi's Department of Health applies strict localisation requirements to licensed entities and has said its rules are aligned with the federal law. Dubai's DHA has its own policies.
India: permission by default, with layers
India's general regime is the Digital Personal Data Protection Act, 2023. Section 16 allows transfers outside India except to countries the Central Government restricts by notification, often described as a "negative list" approach. The DPDP Rules were notified on 13 November 2025, with most obligations, including the cross-border framework and breach notification, phased in over 18 months to around May 2027 (AZB & Partners update).
On top of DPDP, several other layers can apply to hospitals:
| Layer | What it means for hospitals |
|---|---|
| DPDP Act and Rules | Transfers allowed unless restricted; hospital remains responsible for processors abroad; breach duties apply |
| Sectoral laws | DPDP does not override stricter sectoral rules that require data to stay in India |
| Government projects | Government cloud procurement uses MeitY-empanelled providers, audited by STQC, with data in India |
| CERT-In directions | Logs for 180 days; incident reporting within 6 hours |
| ABDM | Records exchanged through ABDM follow its consent and health data management policies |
| Contracts | Insurers, government schemes and corporate clients may require in-India hosting |
MeitY empanelment, explained
MeitY empanelment is the process by which cloud providers are approved for government workloads. Providers are audited by the Standardisation Testing and Quality Certification (STQC) directorate against MeitY's security requirements, and empanelment requires that services and data are hosted in India. Reports in 2025 put the number of empanelled providers at 26.
Private hospitals are not legally required to use MeitY-empanelled clouds. But if you run government scheme work, host data for a public hospital, or want an easy answer to a procurement question about security and residency, choosing an empanelled provider and an Indian region removes a lot of friction.
How this affects common decisions
| Decision | India | UAE |
|---|---|---|
| Cloud HMS hosting | Indian region recommended; empanelled provider for government work | UAE region required by default |
| Backups and disaster recovery | Second Indian region preferred | Second site in UAE; offshore DR only within an exception |
| AI tools (LLM APIs, transcription) | Allowed with DPDP compliance; check contracts and sector rules | Inference must run in-country unless an exception applies |
| Offshore support / development | Allowed with processor contracts and controls | Access to identifiable health data from abroad is a transfer; avoid or restrict |
| Analytics and data warehouses | Prefer in-country; de-identify where possible | In-country; de-identified data may still need review |
| Email and messaging with patient data | Check processor location; minimise PHI in messages | Check processor location; minimise PHI in messages |
The AI row is where most hospitals are exposed right now. A transcription, summarisation or chatbot feature that sends patient data to a model hosted in another country may be fine in India with the right contracts and notices, and a problem in the UAE. Our post on UAE healthcare AI policy covers the governance side.
Designing for both: an architecture pattern
For hospital groups and vendors operating in both countries, the pattern we use at Algon is straightforward:
- One codebase, separate deployments. The same application runs in an Indian region for Indian hospitals and a UAE region for UAE hospitals. Patient data never shares a database across countries.
- Regional AI endpoints. AI features call models hosted in the same country as the data, or are switched off where that is not possible.
- De-identified engineering data. Development and testing use synthetic or properly de-identified data, so offshore engineers do not need access to real patient records.
- Break-glass support access. Where production support needs access, it is time-limited, logged, approved and, for the UAE, performed by in-country staff or within a documented legal basis.
- Centralised, data-free operations. Monitoring, metrics and deployment pipelines can be shared across regions as long as they carry no patient data.
This is the same approach we take to cloud and AWS architecture and DevOps in healthcare generally: keep the data where it must be, and move code and metrics freely.
Worked example: a Kerala hospital group with a Dubai clinic
Consider a hospital group with three hospitals in Kerala and one outpatient clinic in Dubai serving the Malayali community there. Management wants one HMS, one dashboard and one AI documentation tool across all four sites. How should residency shape the design?
- Patient records: Kerala hospitals run on a deployment in an Indian cloud region. The Dubai clinic runs on a separate deployment of the same software in a UAE region, configured for DHA and NABIDH requirements. There is no shared patient database.
- Patients who move between countries: when a Dubai patient is referred to a Kerala hospital for surgery, records are shared with the patient's consent as part of treatment, through a documented transfer rather than a database link. Treatment of a patient abroad is the kind of case the UAE exceptions contemplate, but the legal basis and conditions should be confirmed with counsel before go-live.
- Group dashboard: each deployment publishes aggregated, non-identifiable metrics (OPD volumes, revenue, wait times) to a group reporting store. Management sees one dashboard without patient-level data crossing borders.
- AI documentation: Indian sites use a model endpoint hosted in India. The Dubai clinic uses an endpoint hosted in the UAE, or the feature stays off until one is available.
- Support: the vendor's engineering team in Kochi works on code and on Indian production systems under contract. Production access for the Dubai deployment is limited to in-country staff or a tightly controlled, approved process.
The result costs slightly more to run than a single global deployment, but it gives clean answers to every regulator, auditor and patient question in both countries. It also mirrors the multi-specialty, multi-site setups many Indian groups are already moving towards.
Questions to ask your HMS or cloud vendor
- In which country and region is our production data stored? Backups? Disaster recovery?
- Which sub-processors handle our data, and where are they located?
- Do any features, especially AI, send data outside the country? Can they be disabled?
- Who can access production data, from where, and how is that access logged?
- Are logs and monitoring data scrubbed of patient identifiers?
- For India: are you MeitY-empanelled, or hosted on an empanelled provider? For the UAE: how do you meet the Health Data Law and DoH or DHA requirements?
- What happens to our data, including backups, when the contract ends?
Common mistakes
- Assuming "cloud" means "abroad". Major cloud providers have Indian and UAE regions. Residency is a configuration choice.
- Forgetting the tail. The main database is in-country, but backups, logs, email, analytics and AI calls go elsewhere.
- Treating de-identification as a checkbox. Removing names is not de-identification if dates, locations and rare diagnoses remain.
- No data map. You cannot answer a regulator or a patient if you do not know where data flows. Draw it once and keep it updated.
Conclusion
The UAE and India sit at opposite ends on health data residency. The UAE requires health data to stay in-country unless a listed exception under Resolution 51 of 2021 applies. India permits transfers by default under the DPDP Act, with obligations phasing in towards May 2027 and sectoral, government and contractual requirements that often push data back into India anyway.
The safe design for both is the same: in-country hosting by default, regional AI endpoints, de-identified engineering data, logged and limited support access, and a data map. If you are planning a cloud HMS or AI rollout across India and the Gulf, talk to us about building residency in from day one.
Frequently asked questions
Can UAE health data be stored outside the UAE?
Generally no. Federal Law No. 2 of 2019 restricts storing, processing or transferring health data relating to healthcare services in the UAE outside the country, except in cases permitted by the health authorities, which are listed in Ministerial Resolution No. 51 of 2021 and often carry conditions.
Does India require health data to be stored in India?
The DPDP Act 2023 allows transfers abroad unless the government restricts a destination, so there is no general localisation rule for private hospitals. However, sectoral rules, government project requirements, CERT-In directions and contracts can require data to stay in India.
What is MeitY cloud empanelment?
It is the process by which cloud service providers are approved for Indian government workloads after audits by the STQC directorate. Empanelment requires services and data to be hosted in India. Private hospitals are not required to use empanelled providers, but it simplifies government and procurement requirements.
When do the DPDP cross-border rules come into force?
The DPDP Rules were notified on 13 November 2025. Most obligations, including the cross-border framework and breach notification, phase in over 18 months, to around May 2027.
Can hospitals use AI tools hosted abroad?
In India, possibly, with DPDP-compliant processor contracts, notices and attention to sectoral or contractual restrictions. In the UAE, sending identifiable health data to a model hosted abroad is a cross-border transfer that generally needs to fit a permitted exception.
Can offshore teams support a UAE hospital system?
Access to identifiable UAE health data from abroad is treated as a transfer, so it should be avoided or tightly restricted. Common approaches are de-identified data for development, in-country support staff for production access, and logged, time-limited access within a documented legal basis.
