Compliance-Referenz · United Arab Emirates

Cloud Security Controls under UAE IA and DESC ISR

Moving to the cloud does not change which controls apply in the UAE. It changes who is able to evidence them. The UAE Information Assurance Regulation reaches cloud estates through its existing technical families, the DESC Information Security Regulation adds expectations specific to Cloud Service Providers serving Dubai government, and the gap between the two sits in the shared responsibility model rather than in either document.

Herausgegeben von
TDRA for the UAE Information Assurance Regulation; Dubai Electronic Security Center for the ISR and its Cloud Service Provider expectations
Zuletzt geprüft

This page sets out what the two UAE regimes ask of a cloud estate, which side of the shared responsibility line each control falls on, and how data residency is actually determined. It is written for the decision that comes before an assessment: whether an architecture can be evidenced at all.

Short answer. Cloud does not create a separate control set in the UAE. Under the UAE Information Assurance Regulation the same 188 controls apply, with the technical families T1 to T9 reaching cloud infrastructure as they reach any other infrastructure. Under the DESC Information Security Regulation, providers serving Dubai government entities carry additional expectations on location, tenancy isolation, operational transparency and inspection rights. What changes in both cases is evidence: a control operated by your provider is still a control you are assessed on, and the only routes to evidencing it are contractual or an attestation the provider already publishes. Residency is decided by data classification and by the contracting entity, not by a blanket rule.

UAE IA

Which Control Families Reach the Cloud

The regulation does not carve out a cloud annex. Its 15 families apply to the estate as a whole, and for a cloud-hosted service the technical families are where the assessment concentrates. The identifiers below are the ones most often contested in a cloud engagement, because each has a version that you operate and a version your provider operates. The complete control set is reproduced on our UAE IA (NESA) reference page.

Bereit, Ihre
Unternehmensinfrastruktur abzusichern?

Vereinbaren Sie ein technisches Briefing. Kein Sales-Pitch, nur Architekten und Ihr Team.

T1, asset management

Ephemeral infrastructure defeats an inventory built for servers. Cloud accounts, subscriptions, managed services and the data stores inside them all have to appear, and an inventory that is refreshed by hand will be stale at assessment.

T3, access control

Two identity planes now exist: the one inside your workloads and the one that administers the cloud tenancy itself. Assessments routinely find the second ungoverned, with standing administrative access and no review record.

T5, communications and network security

Segmentation expressed as security groups and policy rather than as subnets, and evidence that the policy in force matches the policy approved.

T7, monitoring and logging

Control plane logs matter as much as workload logs, and retention has to survive the assessment period. Default retention on managed services is frequently shorter than the window an assessor will ask about.

T8, cryptography and key management

Who holds the keys is the question, not whether encryption is enabled. Provider managed keys, customer managed keys and externally held keys produce three different answers to the same control.

M5 and supplier assurance

The provider is a supplier. Their attestations, their scope, and what happens when the scope changes all belong in your supplier assurance record rather than in a procurement folder.

DESC

The Cloud Service Provider Expectations

Where a Dubai government entity is involved, the Dubai Electronic Security Center applies expectations specific to Cloud Service Providers on top of the ISR control set. They are assessed against the service actually being sold, in the region it is sold from, which is why a provider holding strong international certifications can still fall short: those certifications answer whether a security programme exists, not whether this service in this region meets Dubai's conditions.

Four themes account for most of the work. Location, meaning where data and its backups physically reside and who can reach them. Isolation, meaning what separates one tenant from another and how that separation is demonstrated rather than asserted. Operational transparency, meaning what the government entity can see about incidents, changes and personnel with access. And inspection, meaning what rights the entity or the regulator holds to examine the service, which has to be in the contract because it cannot be retrofitted. The regulation itself is summarised on our DESC ISR reference page.

Residency

Where the Data Has to Live

Vendor summaries state a flat rule that the source documents do not. Residency in the UAE is determined by the classification of the data and by the requirements of the contracting entity, layered with sector rules and, for personal data, the transfer conditions of the UAE PDPL. Government data carries the tightest expectations, and a Dubai government contract may specify residency directly regardless of what the general regime would allow.

The practical sequence is to classify first, establish the contracting entity's position in writing second, and design the architecture third. Doing it in the other order produces the most expensive category of finding, one that cannot be remediated with a control because it requires a migration. Backups, disaster recovery regions, log destinations and support access paths are where residency assumptions break most often, since each can quietly place data outside the region the primary service sits in.

The shared responsibility model is a document you write, not one the provider gives you. Providers publish a division of duties for their platform. Mapping that division onto the specific control identifiers you are assessed against is your work, and the controls that fall between the two descriptions are exactly the ones an assessment finds unowned.

UAE cloud controls: common questions

Do the UAE IA (NESA) controls apply to cloud workloads?

Yes, without modification. There is no cloud carve-out and no separate cloud control set. The same 188 controls apply, with the technical families T1 to T9 reaching cloud infrastructure exactly as they reach on-premise infrastructure. What differs is evidence: several controls are operated by the provider, and you are still assessed on them, so the evidence has to come through a contract or a published attestation.

What is the DESC Cloud Service Provider Security Standard?

Expectations DESC publishes for cloud service providers serving Dubai government entities, applied on top of the ISR. They concentrate on location, tenancy isolation, operational transparency and inspection rights, assessed against the specific service and region rather than against a general security programme. For a provider it is a market entry requirement; for a buyer the provider's position on it forms part of your own evidence pack.

Does our data have to stay inside the UAE?

It depends on the classification of the data and on the contracting entity, not on a single blanket rule. Government data carries the tightest expectations and a government contract may specify residency outright. Personal data adds the transfer conditions of the PDPL on top, and sector regulators add their own. Establish the position in writing before committing to an architecture, and check backups, disaster recovery regions, log destinations and support access separately, because those are where residency assumptions usually break.

Can a hyperscale provider satisfy these requirements?

Often yes, and the answer is per service and per region rather than per provider. A provider may meet the conditions on its UAE regions and specific services while a managed service you also use processes or stores data elsewhere. The assessment is of the architecture you deployed, so the useful question is which services in which regions, not which logo is on the contract.

Who evidences a control the provider operates?

You do, using what the provider gives you. In practice that means a current attestation whose scope covers the service and region in use, contractual commitments where no attestation exists, and your own evidence for the part of the control that sits on your side of the line. A control where neither side holds evidence is a finding, and it is the most common one in a first cloud assessment.

We are already ISO 27001 certified in the cloud. Is that enough?

It is a strong start for the management families and it does not answer the UAE-specific questions. ISO 27001 certifies that a management system exists and operates; it does not address residency expectations, the DESC conditions for Dubai government work, or the specific technical control identifiers you will be scored against. Expect the mapping to transfer and the gaps to concentrate in evidence detail and in the cloud responsibility split.

Related

Where We Do This Work

Gap analysis

All 188 controls tested against evidence and scored by tier, in four to six weeks. NESA gap analysis in the UAE.

Implementation

Closing what a gap report found, in the order an assessment expects. NESA implementation in the UAE.

Assessment

Control-by-control gap assessment against this framework, evidenced finding by finding. Information security assessment in Dubai.

Consulting

Regulatory scoping, threat modelling and zero-trust architecture for groups operating in the Emirates. Cyber security consulting in Dubai.

Governance

One control set mapped to every framework that binds you, with the evidence pipeline behind it. IT security governance in the UAE.