Data Residency Versus Data Sovereignty: A UAE Buyer’s Guide

A UAE business asks a software supplier whether its records will stay in the country. The supplier confirms that the production database is in a UAE cloud region. The buyer then asks where the backups go, whether an overseas support engineer can open a ticket attachment and who controls the keys needed to restore an encrypted copy. The original answer covers one part of the service. The other questions can affect whether the deployment meets the buyer’s obligations and whether it can run during an incident.

Data residency is about where specified data is stored or processed. Data sovereignty is a broader buying question about the laws and authorities that can apply and the practical control the customer has over access, administration and recovery. Suppliers may use the terms differently. Ask them to describe the proposed service in concrete terms and tie each answer to a contract, configuration or test.

Start with the entity and the records

Identify who is buying the service and who will use it. A UAE group may have a mainland operating company, a free-zone affiliate and a shared support team. A contract signed by one company can cover records or staff from another. List the relevant entities, their roles and the data each will handle. Give the legal or privacy lead the actual flow rather than relying on a group-level description.

Article 2 of the UAE federal personal data protection law sets out its scope and exclusions, including establishments in free zones with special personal data legislation. Articles 22 and 23 address transfers outside the State under different protection conditions. The buyer needs to identify the applicable regime and assess the proposed processing and transfers for its own circumstances. A customer contract or sector requirement can add a separate restriction, so record which source creates each condition. UAE Federal Decree by Law No. 45 of 2021

The DIFC Commissioner’s guidance discusses exporting personal data outside the DIFC under its own law, including adequacy and routes under Article 27. The ADGM Office of Data Protection also publishes guidance and its designated adequate jurisdictions for transfers out of ADGM. These are different reference points from a supplier’s country label. For an applicable free-zone regime, assess the recipient and the transfer against that regime even when the buyer and vendor both describe the service as UAE-based. DIFC data export and sharing and ADGM adequate jurisdictions

Dubai Chamber of Commerce’s Dubai Freezone Growth Event reel gives context for the role of free zones in local business. For the purchase, document the actual entity, its role and the legal analysis. A location in a sales proposal can identify where a server sits while leaving those questions unanswered.

Ask for a map of the whole service

Pick one realistic record and have the supplier trace it through the proposed deployment. For example, a Dubai distributor uploads a customer order with a delivery address. Follow the order through the web application, extraction service, database, file storage and any integration that passes it to a carrier. Then follow a failed order through diagnostics and support. A screenshot attached to a ticket may contain the same address as the database row.

For each step, record whether the service receives the full record, selected fields or only metadata. Ask where that material is stored and processed, where it can be accessed from and how long it remains. Include backups, replicas, logs, caches and exports. Add development and test environments if production data or support extracts can reach them. Make a separate row for optional features, since turning on a new search or analytics tool can change the path.

Microsoft’s Azure documentation distinguishes regional and nonregional services and explains that some components have their own location settings. This is an example of why a service map should include dependencies even when the main workload has a named region. Check the documentation and terms for the actual product and account. Where a provider can offer more than one configuration, confirm which one the quote includes. Microsoft Learn on Azure nonregional services

Identify who can access, authorize or compel disclosure

Ask who runs the service and who can obtain access to customer content. Include the contracting entity, the cloud operator, the application provider, the support partner and subcontractors. Identify who administers user accounts, who can grant emergency permissions and who can approve a change to the service. Keep this list separate from the storage map so the buyer can see where an access route crosses an organizational or geographic boundary.

Ask the supplier to demonstrate a support case using approved test data. Show what a support worker can see before approval, what happens after access is granted and whether it expires. Have the buyer retrieve the record showing which identity accessed what and why. If a vendor advertises an access approval feature, confirm that it covers the specific services, editions and incident paths the buyer expects to use. Ask which emergency exceptions exist and how they are logged.

Ask legal to assess which laws could apply to the parties and how the supplier handles demands for disclosure. Request the relevant policy or agreement, including the process for reviewing requests, limiting the data disclosed and informing the customer where permitted. There is a distinction between the technical possibility of access and the legal authority to require it. Neither is resolved solely by moving the production database.

Use a separate check for people inside the buyer’s own group. A shared administrator may inherit permissions across subsidiaries or tenants even if the supplier meets the geographic commitment. Test two ordinary users from different entities and an administrator whose permissions have recently changed. Ask whether access to exported records and diagnostic copies follows the same policy. If it does not, name the person who is responsible for reviewing those grants.

Test what control over encryption means

Record who creates and stores the keys, which services may use them and who can revoke access. The phrase “customer-managed key” can describe an arrangement where the customer sets policy but the application can still decrypt content to perform an authorized task. Ask which components actually use the key. Search indexes, snapshots, support files and logs may have separate settings.

Have the vendor demonstrate rotation in a test environment and confirm which records remain readable. Then rehearse loss of access to a key during recovery. A control that blocks the application from opening a file can also block the buyer from restoring operations. Identify who can authorize recovery use, how the decision is recorded and which keys the secondary environment requires. Avoid making assumptions about erasure from key deletion when other copies, keys or retention obligations exist.

Check what the buyer can take on exit. Request a sample export, its data dictionary and a procedure for validating completeness. Determine whether customer-held keys will be needed to decrypt the export or any archived material. Ask which copies the supplier will retain, under what conditions and for how long. Get the people who will perform the migration to run through the steps before the company relies on that exit plan.

Apply the same constraints during recovery

A backup held locally is useful only if the business can restore it where it is permitted to operate. Have the supplier show the recovery location for the database, documents, keys and identity services. Ask whether an outage would send logs or diagnostic material through a different route. Where the primary service offers automatic replication, ask whether the buyer can choose or restrict the destination. Make the destination explicit in the recovery design. Record the setting that controls failover and the role allowed to change it during an incident.

Suppose the hypothetical distributor approves UAE storage for order records and needs a second copy it can restore without the primary site. The vendor can keep the database replica in the approved location but proposes sending full incident files to a support system with different access terms. The buyer can ask whether masked diagnostics are sufficient, test the alternative and record any residual exception. A recovery drill should then verify the actual route for both the records and the support case.

Record what happens to temporary copies after the exercise or incident. A recovery team might export data for reconciliation or turn on detailed logging during a failure. Assign an owner to check that those records are stored, accessed and disposed of according to the agreed terms. Include failback in the test so the team knows where the final authoritative copy will sit when normal service resumes.

Turn the assurances into a purchase record

Write a short acceptance schedule for each data category. Name the permitted storage and processing locations, access roles, support arrangements, retention and exit obligations. Identify which controls belong to the customer and which the supplier must maintain. Ask for notice before material changes to locations, subprocessors or features. Give the legal, security and service owners a common record so they can see how a change would affect their responsibilities.

Agree what happens when a verification fails. A location mismatch may mean disabling a feature or holding deployment until the supplier can offer a different configuration. Give the service owner a way to confirm the restricted feature stays disabled after a routine update.

Keep a verification method next to each requirement. The location of a customer-selected storage account may be checked in its configuration. A promise about subcontractor handling may require a signed term and an assurance report. A claim about recovery depends on a test. Where the team cannot independently inspect a path, describe what evidence the vendor can provide and decide whether it is sufficient for the risk.

The distributor could approve the service after the provider demonstrates the agreed configuration, the access procedure and a restore within the permitted boundary. It could keep an optional feature disabled while its data path is assessed. Review the decision when a new entity joins, a provider changes a support process or a recovery destination changes. A useful buying record tells the next owner where the data can go, who can act on it and what to check before the service changes.