UAE health data residency: Tier 3 and a DESC-certified cloud

UAE health data residency is not one rule but three, and the third is the one that breaks architecture diagrams. Patient data tied to care delivered in the country must stay in the country, on a data centre certified to at least Tier 3, hosted by a cloud service provider carrying a DESC certification. DESC does publish a list of certified providers. No hyperscaler is on it.

This analysis comes from reading the published rules and the primary sources behind them: the Dubai Health Authority's current telehealth standard, DESC's own certification pages, and the compliance documentation the cloud providers publish about themselves. Where we could not read a primary document, we say so rather than characterise it. The short version, as of 8 October 2026:

• The document is DHA's Standards for Telehealth Services, DHA/HRS/HPSD/ST-14, Issue 4, effective 26/11/2025.
• The hosting clauses are 7.6.7(a) and (b): at least Tier 3 certified data centres, storage at a DESC-certified cloud provider in the UAE.
• The export rule is 8.2.5(d) and the note under 7.6.7: no storage, development or transfer abroad, except the cases in Article 2 of Ministerial Decision No. 51 of 2021.
• The reach is every system touching the data — backups, logs, traces, error reports and inference endpoints included.

What the DHA standard actually requires, clause by clause

The published PDF sits under a /uploads/012023/ path, which reads like a January 2023 document and is not one. The cover and every page footer carry Version 4, issue date 26/09/2025 and effective date 26/11/2025. Check the footer, not the URL.

Clause 7.6.7 requires that all stored data comply with Federal Law No. 2 of 2019 on the use of ICT in healthcare, then adds five sub-requirements. The first two are the infrastructure ones: all data centres shall be at least Tier 3 Certified, and all data shall be stored in a server located at a Cloud Service Provider (CSP) certified by Dubai Electronic Security Centre (DESC) in the UAE. The remaining three ask for HIPAA compliance certification, ISO 27001 certification, and — for certain conditions — HITRUST or SOC 2 with HIPAA alignment.

Two other clauses matter as much and are easier to miss. Clause 7.9.1(h) requires secure servers located in the UAE with relevant data backup, which puts the backup copy in scope by name. Clause 8.2.5(d) states that storage, development or transfer of health data outside the UAE is prohibited unless approved by DHA.

Note the verb in both 8.2.5(d) and the note under 7.6.7: develop, alongside store and transfer. This is not a storage-location rule with a processing carve-out. Computing on the data abroad is the thing being prohibited.

What Article 2 of Decision 51/2021 actually permits

Every piece of coverage we found treats UAE health data as absolutely unexportable. The DHA standard does not say that. The note under 7.6.7 carves out the cases mentioned in Article no. (2) of the Ministerial Decision no. (51) of 2021, and whether a lawful route exists is a commercial question for any platform with an offshore analytics or support model.

We could not read Ministerial Decision 51/2021. The UAE legislation portal returned HTTP 403 to every request, the full-text legal databases that carry it paywall the text after Article 1, and the law-firm alert that reproduces it is a PDF whose text layer we could not extract. We are not characterising the decision's own words.

What we can report is CMS's published tabulation of the Article 2 cases, attributed to CMS. It lists nine: treatment outside the UAE, examination of samples abroad, scientific research, insurance and claims administration, cooperation with the UAE state, simple devices and tools, pharmacovigilance, online health services, and transfer at the patient's request. Most carry conditions — consent, encryption, anonymisation, and in several cases retaining a copy inside the UAE.

Read that list as an architect and the commercial answer is clear. A documented lawful route exists, and none of the nine cases is offshore analytics, offshore engineering support, or vendor-side processing for your own convenience. Online health services is the closest fit for a telehealth platform, and its conditions include retaining a copy in the UAE and restricting access to the treating physician on the relevant system for a defined period. That is not a licence to put your warehouse in Frankfurt.

There is also a second route, and the standard describes the exception twice in two different ways. The note under 7.6.7 points at Article 2. Clause 8.2.5(d) says instead that transfer is prohibited unless approved by DHA. Those are not the same test: one is a self-assessment against a closed list, the other is an application to a regulator. Where the same document gives you two readings, design for the stricter one and get the DHA approval in writing.

Which providers hold DESC certification, and why DESC's list won't tell you

DESC does publish a register. Its Certified Providers page carries three tables — Incident Response, Penetration Testing, and Cloud Service Provider — and the Cloud Service Provider table held 25 entries when we read it on 8 October 2026.

Not one of them is AWS, Microsoft, Oracle, Alibaba Cloud or Moro Hub. The names are Dubai-registered cyber-security and audit firms: KPMG Lower Gulf, Protiviti's Dubai branch, Gulf Business Machines, DTS Solution, ValueMentor, CPX Holding, Paramount Computer Systems. The page's own introduction frames the scheme as a Cyber Force certification for individuals and companies offering services to Dubai government entities. Six of the 25 entries carried expiry dates that had already passed by the date we read them.

So the list is real, and it is not the list a hosting buyer needs. It registers firms that provide cloud security services, not platforms certified against the CSP Security Standard. Hand that URL to a procurement team as the approved-hosting list and they will reject every provider you actually intend to use.

The certificates you need are issued by certification bodies accredited by DESC. Per DESC's certifications page, the CSP Security Standard is built on ISO/IEC 27001:2013, 27002:2013 and 27017:2015, Dubai's ISR 2017 v.02 and the CSA Cloud Controls Matrix 3.0.1, with yearly surveillance audits and recertification every three years. Existing certificates for the underlying standards are accepted without re-audit. There is no central lookup: you get the certificate from the provider.

Three providers publish theirs:

• AWS holds a Tier 1 CSP licence covering the Middle East (UAE) Region. The 2026 audit announcement gives a certificate valid through 22 January 2027, 108 services in scope after 10 were added, and BSI as the third-party auditor. The certificate downloads from AWS Artifact.
• Microsoft says it was the first global cloud provider to obtain the certification. Per Microsoft's own compliance page, the certificate applies to UAE Central (Abu Dhabi) and UAE North (Dubai), with scope stated as Azure Core Services, Dynamics 365 Core Services and Office 365 Services. Documents come from the Service Trust Portal's UAE regional resources.
• Alibaba Cloud states on its trust centre that the certification covers the data centres deployed in its Dubai region, with the certificate available for download. It names neither a date nor a certification body.

Read those three side by side and the verification problem becomes obvious. AWS enumerates 108 named services. Microsoft states a product family. You cannot compare the two certificates on scope, and scope is the whole question — a service absent from the certificate is not covered even when it runs in the right region. Amazon Bedrock entered AWS's DESC scope only in the 2026 audit, and Bedrock Marketplace is excluded. An inference endpoint that looked compliant on a region diagram last year was outside certificate scope.

Four things to check on any DESC certificate: the region it names, the services-in-scope list, the expiry date, and whether the issuing certification body is DESC-accredited. A marketing claim of DESC certification answers none of them.

"Tier 3 Certified" — by whom, and certified at what stage?

Clause 7.6.7(a) requires data centres to be at least Tier 3 Certified and names no certifying body. The scheme the phrase refers to in practice is the Uptime Institute's, where Tier III means Concurrently Maintainable: every capacity component and distribution path can be taken out of service on a planned basis without disrupting operations, while the site remains exposed to equipment failure and operator error.

The trap is that Uptime issues three different certifications. Tier Certification of Design Documents reviews drawings. Tier Certification of Constructed Facility verifies the building was built as designed, which matters because construction practice and value engineering can compromise design intent. Tier Certification of Operational Sustainability assesses how the facility is run. A press release announcing "Tier III certification" is frequently about the first of those, for a building that does not yet exist.

Ask which named facility your workload lands in, whose Tier scheme it is certified under, whether the certificate covers design or constructed facility, and whether it is current. Uptime publishes a Tier Certification List to check the answer against.

The HIPAA clause that cannot be satisfied as written

Clause 7.6.7(c) requires that all platforms have HIPAA compliance certification. No such thing exists. The US Department of Health and Human Services states in its Security Rule FAQ that no standard or implementation specification requires a covered entity to certify compliance, that HHS does not endorse or recognise private certifications, that such certifications do not absolve an entity of its obligations, and that an external certification does not preclude HHS from subsequently finding a violation.

This is the sharpest example in the standard of a clause with no corresponding artefact. What a reviewer can actually be given is what 7.6.7(e) already names: a SOC 2 report with HIPAA alignment, or HITRUST. Both are real audits with real lead times and real cost, and both belong in the budget before the first sprint rather than in the week before a licensing submission.

UAE health data residency reaches further than your primary database

This is the part teams get wrong. Clause 8.2.5(d) prohibits storage, development or transfer abroad, and 7.9.1(h) puts the backup inside the UAE by name. Health data is whatever relates to the health service delivered in the country, and it does not stop being health data when it arrives in a log line.

Layer	Where it defaults	Why it is in scope
Primary database	Provider default region	The record itself; must also be a service named in the DESC certificate
Automated backups and snapshots	Same region, sometimes copied out	7.9.1(h) names backup explicitly
Cross-region DR replica	A second region, usually outside the UAE	Continuous transfer of the full record set
Log aggregation	Vendor's US or EU ingest endpoint	Request bodies, query parameters and patient identifiers
Error tracking	Vendor's default region	Stack traces carry local variables and request context
Session replay	Vendor's default region	Records the clinician's screen, which is the record
APM traces	Vendor's default region	SQL statements with bound parameters
Analytics and BI warehouse	Wherever the warehouse already is	Usually the largest single copy of the data
AI inference endpoint	Model provider's region	A prompt containing a patient record is a transfer
Email, SMS and support tooling	Vendor's default region	Notifications and ticket attachments carry identifiers

A team that moves its database to the UAE and leaves its observability stack offshore has not complied. The database migration is the visible, budgeted, project-managed half; the telemetry pipeline is the half that was configured once by whoever set up the account and has pointed at a US ingest endpoint ever since.

Error tracking is the most frequently missed layer, because nobody thinks of a stack trace as patient data until they read one that serialised a request body. Session replay is the extreme case: it is a video of the medical record. The AI layer deserves its own review, because a model endpoint outside the region is a transfer and an endpoint inside the region still has to appear in the provider's certificate — the same question we worked through on where an AI provider's data actually stays.

Two adjacent decisions are worth settling at the same time. Your DR design has to survive without the cross-region replica most reference architectures assume, which we have written about in the context of disaster recovery for UAE workloads. And an in-country backup you have never restored is not a backup — the backup you never restored is the one the residency audit will ask about.

Who this binds, and who it does not

The strongest argument against everything above is a scope argument, and it deserves stating properly. Applicability clause 4.1 applies the standard to DHA-licensed healthcare professionals and health facilities providing telehealth services. If you are a software company with no DHA licence, the standard does not name you. Clause 4.2.3 goes further and excludes platforms used for face-to-face in-person consultation altogether, alongside emergency life-threatening intervention and the prescribing of narcotic, controlled or semi-controlled medication. DHA regulates Dubai; Abu Dhabi's Department of Health and MOHAP are separate regulators with their own instruments.

That argument fails on clause 7.6, which imposes obligations directly on platforms regardless of who 4.1 names. Clause 7.6.2 requires every telehealth platform intended for internal or commercial use to be assessed and approved by DHA's health facility licensing section before in-house or go-to-market implementation. Clause 7.6.3 requires legal representation in Dubai with a trade licence, 7.6.4 an assigned Business Technical Director, and 7.7 approval of any change to core functions, data management practices or ownership. A vendor reading only clause 4.1 and concluding it is out of scope has stopped reading too early.

Two related subjects sit outside this post deliberately. Where the licensing boundary falls between a platform and a facility is its own question. And general personal-data residency under the federal PDPL is a separate regime, worth knowing precisely because it is not the instrument governing the clauses above — health data sits under its own sectoral law.

What to do before the architecture is drawn

Get the DESC certificate from each provider you are considering, and read its services-in-scope list against your real dependency list — not the four boxes on the architecture diagram, but every managed service, every SaaS vendor and every telemetry endpoint in your terraform state. The gaps that turn up are rarely the database.

Then price the audit work that 7.6.7 actually makes achievable, settle whether you need a DHA cross-border approval or can run entirely in-country, and only then choose a region. Doing it in that order is the difference between a hosting decision and a hosting migration. If you want to see how we approach this kind of constraint, our DevOps and cloud engineering work is the relevant practice, and you can see what we build in Dubai.