NESA compliance UAE: what a vendor must evidence

NESA compliance UAE questions turn up in vendor questionnaires far more often than the standard itself applies. The document in force is the UAE Information Assurance Standard, version 2.1, dated November 2025 and published by the Cyber Security Council. Its scope clause names ministries, federal authorities and critical information infrastructure entities. It does not name their software suppliers.

That gap is the whole subject of this post. If you are buying software in the UAE, the useful question is not whether your vendor is "NESA compliant" — a claim the standard has no mechanism to confer on a supplier — but whether the vendor can produce the specific artefacts your own obligations require you to collect.

The facts a buyer needs up front:

• Current document: UAE Information Assurance Standard v2.1, November 2025, issued by the Cyber Security Council (CSC).
• Predecessor: UAE Information Assurance Regulation v1.1, March 2020, issued by the then TRA (now TDRA).
• Size of v2.1: 15 control families, 47 sub-families, 134 controls, 449 sub-controls.
• Mandatory core: 70 controls are "Always Applicable"; 39 controls sit at priority P1.
• In scope: ministries and federal authorities, non-government critical information infrastructure entities, and emirate government entities where no emirate programme exists.
• Not in scope: a private company selling software to another private company.

Everything below comes from reading the two published documents and the Dubai legislation, not from a project file. Where a figure in wide circulation does not survive that reading, the section says so.

Who the UAE Information Assurance Standard binds, and who it does not

Section 1.2 of v2.1 is three bullets long and worth quoting rather than paraphrasing. The standard "applies to Ministries & Federal Authorities and Non-Government Critical Information Infrastructure (CII) Entities". Where an emirate runs its own CIIP programme, applicability, enforcement and monitoring for that emirate's government entities and non-government CII entities pass to the emirate lead. In the absence of an emirate programme, the standard applies to emirate government entities.

There is no fourth bullet, and no clause anywhere in the 242-page published standard that brings private suppliers of IT services, cloud infrastructure or managed security into scope in their own right. The predecessor was explicit in the other direction: the 2020 regulation obliged government entities and "other entities identified as critical by TRA", then added that the regulator "highly recommends all entities in the UAE to adopt these on a voluntary basis". Recommended is not required.

One naming point, because it causes real confusion in procurement. The market still calls this NESA, after the National Electronic Security Authority. Neither published version carries that name: v1.1 is a TRA document and v2.1 is a Cyber Security Council document. As of October 2026 we could not establish from primary legislation which body now holds the original NESA mandate, so a vendor claiming a "NESA certificate" is describing something the two published documents do not issue.

NESA compliance UAE: the control counts in circulation are a version behind

The figure you will see most often is 188 controls. It is a real number from a real document — it is just the wrong document. Annex B of v1.1 distributes its controls as 39 at P1, 69 at P2, 35 at P3 and 45 at P4, which totals 188. Annex A of v2.1 gives 134 controls and 449 sub-controls.

	v1.1 (March 2020)	v2.1 (November 2025)
Issuing body	TRA, now TDRA	Cyber Security Council
Control families	15 (6 management, 9 technical)	15 (6 management, 9 technical)
Controls	188	134, plus 449 sub-controls
Always Applicable	34, all management	70, management and technical
P1 controls	39	39
Incident response at P1	No	Yes

Three other claims in circulation do not survive the primary text. There is no "Tier 1" entity class: the word tier does not appear in v2.1 at all, and the standard sorts controls by applicability and priority rather than sorting entities into tiers. There is no five-domain structure; both versions use fifteen families. And the standard mandates no annual independent assessment. Internal audits (M6.2.2) are Always Applicable at P2, the implementation guidance says annual internal audits are "recommended", and where internal independence is unavailable it permits external resources to supply it. Those are different obligations with different costs, and a vendor quoting the stronger one is usually quoting a consultancy page.

The 39 Priority One figure, interestingly, is the one that holds — identically, in both versions, by coincidence of arithmetic rather than continuity. What changed is the contents. Annex C of v2.1 puts identity and access management (T5.2.1 to T5.2.4, T5.3.1, T5.3.3, T5.4.3), vulnerability management (T3.3.2), data at rest and in motion with key management (T3.4.2, T3.4.3) and incident response (T8.1.2, T8.2.1) at P1. In v1.1 the incident-management family sat entirely at P3 and P4. So the common summary that P1 covers access, patching, data protection and incident response is true of v2.1 and false of v1.1 — which is a reason to ask a vendor which version it mapped against.

The strongest case that the standard does reach your vendor

Here is that argument at full strength, because it is not a weak one. Control T6.2.3 requires an in-scope entity to define security requirements before procuring hardware and software, to evaluate products against them before purchase, to complete tests before accepting a system into production, and — per criticality — to require a software or hardware bill of materials from the third party. T6.2.4 tells the entity to require that suppliers "pass these requirements down to their sub-contractors". T6.2.2 says the entity shall assess a third party's security posture during selection, full stop.

Read together, an in-scope buyer cannot lawfully claim compliance while buying from a vendor that cannot answer. Functionally, the vendor is bound.

The answer is that it is bound by the contract, not by the standard, and the difference decides three practical things. The Cyber Security Council's compliance relationship runs to the implementing entity, which reports through its sector regulator or emirate lead; a supplier that fails a security assessment loses a deal rather than breaching a regulation. Liability therefore sits where the contract puts it, which is negotiable in a way a statutory duty is not. And the controls a supplier genuinely cannot implement — information classification, the Statement of Applicability, the risk treatment plan — stay with the buyer no matter what the questionnaire implies.

Why the questionnaire is long: T6 flows the standard down by contract

The Third-Party Security family has five controls, and all five are Always Applicable, which is the stronger label of the two: it means they apply regardless of the buyer's risk assessment. Only T6.2.1 sits at P1; the other four are P2. That combination is why a UAE buyer's questionnaire is long even when the purchase is small.

1. T6.2.1, third party risk management. The entity classifies suppliers by the risk they pose to its systems and data, assesses that risk across the supply chain, and monitors it continuously. High-risk suppliers attract enhanced due diligence, periodic vulnerability assessment and penetration testing, and on-site inspection rights.
2. T6.2.2, assessment during onboarding. The guidance names the assessment topics: supplier governance, secure code, secure design and engineering, information security, physical security, monitoring and auditing, and incident response and recovery. That list is why the form has seven sections.
3. T6.2.3, the ICT supply chain. SBOM or HBOM on request, acceptance testing including security testing, assurance through a scheme such as Common Criteria where appropriate, traceability of critical components, and a named alternative supplier in case you stop trading.
4. T6.2.4, security in the agreement. Requirements embedded in the contract, passed down to sub-contractors, with step-in rights, timely incident notification, vulnerability disclosure, a sub-supplier list with notice before any change, and secure return or disposal of data on termination.
5. T6.2.5, monitoring and change. A monitoring programme, audits to verify compliance, logging of third-party access, and notification of changes including new sub-contractors and any change to the physical location of service facilities.

Note what that last item implies about where your infrastructure lives. Where the data may physically sit is a separate regulatory question with its own answer, and a companion post in this series covers UAE data residency; the control here is narrower, and only requires that you tell your client before the location changes.

What a credible answer looks like, and what an evasive one tells you

A vendor that has read the standard answers in control IDs. A vendor that has read a blog answers in adjectives.

What to ask	Credible	Evasive
Which version did you map to?	Names v2.1 of November 2025 and cites control IDs, for example T5.2.3 for privileged access rights	"We are NESA compliant", with no version and no IDs
Who assessed it, and when?	Names the assessor, the date and the systems in scope	A badge, or "our auditors confirmed it"
Which controls are yours and which are ours?	A written split: they hold their own access, pipeline and logging; you hold classification and the Statement of Applicability	"Fully compliant" — a claim over controls only you can implement
Can you produce an SBOM for this deliverable?	A generated SBOM in a named format, refreshed on each release	"We can send a dependency list on request"
Who are your sub-contractors?	A current list, plus a clause promising notice before it changes	Silence, or "we may use partners as needed"
How fast will you tell us about an incident?	A number of hours in the contract, and the named person who makes the call	"Promptly", or "as required by law"

The third row is the one that matters most and the one most often fumbled. A vendor claiming full compliance is claiming controls it cannot hold, which tells you it has not read the document. The honest answer is a split, and on the work we do in DevOps and cloud engineering that split is usually the first artefact worth writing down — before the questionnaire, not in response to it. The same applies to a custom software build, where secure coding (T7.3.1) and security testing in development and acceptance (T7.4.3) are genuinely the builder's, and data classification is genuinely not.

Dubai is a separate instrument, and there the gate is a real one

DESC ISR is not the federal standard under another name. It is issued by the Dubai Electronic Security Center, and the clearest evidence that the two are distinct is that v2.1's own reference list cites "DESC Information Security Regulation v3" as one of the documents it drew on. A framework does not cite itself.

Dubai is also the place where supplier scope is written into law rather than inferred from a control. Law No. (15) of 2024 concerning the Dubai Electronic Security Centre puts its obligations on "a Government Entity or a Critical Non-government Entity" at Article 14. Article 14(8) then forbids such an entity from engaging any private company specialised in electronic security unless that company is certified by DESC, and Article 15(b) permits outsourcing only to a DESC-certified entity. Article 21 gave those governed by the law one year to comply, extendable once.

So the procurement gate is real, and narrow. If you sell penetration testing, incident response or managed security into Dubai government, certification is a legal precondition for your buyer to engage you. If you sell a line-of-business application, it is not — the duty still rests on the buyer, who will move it to you by contract. Those are different conversations and should not be run as one.

A third instrument gets folded into the same questionnaire and should not be. The UAE Personal Data Protection Law, Federal Decree-Law No. 45 of 2021, has been in force since 2 January 2022 and governs the processing of personal data inside or outside the country. It is not a security-controls regime, its exclusions are its own, and an answer about one says nothing about the other. If you want to see the work this applies to, that is set out on our Dubai page.

What to do with this on the next vendor call

Ask for the version and the control IDs first; it takes a minute and separates the vendors who have done the work from the vendors who have bought a badge. Then ask for the responsibility split in writing, because that is the document your own assessor will want and the one nobody produces unprompted.

After that, stop using the questionnaire for things a contract does better. Incident notification in hours, a sub-contractor list with notice before it changes, step-in rights, and secure handover of data at termination are all T6.2.4 items, and all of them are clauses rather than claims. They are also, not coincidentally, the clauses that make a vendor replaceable: lock-in is a reversibility problem rather than a vendor one, and the same paragraph that satisfies your assessor is the paragraph that lets you leave.

And if you are a private company buying from a private company, with no in-scope client anywhere downstream, the honest conclusion is that none of this binds either of you. Ask the questions anyway if they tell you something useful about engineering discipline. Do not let anyone sell you a compliance programme for a standard you are not in scope for.