Organisations serving UAE government and critical infrastructure are asked to prove compliance with "NESA", but the standard behind that name has changed owner and version twice, and many control matrices still map to text that has been replaced. The UAE Information Assurance Standards were first issued by the National Electronic Security Authority (NESA), republished as the UAE Information Assurance Regulation by the Telecommunications and Digital Government Regulatory Authority (TDRA, formerly TRA), and, according to KPMG's analysis, replaced in November 2025 by the UAE IA Standard v2.1 issued by the UAE Cyber Security Council. This guide explains the structure that has stayed stable (management families M1 to M6, technical families T1 to T9, priorities P1 to P4), what applies to whom, where identity and non-human identity controls sit, and how emirate schemes such as the Dubai ISR and Abu Dhabi ADHICS relate. It is for security and compliance teams at government entities, critical infrastructure operators and their suppliers, and for executives who sign off risk acceptance.
Key takeaways
- Check which version you are mapping to. The NESA IAS (2014 era), the TDRA IA Regulation v1.1 (2020) and the UAE IA Standard v2.1 (November 2025, per KPMG) share a structure but differ in content; confirm the current text with your sector regulator.
- The structure is stable. Six management families and nine technical families, with access control in T5, have carried through each version, so existing control IDs such as T5.2.2 Privilege Management remain a useful anchor.
- Priority is not optional. P1 to P4 set implementation order, but all controls that apply to an entity are mandatory regardless of priority.
- Applicability is risk-driven. A core set of controls is always applicable; the rest apply according to the entity's risk assessment, which makes the risk assessment itself a key audit artefact.
- Identity controls carry the most findings. User registration, privilege management, credential management and access reviews (T5.2) apply to service accounts and API credentials as much as to staff.
What it is and who it applies to
The UAE Information Assurance framework sets a minimum level of protection for information assets and the systems that process them. The UAE government portal describes the TDRA regulation as applying to all entities in the UAE, with TDRA designating critical entities under the UAE Critical Information Infrastructure Protection (CIIP) Policy, and those designated entities required to implement it. It covers the use, processing, storage and transmission of information in physical or electronic form, on systems the entity owns, leases or otherwise holds.
Version history
| Version | Issuer | Notes |
|---|---|---|
| UAE Information Assurance Standards (IAS) | National Electronic Security Authority (NESA) | Part of the National Information Assurance Framework under the CIIP Policy; based on ISO/IEC 27001:2005 with additions from ISO/IEC 27002:2013 and NIST; 188 controls (60 management, 128 technical) |
| UAE IA Regulation v1.1 | TRA, now TDRA | Published on the UAE government portal in 2020; the version most existing gap assessments and vendor mappings use |
| UAE IA Standard v2.1 | UAE Cyber Security Council (as reported by KPMG) | Released November 2025 according to KPMG; adds AI, cloud sovereignty, IoT and OT controls and stronger executive accountability |
We could not retrieve the v2.1 text or the Cyber Security Council's policy listing directly when checking in October 2026, so the v2.1 details here are KPMG's summary. Treat them as indicative and obtain the official text from the Council or your sector regulator before scoping an assessment.
Who is in scope
- Federal government: ministries and federal authorities.
- Emirate-level government entities: through emirate programmes, alongside local schemes such as the Dubai ISR.
- Critical information infrastructure operators: entities designated under the CIIP Policy including non-government operators.
- Suppliers: cloud providers, managed service providers and software vendors are pulled in contractually. Third-party security is its own technical family (T6), so expect flow-down clauses and right-to-audit requirements.
- Free zones: financial free zones have their own regulators. ADGM's FSRA, for example, told its firms in October 2025 to stay informed about new Cyber Security Council policies while stating that adherence was not mandatory for them; check your own regulator's position.
Structure and key requirements
The families below come from the NESA IAS as documented by Dionach (2015), and KPMG reports the same six management and nine technical families in v2.1. Control counts per family are from the NESA edition; v2.1 counts differ.
| Management family | Controls (NESA IAS) | Technical family | Controls (NESA IAS) |
|---|---|---|---|
| M1 Strategy and planning | 15 | T1 Asset management | 10 |
| M2 Information security risk management | 11 | T2 Physical and environmental security | 16 |
| M3 Awareness and training | 8 | T3 Operations management | 17 |
| M4 Human resources security | 8 | T4 Communications | 15 |
| M5 Compliance | 13 | T5 Access control | 22 |
| M6 Performance evaluation and improvement | 5 | T6 Third party security | 6 |
| T7 Information systems acquisition, development and maintenance | 25 | ||
| T8 Information security incident management | 13 | ||
| T9 Information security continuity management | 4 |
- Control anatomy: each control has sub-controls that state the requirement, implementation guidance, document requirements and performance indicators. IDs follow family, sub-family, control (for example T5.2.3).
- Priorities: in the NESA edition 39 controls were P1, 69 P2, 35 P3 and 45 P4. Priorities set the order of implementation; priorities other than P1 can shift with the risk assessment, and NESA published a summary of P1 controls ordered by attack mitigation impact.
- Always applicable versus risk-based: in the NESA edition 35 management controls were always applicable and the rest applied according to risk. KPMG reports v2.1 as 70 always-applicable and 64 risk-based controls (134 in total).
- v2.1 additions (per KPMG): documented executive risk acceptance and continuous assurance; resilience against physical events that disrupt digital services; AI governance, lifecycle risk management and secure deployment; cloud requirements on data location, key management, legal control and operational autonomy; expanded IoT and OT controls.
Related Cyber Security Council policies
The Council has also issued national policies that sit beside the standard. FSRA's October 2025 notice lists newly released or updated policies on incident response (including the national incident response plan), information sharing, SOC baseline capabilities and cloud security. KPMG notes that demonstrating compliance with v2.1 is intended to reflect compliance with these underlying policies.
Identity and NHI requirements
Access control is family T5, and its sub-families map closely to ISO/IEC 27002 access control. The IDs below are from v1.1 as cited in a vendor mapping to the TRA regulation, and ADHICS still references T5 controls such as T5.1.1, which confirms the numbering remains in use.
| Control (v1.1) | Requirement area | Non-human identity angle |
|---|---|---|
| T5.2.1 User Registration | Formal registration and de-registration | Register every service account, workload identity and API client with an owner and purpose |
| T5.2.2 Privilege Management | Restrict and control privileged access; includes not granting users domain or local admin rights | Find automation accounts with domain admin or tenant-wide roles; scope them down |
| T5.2.3 User Security Credentials Management | Controlled allocation of passwords and credentials | Vault secrets, keys and tokens; no hard-coded credentials |
| T5.2.4 Review of User Access Rights | Periodic access reviews | Include service accounts and OAuth grants in certification campaigns |
| T5.3.1 Use of Security Credentials | User responsibilities for credentials | Developers must not paste secrets into code, tickets or chat |
| T5.5.1 Secure Log-On Procedures | Controlled log-on | Block interactive log-on for service accounts |
| T5.5.2 User Identification and Authentication | Unique IDs and suitable authentication | Unique identity per workload; certificate or federated tokens over shared passwords |
| T5.5.3 User Credentials Management System | Quality and management of credentials | Rotation and expiry for keys and tokens |
| M4.4.3 Removal of Access Rights | Revoke access on termination or change | Revoke credentials owned by leavers, including tokens and keys they created |
- Privileged access: T5.2.2 is where auditors test admin separation, approval and logging. See the Privileged Access Management Guide.
- Service accounts: registration, ownership and review under T5.2 apply equally to machine accounts. See the Service Account Security Guide.
- Secrets and keys: T7.4.1 Policy on the Use of Cryptographic Controls plus v2.1's cloud key management expectations mean key custody and location must be documented. See the Secrets Management Guide.
- AI agents: v2.1 adds AI governance and secure deployment controls (per KPMG). Agents that act with their own credentials should be registered, scoped and reviewed like any other non-human identity.
Implementation steps
- Confirm the applicable version and regulator. Ask your sector regulator or the emirate programme which version applies and by when. Record the answer: auditors will ask.
- Define scope. List information assets and systems that are in scope, including outsourced and cloud-hosted ones and suppliers under T6.
- Run the risk assessment (M2). It determines which risk-based controls apply, so it must be documented, approved and repeatable. Under v2.1, record executive risk acceptance explicitly.
- Build the applicability statement. Mark every control as always applicable, applicable by risk, or not applicable with a justification.
- Implement P1 first. Work through P1, then P2 to P4, but do not treat lower priorities as optional: applicable controls are mandatory.
- Close identity gaps early. Access control has the most controls of any technical family and is the easiest to test, so fix registration, privilege, credential and review controls in the first phase.
- Pilot evidence collection. Pick one business unit or system, collect evidence for every applicable control, and run an internal audit before the external one.
- Report and improve (M5, M6). Report progress to the sector regulator as required, track performance indicators and feed findings back into the risk assessment.
Rollback: if a hardening change (for example blocking interactive log-on for service accounts) breaks a business process, revert it, record a time-bound risk acceptance and fix the dependency, rather than marking the control not applicable.
Small versus large entities
- Smaller entity or supplier: focus on always-applicable controls and P1, reuse an ISO/IEC 27001 ISMS for M-family evidence, and lean on a cloud provider's attestations for T2 physical controls.
- Large CII operator: expect full scope, sector-specific standards on top, OT coverage under v2.1 and regular regulator reporting. Run continuous control monitoring rather than annual evidence sprints.
Evidence and assessment
Each control carries document requirements and performance indicators, so evidence expectations are relatively predictable. The NESA-era compliance cycle described by practitioners was gap audit, training, risk assessment, implementation and annual compliance audits, with entities reporting to sector regulators who consolidated reporting nationally.
| Evidence type | Examples | Weak evidence to avoid |
|---|---|---|
| Governance (M1, M5, M6) | Approved policy set, roles, compliance register, management review minutes | Unsigned policies copied from a template |
| Risk (M2) | Risk register, methodology, applicability statement, risk acceptance records | A risk register with no link to control selection |
| Access control (T5) | Account inventory with owners, privileged group exports, access review sign-offs, MFA configuration | A statement that "admins use MFA" with no configuration |
| Operations and monitoring (T3) | Log sources, retention settings, alert samples, patch reports | SIEM licence with no use cases |
| Third parties (T6) | Contracts with security clauses, supplier assessments | Supplier questionnaires never reviewed |
Metrics that show it is working
- Percentage of applicable controls implemented, by priority (P1 should reach 100 percent first).
- Service accounts and API credentials with a named owner and in-policy rotation date.
- Privileged accounts protected by MFA and covered by session logging.
- Access reviews completed on time, including non-human identities.
- Open audit findings and their age, by family.
- Percentage of suppliers with completed T6 security assessments.
Mapping to other frameworks
| UAE IA area | ISO/IEC 27001:2022 Annex A | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|---|
| M2 Risk management | Clauses 6.1.2 and 6.1.3 | CA-2, PL-2 | GV.RM-01 |
| M5 Compliance | 5.31, 5.36 | CA-2 | GV.OC-03 |
| T5.2.1 and T5.2.4 registration and review | 5.16, 5.18 | AC-2 | PR.AA-01, PR.AA-05 |
| T5.2.2 Privilege management | 8.2 | AC-6 | PR.AA-05 |
| T5.2.3, T5.5.2, T5.5.3 credentials and authentication | 5.17, 8.5 | IA-2, IA-5 | PR.AA-01 |
| T3 monitoring | 8.15, 8.16 | AU-6, CA-7 | DE.CM-03 |
| T6 Third party security | 5.19 to 5.23 | PL-2 | GV.SC-07 |
- ISO/IEC 27001: the IAS were built on ISO 27001 and 27002, so an ISMS covers much of M1 to M6. See the ISO 27001 Certification Guide.
- Dubai ISR: the Dubai Electronic Security Center (DESC) Information Security Regulation, formalised under Resolution No. 13 of 2012 and maintained under Dubai Law No. 11 of 2014, applies to all Dubai Government Entities and has 13 domains across Governance, Operation and Assurance. Entities run an applicability review to decide which controls apply. DESC also publishes IoT, ICS, electronic biomedical device, connected vehicle and web security standards.
- Abu Dhabi ADHICS: the Department of Health's Abu Dhabi Healthcare Information and Cyber Security Standard V2 (published May 2024, effective August 2024) applies to health sector entities in Abu Dhabi, sorts them into Basic, Transitional, Advanced and Service Provider categories, and tags controls to UAE IA references such as M2.1.1 and T5.1.1.
- Regional peers: see the Global Cybersecurity Regulatory Map for neighbouring regimes.
Common pitfalls
- Mapping to a superseded version: many tools and consultants still map to v1.1 or the NESA IAS. Confirm the version before you buy a control library.
- Treating P3 and P4 as optional: priority sets order, not obligation. An applicable P4 control left undone is a finding.
- A risk assessment that does not drive applicability: if risk-based controls are marked not applicable without a link to the risk register, the applicability statement will not survive audit.
- Human-only access reviews: T5.2.4 reviews that cover staff but skip service accounts, API keys and OAuth integrations leave the most privileged credentials unreviewed.
- Ignoring emirate and sector overlays: a Dubai government entity or an Abu Dhabi health provider has ISR or ADHICS obligations on top of the federal standard.
- Cloud sovereignty assumed: v2.1 (per KPMG) tightens expectations on data location and key management. A UAE region alone does not prove who controls the keys.
Practitioner checklist
- Confirm in writing which UAE IA version and which emirate or sector overlays apply to you.
- Obtain the official text from the Cyber Security Council or your regulator, not a third-party summary.
- Document the M2 risk assessment and use it to build the applicability statement.
- Implement all P1 controls first and schedule P2 to P4 with dates.
- Register every service account, workload identity and API client with an owner (T5.2.1).
- Remove standing domain and local admin rights and evidence privilege management (T5.2.2).
- Vault credentials, set rotation and include non-human identities in access reviews (T5.2.3, T5.2.4).
- Record key custody and data location for cloud services.
- Track performance indicators per control and report progress to the regulator.
Standards and references
- UAE Government Portal: UAE Information Assurance Regulation
- Dubai Electronic Security Center: Standards and policies, including the Information Security Regulation
- Department of Health Abu Dhabi: Abu Dhabi Healthcare Information and Cyber Security Standard (ADHICS) V2
- ADGM FSRA: Notice on updates to national cyber security policies from the UAE Cyber Security Council
- KPMG: A bold step towards cyber resilience (UAE IA Standard v2.1)
- Dionach: NESA UAE Information Assurance Standards
- DETACK: Mapping to the TRA UAE Information Assurance Regulation (vendor document)
- NIST: SP 800-53 Rev. 5
This guide summarises the UAE Information Assurance standards and related emirate schemes as we could confirm them in October 2026 and is not legal advice. Related NHI Mgmt Group resources: Global Cybersecurity Regulatory Map · ISO 27001 Certification Guide · Privileged Access Management Guide · Service Account Security Guide · NIST CSF to ISO 27001 Mapping Guide