Dubai DESC Information Security Regulation (ISR)
The Information Security Regulation is issued by the Dubai Electronic Security Center and is mandatory for Dubai government and semi-government entities, and for the suppliers, cloud providers and managed service providers that handle their data. It is a control framework and an assessment regime rather than a certifiable standard.
ISR is the regulation that decides whether your organisation can hold Dubai government work. It is enforced through assessment rather than certification, and non-conformity is a procurement problem before it is a security problem.
Have DESC ISR assessed against evidence Scope, deliverables and what you receive
Who ISR Binds
Government and semi-government bodies in the Emirate of Dubai are directly in scope and are assessed against the regulation.
Organisations that provide services to, or handle data on behalf of, Dubai government entities inherit the obligation contractually. This is how most private companies encounter ISR.
Cloud service providers and data centre operators serving Dubai government carry additional requirements around location, isolation and operational transparency.
Organisations running monitoring or response services for in-scope entities are assessed on the operations they perform, not just on their own corporate controls.
ISR is not a certification. There is no certificate to hang on the wall in the way ISO 27001 provides one. Conformity is demonstrated through assessment and evidence, and the practical consequence of failure is exclusion from Dubai government procurement.
enterprise infrastructure?
Schedule a technical briefing. No sales pitch, just architects and your team.
ISR v2 and ISR v3
ISR v2 established the control set most organisations in Dubai first encountered. DESC has since released ISR v3, which restructures the requirements into a broader set of security domains and pulls supply chain and third-party risk management into a much more prominent position, alongside explicit treatment of cloud, operational technology, and security operations.
If your last gap assessment was against ISR v2, the delta concentrates in four places. Each is a re-scoping rather than a new technology purchase, which is why programmes that budget for tooling and not for evidence work tend to run over.
The largest single movement between the versions. Supplier assurance stops being a procurement checkbox and becomes a control family with its own evidence: what each supplier holds, how it was verified, and what happens when the verification lapses. Organisations that inherited ISR through a contract are usually suppliers themselves, so they end up on both sides of this at once.
A control operated by a cloud provider still has to be evidenced by you. The shared responsibility split has to be written down per control rather than assumed, and the provider attestation that covers it has to actually cover the region and service in use. This is where a v2-era assessment most often turns out to have been optimistic. See our cloud security controls reference.
OT and industrial control environments are addressed explicitly rather than being folded into IT. For entities with any plant, building management or physical infrastructure estate this frequently uncovers systems that were never in the asset inventory the last assessment was scoped from.
Monitoring and response move from being a capability you have to a capability you can show operating: alert handling records, escalation timings, and the incidents that turned out to be nothing. Retention windows are the detail that catches people, because evidence that has aged out cannot be reconstructed.
Check which version binds you before scoping anything. Transition timelines are set by DESC and they move, and the contracting entity may hold you to a version other than the current one. This page does not track those dates; the authoritative answer is at desc.gov.ae or from the entity that imposed the requirement on you.
The Cloud Service Provider Security Standard
Alongside the ISR itself, DESC publishes expectations specific to Cloud Service Providers serving Dubai government entities. They sit on top of the regulation rather than replacing it, and they are the reason a provider can hold a strong international certification and still fail a Dubai engagement: the questions are about location, tenancy isolation, operational transparency and the government entity's ability to inspect, not about whether a security programme exists.
Two consequences follow. If you are a Cloud Service Provider, this is a market entry requirement and it is assessed on the service you actually sell, region by region. If you are a government entity or a supplier buying cloud, the provider's conformity is part of your evidence pack, so it has to be established before the architecture is committed rather than after. The control-level detail for both sides is on our cloud security controls reference.
DESC ISR questions
Does ISR apply to private companies in Dubai?
Not directly, but in practice yes for anyone in the Dubai government supply chain. The regulation binds Dubai government and semi-government entities. Private organisations become subject to it through contract when they provide services to those entities or handle their data, and the requirement is usually discovered during procurement rather than beforehand.
How does ISR relate to ISO 27001?
ISO 27001 gives you a certifiable management system; ISR tells you what Dubai expects inside it. The overlap on policy, risk management, access control and incident response is substantial, so existing ISO 27001 work usually transfers with mapping rather than rework. ISR then adds Dubai-specific expectations that ISO does not cover, and it is assessed rather than certified.
What happens if we fail an ISR assessment?
The consequence is commercial. Non-conformity puts existing contracts with Dubai government entities at risk and can remove you from future procurement, which is usually a larger and faster loss than any regulatory penalty. Remediation plans with agreed timelines are the normal path back.
How long does ISR readiness take?
For an organisation with a functioning ISO 27001 management system, a gap assessment plus targeted remediation typically runs three to six months. Starting without a documented management system, expect nine to twelve, because the policy architecture and the evidence pipeline have to be built before the controls can be assessed at all.
Does our data have to stay in Dubai to satisfy ISR?
Location is treated as a control decision tied to the classification of the data, not as a single blanket rule, and government data carries the tightest expectations. Cloud and hosting providers serving Dubai government entities also carry requirements on isolation and operational transparency that a standard multi-tenant offering may not meet. Confirm the current position with DESC or with the contracting entity before committing to an architecture, because this is one of the areas where public summaries are out of date most often.
Who performs an ISR assessment?
Assessment sits with DESC and with assessors operating under its regime, and in-scope government entities are assessed directly. Suppliers most often encounter it indirectly, through the contracting entity asking for evidence of conformity as a condition of the contract. Preparation work, gap assessment, remediation and evidence assembly, is done by your own team or an advisor; it is separate from the assessment itself.
What evidence should we retain?
Approved policies with version and approval records, the risk register and treatment decisions, access reviews, change records, supplier assessments, monitoring output, incident records including the ones that turned out to be nothing, and proof that training and exercises actually happened. Retention matters as much as collection: evidence reconstructed after the request arrives is what assessments are lost on, since it cannot show the control was operating at the time.
What is the DESC Cloud Service Provider Security Standard?
A set of expectations DESC publishes for cloud service providers serving Dubai government entities, applied on top of the ISR rather than instead of it. It concentrates on the questions a general-purpose certification does not settle: where the data physically sits, how tenancy is isolated, how much operational transparency the government entity gets, and what inspection rights exist. A provider can hold ISO 27001 and a stack of international attestations and still not satisfy it, because the standard asks about this service in this region rather than about the security programme in general. For a buyer, the provider's position on it is part of your own evidence pack, so it belongs in the architecture decision rather than in the assessment that follows it.
Which version of the ISR applies to us, v2 or v3?
Whichever the entity imposing the requirement says, which is not always the current one. DESC sets transition timelines and they move, and a contract signed against v2 may hold you to v2 until it is renewed. Establish this in writing before scoping, because the delta between the versions is large enough that assessing against the wrong one wastes most of the engagement. The differences concentrate in supply chain assurance, cloud responsibility boundaries, operational technology and retained security operations evidence.
We already run a European compliance programme. How much of it transfers?
Most of the control substance, little of the reporting detail. Access control, logging, incident response, supplier management and business continuity map across cleanly from an ISO 27001, NIS2 or DORA programme. What does not transfer is who must be notified, in what timeframe, and in what form, plus the Dubai-specific expectations ISR adds around government data handling. Run one control set with framework-specific views rather than two parallel policy libraries.
Where We Do This Work
Regulatory scoping, threat modelling and zero-trust architecture for groups operating in the Emirates. Cyber security consulting in Dubai.
Control-by-control gap assessment against this framework, evidenced finding by finding. Information security assessment in Dubai.
One control set mapped to every framework that binds you, with the evidence pipeline behind it. IT security governance in the UAE.
Turn DESC ISR requirements into an assessment plan
Agree what will be assessed, what evidence is needed and what you receive before work starts.
Start with the applicable document version, the entities and systems in scope, and any requirements imposed by your customer. Record exclusions and their rationale before testing controls.
Primary source: DESC — Standards & Policies.
Worked example: testing an access review
Illustrative example, not a client result: an access policy requires regular reviews, but the team cannot show a completed review. The assessment records the missing evidence, the affected systems and the risk. The remediation names an owner, a due date and the evidence needed to close the finding: an approved review and records of any access removed.
Map the finding to the control in the version that applies to your organisation. A policy document alone does not establish that a control operates.
| Stage | What we agree | What you receive |
|---|---|---|
| Scope | Entities, frameworks, locations, systems and access constraints. | A written scope, exclusions, evidence request list and delivery schedule. |
| Assessment | Document review, interviews and the technical tests included in the engagement. | Findings linked to evidence, with risk, control references and remediation priorities. |
| Remediation and re-test | Which fixes your team owns, where engineering support is needed and whether re-testing is included. | An action plan with owners and acceptance evidence; re-test results where commissioned. |
What determines the price?
The main drivers are the number of entities and frameworks, the systems and locations sampled, the depth of technical testing, evidence readiness and access restrictions. Implementation and re-testing are scoped explicitly, so a gap assessment is not mistaken for a remediation programme.
Share an architecture overview, the frameworks or customer requirements you need to meet, and your target date. We use these to agree a fixed scope and quote. The proposal states assumptions, exclusions and how changes are priced.