#Data Residency & Localisation Statement: United Arab Emirates

Position as at 01 August 2026. This document is written to be read before a demonstration, not after a security review. It states where UAE hospital data physically resides under each deployment model, and it names the models that cannot be offered in this market.

---

#Applicability

Read that table as the answer to the first question a UAE hospital asks. It is not softened elsewhere in this document.

---

#Purpose

To state, unambiguously and per deployment model, where data generated by health services provided in the United Arab Emirates is stored, where it is processed, where its backups and logs live, and from which countries a human being can reach it, and to state plainly which of Pensieve Labs's deployment models cannot lawfully be used in this market today.

DIS-GL-008 is the global residency statement and carries the four-component model this document uses. This document is the UAE fork. Where the two differ on a UAE question, this document governs.

---

#1. The rule

Federal Law No. 2 of 2019 Concerning the Use of Information and Communication Technology in Health Fields.

#1.1 Why the four verbs matter

Article 13 names four activities: stored, processed, generated, transferred.

Most vendor residency statements answer only the first. A statement that says "your database is in the UAE" is not an Article 13 answer, because:

• "processed" covers computation. Keeping the database in the UAE and running application compute, batch jobs, reporting, search indexing or model inference elsewhere does not comply.
• "processed" also, on the conservative reading Pensieve Labs adopts, covers a human being outside the UAE operating on the data, including viewing it on a screen during a support session. Section 6.
• "generated" covers data created by the Platform itself: derived records, audit logs, computed indicators, generated documents. These are health data too, and they must be generated inside the UAE.
• "transferred" covers the movement, not merely the resting place. A nightly export to an analytics environment outside the UAE is a transfer even if the primary store never moves.

The obligation is territorial, not risk-based. It is not satisfied by encryption, by pseudonymisation, by key custody arrangements, by a data processing agreement, by standard contractual clauses, or by any combination of them. Those instruments answer a risk question. Article 13 asks a location question.

#1.2 The exemption, and why Pensieve Labs does not plan around it

Article 13's carve-out requires a decision of the relevant health authority in coordination with the Ministry of Health and Prevention.

The reasoning is simple and worth stating to a customer: complying is faster and more certain than applying for permission not to. A cost Pensieve Labs controls is better than a wait it does not.

The full protocol for handling an Article 13 permission request (who prepares what, what Pensieve Labs will and will not sign, and what happens to the deployment while a decision is pending) is DPA-AE-001 Schedule 2.

---

#2. What the default infrastructure cannot do

There is no region of Pensieve Labs's default cloud provider inside the United Arab Emirates.

Therefore: Pensieve Labs does not serve a UAE hospital from an India region, from any Middle East region of its default provider, or from any other region outside the UAE, under any circumstances, in any deployment model. This is an architectural rule inside Pensieve Labs, not a contractual promise that could be waived commercially.

---

#3. The four-component answer, per deployment model

DIS-GL-008 establishes that residency has four components and that vendors routinely answer only the first. The UAE answer, component by component:

#3.1 What never leaves the UAE, in every available model

• Patient records, clinical documentation, prescriptions, results, images, billing and financial records.
• Backups, snapshots and exports.
• System and audit logs.
• Encryption keys.
• Derived and generated health data of every kind, including analytics outputs computed over patient data.

Pensieve Labs does not maintain a central copy, warehouse, analytics extract, benchmarking dataset or training corpus of any hospital's data in any location. There is no global data lake. This is stated because it is the assumption a reviewer should test, and because in this market the assumption being wrong would be a statutory breach rather than a policy failure.

#3.2 What does leave, and what it is

Three categories cross the border. None is health data and none is patient data. They are listed exhaustively so that the list can be checked rather than trusted.

---

#4. The infrastructure options, honestly

#4.1 A cloud provider with a UAE region: the scale answer

Two major public cloud providers operate regions physically inside the United Arab Emirates, and sovereign cloud operators serve the same market. Any of them satisfies Article 13 on storage, processing and generation.

What it costs Pensieve Labs: a port of the Platform's managed-container compute, managed database, object storage, key management and logging to that provider, a programme of the order of 60 to 120 days of engineering, run once and then reused for every UAE customer.

Status: not complete. Until it is, DM-1 and DM-2 are not offered in this market. Pensieve Labs will not describe a planned port as an available option, and will not accept a UAE DM-1 order on the expectation that the port will finish in time.

When it completes, the chosen provider becomes the infrastructure sub-processor for this market and is recorded as a separate market entry in DIS-GL-009, not as a variant of the default provider's entry. A UAE hospital's reviewer should expect to see a different company named in the register for its deployment than an Indian hospital would see.

#4.2 The shared estate: a second, separate condition

DM-2 requires both the port in Section 4.1 and a UAE-resident shared estate with its own tenancy isolation boundary. A UAE tenant cannot be placed on a shared estate that lives anywhere else, and a shared estate serving several markets from one region is not available to this one. DM-2 is therefore the last model to become available in the UAE, not the first.

#4.3 The hospital's own cloud account: DM-3

Where the hospital holds an account with a provider that has a UAE region, Pensieve Labs deploys into it. The hospital owns the account, selects the region, holds the billing relationship and holds the keys. Article 13 is satisfied by the hospital's own infrastructure choice, and Pensieve Labs's access to it is governed by ADD-GL-009 and by Section 6 below.

This is the fastest compliant path for a hospital that already has cloud competence. It requires the hospital to have or acquire it; WPR-GL-004 states what that costs in schedule.

#4.4 On-premise or UAE colocation: DM-4

The hospital's own server room, or a rack in a UAE colocation facility, satisfies Article 13 by physical fact. There is no region question, no provider question and no transfer question.

In every other market Pensieve Labs steers away from DM-4 because it is the slowest and most expensive model and it breaks the 14-day target. In the UAE it is the recommended model for a first deployment, because it is the only model available today without a platform port and because it converts a regulatory problem into a logistics problem.

What DM-4 costs is not softened here: ADD-GL-008 applies in full, including its statement that Pensieve Labs offers no availability commitment for infrastructure it does not control, that patching windows are the hospital's to grant, and that backup custody is the hospital's. SLA-GL-001 is read subject to ADD-GL-008.

#4.5 Options Pensieve Labs rejects, and why

---

#5. What a UAE hospital should actually verify

Four configuration facts, which Pensieve Labs will show on request during the security review rather than assert:

1. The region identifier of the database instance, the object storage buckets and the container service, and that it resolves to a facility inside the UAE.
2. That backup replication outside the region is disabled, not merely unconfigured. The distinction is whether a future change can silently enable it.
3. That the log bucket is regional, inside the UAE, with retention configured and retention lock applied where the provider offers it. See DIS-GL-034.
4. That data-access audit logging is explicitly enabled. It is off by default on most providers, and a deployment where it is off cannot evidence who read a record (DIS-GL-013).

Under DM-3 and DM-4 the hospital can verify all four itself, in its own console or on its own hardware, without relying on Pensieve Labs at all. That is the strongest form of this assurance and it is one of the reasons those models are recommended here.

---

#6. Access residency: the question that decides the deal

This is the component of Article 13 that vendors hide and that a competent CIO finds. Pensieve Labs states it first.

#6.1 The unresolved legal question, stated as unresolved

Article 13 restricts processing outside the UAE, not merely storage. Whether a support engineer outside the UAE viewing UAE health data on a screen (with no copy, no cache and no export) constitutes processing outside the UAE is not resolved by any regulator guidance identified. [UNVERIFIED]

Pensieve Labs does not claim the permissive reading. It operates to the strict one.

#6.2 The position

1. Support that requires sight of UAE health data is performed by personnel located in the United Arab Emirates, or it is not performed. Where no UAE-resident engineer is available for a class of work, Pensieve Labs says so and the work waits or is done by the hospital.
2. Pensieve Labs's engineering and support function is operated from India (DIS-GL-033). That is the reason for point 1, and it is a real constraint on what Pensieve Labs can offer in this market until a UAE-resident support tier exists.
3. Where a remote session from outside the UAE is unavoidable, it is conducted as a screen-mediated session that does not transfer, copy, cache, download or export health data outside the UAE; it is approved in advance by a named approver at the hospital; it is time-bound; it is recorded; and the recording is stored inside the UAE. The hospital should take its own advice before relying on this option, because Section 6.1 is unresolved and the hospital carries the licensing consequence.
4. Diagnostic exports, memory dumps, database extracts and log bundles containing health data are not taken out of the UAE, in any model, for any purpose, including debugging.
5. Under DM-3 and DM-4 the hospital controls the access path itself. Access exists only while the hospital opens it. This is the cleanest answer to Section 6.1 available and it is another reason those models are recommended.

#6.3 What this costs the hospital, stated honestly

A support model that excludes offshore access is slower than one that does not. Pensieve Labs will not pretend otherwise. A hospital choosing the strict reading should expect longer resolution times on data-specific defects than SLA-GL-001 records for markets without this constraint, and the Order Form records the applicable targets for this market rather than importing the global ones.

#6.4 Data minimisation in the support channel

Because a screenshot pasted into a ticket is a transfer, the rule that keeps health data out of the support channel is enforced here as a control rather than a guideline:

• Tickets carry identifiers, not content.
• Attachments containing patient data are refused, and where received are deleted with the deletion recorded.
• Hospital staff are briefed on this at onboarding, because the most common source of a breach of it is the hospital's own user attaching a screen capture.

---

#7. The other UAE data laws, and why they change nothing here

---

#8. Where Pensieve Labs cannot currently meet a requirement

A residency statement that lists only successes is not a residency statement.

---

#9. Changing the arrangement after go-live

Pensieve Labs does not move a hospital's data for its own operational convenience. In this market it could not lawfully do so even if it wished to.

---

#10. Limitations

10.1 No UAE deployment exists yet. Sections 3 and 4 describe an architecture and a set of controls, not a running system that has been observed. The first UAE deployment will produce the evidence; until then this document should be read as a design commitment.

10.2 Region is a configuration. The control against drift is infrastructure-as-code with reviewed changes and configuration-drift alerting (WPR-GL-001 Section 7.2), not a certificate. Section 5 exists so that a hospital verifies rather than assumes.

10.3 Cloud provider internal operations. A provider may operate global control planes for its own service management. Pensieve Labs relies on that provider's published documentation and contractual commitments about what those planes carry and does not independently verify them (DIS-GL-009 Section 9.1). In this market that reliance is material, because a control plane that carried health data outside the UAE would be an Article 13 problem Pensieve Labs could not detect. It is a question to put to the chosen provider in writing before the port in Section 4.1 is committed.

10.4 The strict reading in Section 6 is Pensieve Labs's choice, not a regulator's ruling. A hospital that obtains contrary advice may relax it for its own deployment; Pensieve Labs will not initiate that.

10.5 [UNVERIFIED] items are marked. They are unresolved in the research behind this document and are carried forward as unresolved rather than smoothed over.

---

#11. Related documents

---

#12. Change history

---