NESA Compliance Requirements: UAE IAS Controls, Domains Explained

What Are the NESA Compliance Requirements?

NESA compliance is built on a single technical document: the UAE Information Assurance Standards (IAS) a national cybersecurity framework developed by the National Electronic Security Authority (now the UAE Signals Intelligence Agency, SIA). The IAS defines exactly what organisations must implement to protect the UAE's critical information infrastructure.

At its core, the framework contains 188 security controls spanning organisational governance and technical defence. These controls are divided into two families — management and technical and assigned priority tiers from P1 (mandatory, implement first) to P4 (risk-based, implement as determined by assessment). The 188 controls break down into 700 sub-controls in total: 136 mandatory sub-controls and 564 risk-assessment-based sub-controls.

This page explains the requirements what each domain covers, which controls are mandatory, and what documentation auditors expect. If you need the audit process, see NESA Audit & Assessment Process →.

The Two Control Families: Management vs Technical

Before looking at individual domains, it helps to understand how NESA structures the 188 controls.

Management Controls (60 controls) cover strategic and governance requirements: information security policy, risk management, organisational roles, supplier relationships, compliance oversight, and incident management governance. Of the 60 management controls, 35 are "always applicable" — meaning they are mandatory regardless of the organisation's risk assessment outcome. These are the non-negotiable baseline.

Technical Controls (128 controls) cover operational and technical implementation: access control, cryptography, network security, application security, endpoint protection, logging, and vulnerability management. None of the technical controls are classified as "always applicable" — their applicability is determined by the organisation's risk assessment. However, once a technical control is determined to be applicable, compliance is mandatory regardless of priority level.

This distinction matters in practice: an organisation cannot opt out of technical controls by claiming low risk the risk assessment determines which technical controls apply, not whether to apply them.

Priority Tiers: P1, P2, P3, P4 Explained

The IAS assigns every control a priority level to guide implementation sequencing. All applicable controls across all priority levels are ultimately mandatory priority only indicates the order of implementation.

The P1 rule: P1 controls are the only tier that cannot be demoted. Organisations may re-prioritise P2, P3, and P4 controls based on their risk assessment, but P1 controls may only be augmented — never reduced. In practice, demonstrating P1 compliance is the first gate in any NESA audit or procurement review.

What P1 controls address: The 39 P1 controls were selected because NESA's threat analysis identified them as mitigating the highest proportion of real-world attacks against UAE critical infrastructure — ransomware, credential theft, phishing, lateral movement, and data exfiltration. A mature P1 implementation is not a compliance exercise; it is effective cyber hygiene.

The 12 Control Domains: What Each Requires

The 188 controls are organised into domains that map to the management/technical split. Below is a reference breakdown of each domain, its scope, and the documentation typically required by auditors.

Domain M1 — Information Security Management

Family: Management Scope: Establishing the Information Security Management System (ISMS) foundation. Requires a formal information security policy approved by senior management, defined security roles and responsibilities, and an ISMS scope document covering all critical services and supporting infrastructure.

What auditors look for:

• Signed information security policy (board or senior leadership approval)
• ISMS scope statement defining critical services and boundaries
• Roles and responsibilities matrix mapping security functions to named positions
• Evidence of management review — meeting minutes showing periodic ISMS review

Common gap: Policy exists on paper but has not been reviewed or updated in over 12 months. Auditors will request the version history and approval records.

Domain M2 — Risk Management

Family: Management Scope: The risk management process is one of the most scrutinised domains. Requires a documented risk methodology, formal risk assessment covering identified threats and vulnerabilities, risk treatment decisions, and a risk register maintained and reviewed regularly. The IAS risk assessment requirements closely follow ISO 27005.

What auditors look for:

• Risk methodology document (context, criteria, assessment method)
• Risk register with identified threats, vulnerabilities, likelihood, impact, and risk level
• Risk treatment plan with assigned owners and target dates
• Evidence of risk assessment review — at minimum annually, or after significant changes

Common gap: Risk assessments performed once during initial implementation and never updated. The IAS requires ongoing monitoring and regular review. A static risk register from two years ago will not pass audit.

Domain M3 — Human Resources Security

Family: Management Scope: Security requirements before, during, and after employment. Covers background screening procedures, employment contract security clauses, security awareness training, and exit procedures including access revocation.

What auditors look for:

• Screening procedure document (background check criteria and process)
• Employment contracts or appendices containing security obligations
• Security awareness training records — dates, attendees, content
• Offboarding procedure with access revocation checklist and evidence

Common gap: Training records exist but cannot be tied to specific employees and dates. Auditors require individual-level evidence, not just a training programme description.

Domain M4 — Asset Management

Family: Management Scope: Comprehensive inventory of all information assets including hardware, software, data, and supporting services. Requires asset classification (by sensitivity and criticality), defined ownership, and procedures for acceptable use and disposal.

What auditors look for:

• Asset inventory/register (current, with owner, classification, and location)
• Asset classification scheme (at minimum: public, internal, confidential, restricted)
• Acceptable use policy
• Secure disposal procedure with evidence of disposal records

Common gap: Asset inventories that include IT hardware but omit data assets, cloud services, and third-party systems. NESA considers information not just hardware — an asset requiring classification and protection.

Domain M5 — Third-Party and Supplier Security

Family: Management Scope: Security requirements for third-party relationships. Covers supplier assessments before engagement, contractual security requirements, ongoing supplier monitoring, and procedures for supplier offboarding. Particularly relevant for cloud service providers and outsourced IT.

What auditors look for:

• Supplier register with security classification
• Contract templates or security schedules containing minimum security requirements
• Evidence of supplier security assessments (questionnaires, certifications, audit rights)
• Procedure for reviewing supplier security performance

Common gap: Contracts with cloud providers and SaaS vendors that contain no security requirements. Many UAE organisations use major cloud platforms without any formal security assessment or contractual security clause.

Domain M6 — Internal Audit and Compliance

Family: Management Scope: Internal audit programme to verify that security controls are operating effectively. Requires an audit plan, qualified auditors (internal or external), documented findings, and a tracking system for remediation of audit findings.

What auditors look for:

• Internal audit schedule or programme
• Completed audit reports with findings and remediation tracking
• Evidence that findings have been addressed within agreed timelines
• Independence of internal auditors from the functions they audit

Common gap: Internal audits performed by the same team responsible for implementing controls. NESA requires independence — the auditor cannot audit their own work.

Domain T1 — Access Control

Family: Technical | P1 controls included Scope: One of the most heavily P1-weighted domains. Covers identity and access management across all systems: user provisioning and de-provisioning, privileged access management, password requirements, multi-factor authentication, and access reviews. The P1 controls specifically mandate controls against credential-based attacks — consistently among the highest-frequency UAE threat vectors.

What auditors look for:

• Access control policy
• User provisioning and de-provisioning procedures with evidence of timely execution
• Privileged account inventory and access review records (minimum quarterly for privileged accounts)
• MFA implementation evidence for remote access and privileged systems
• Password policy with enforcement evidence (configuration screenshots)

Common gap: Orphaned accounts — former employee or contractor accounts that remain active after offboarding. Auditors will check access review frequency and compare against HR termination records.

Domain T2 — Cryptography

Family: Technical Scope: Use of cryptographic controls to protect data in transit and at rest. Requires a cryptography policy, key management procedures, approved algorithm standards, and evidence of implementation across critical data stores and transmission channels.

What auditors look for:

• Cryptography policy specifying approved algorithms and key lengths
• Key management procedure (generation, storage, rotation, revocation, destruction)
• Evidence of encryption on data at rest (databases, laptops, removable media)
• Evidence of encryption in transit (TLS configuration, certificate management)

Common gap: Outdated cipher suites and TLS versions in production environments. Many organisations have a cryptography policy but have not audited actual configurations against it. SSL/TLS scanner output showing SHA-1 or TLS 1.0 in use will immediately flag.

Domain T3 — Physical and Environmental Security

Family: Technical Scope: Physical security of facilities housing critical information systems. Covers access control to secure areas, environmental controls (fire suppression, temperature, power), clean desk and clear screen policies, and secure disposal of physical media.

What auditors look for:

• Physical access control procedures and records (visitor logs, access logs for data centres)
• Environmental monitoring records (temperature, power, UPS test logs)
• Clean desk and clear screen policy with evidence of enforcement
• Physical media disposal records

Common gap: Data centre or server room access logs that exist but are not reviewed. Having logging without evidence of review does not demonstrate a functioning control.

Domain T4 — Communications and Network Security

Family: Technical | P1 controls included Scope: Network architecture, segmentation, perimeter controls, remote access security, and monitoring of network traffic. P1 controls in this domain specifically mandate network monitoring and detection capabilities — passive network without monitoring does not meet NESA requirements.

What auditors look for:

• Network architecture diagram (current, showing segmentation, perimeter controls, DMZ)
• Firewall ruleset review evidence (showing periodic review and approval of rules)
• Remote access policy and implementation evidence (VPN, MFA)
• Network monitoring capability — SIEM or equivalent with evidence of alert review

Common gap: Network diagrams that are outdated or show a flat network with no segmentation. NESA expects network segmentation for critical systems. A diagram showing everything on the same VLAN will require remediation.

Domain T5 — System Acquisition, Development, and Maintenance

Family: Technical Scope: Security requirements throughout the system lifecycle from procurement through development to maintenance. Covers secure development standards, change management procedures, patch management, and security testing of applications before deployment.

What auditors look for:

• Secure development lifecycle (SDLC) policy or procedure
• Change management procedure with security review steps
• Patch management policy with SLA definitions and evidence of compliance
• Evidence of security testing before production deployment (penetration test reports, code review)

Common gap (P1): Patch management is a P1 control, and patch evidence is one of the first things auditors review. Organisations without documented SLAs for critical patch deployment — and evidence of meeting those SLAs — consistently fail this domain.

Domain T6 — Incident Management

Family: Technical | P1 controls included Scope: Capability to detect, respond to, and recover from information security incidents. P1 controls mandate that organisations have a documented incident response plan, defined roles, tested procedures, and a mechanism for reporting incidents to NESA and sector regulators.

What auditors look for:

• Incident response policy and procedure
• Incident response team roster with defined roles
• Evidence of testing — tabletop exercise records or drill documentation
• Incident log showing incidents recorded, categorised, and closed
• Escalation procedure for reporting to sector regulator and SIA

Common gap: Incident response plans that have never been tested. Having a documented IR plan is necessary but not sufficient — NESA expects evidence of exercises. An untested plan is not a functioning control.

Domain T7 — Business Continuity and Disaster Recovery

Family: Technical | P1 controls included Scope: Ensuring continuity of critical services through disruption. Covers Business Impact Analysis (BIA), Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO), backup procedures, and tested recovery plans.

What auditors look for:

• Business Impact Analysis identifying critical services and acceptable downtime
• BCP/DRP documentation with defined RTO/RPO targets
• Backup procedure with evidence of execution (backup logs)
• Recovery test records — actual restoration tests, not just backup confirmation
• BCP/DRP test records (minimum annual)

Common gap: Backups run successfully but recovery has never been tested. Backup logs prove data is being copied; they do not prove it can be restored. Auditors will request evidence of actual restore tests with defined success criteria.

P1 Controls by Domain: Quick Reference

The following table summarises which domains contain P1 (mandatory) controls, and the primary P1 focus area in each.

Sub-Control Breakdown: Mandatory vs Risk-Based

Understanding the distinction between mandatory and risk-based sub-controls is essential for scoping a NESA compliance programme correctly.

136 mandatory sub-controls apply to all in-scope organisations regardless of their risk assessment outcomes. These are the controls auditors will verify without exception. They sit predominantly within the management control family and the P1 tier of technical controls.

564 risk-based sub-controls apply if the organisation's risk assessment identifies the relevant threat as applicable. This does not mean they are optional — once a control is determined to apply, it is mandatory. The risk assessment eliminates controls only when the associated threat is genuinely not applicable to the organisation's context (for example, a cloud-native organisation with no physical media may legitimately exclude certain physical media disposal sub-controls after documenting the rationale).

In practice, most UAE organisations in scope will find that a large proportion of the 564 risk-based sub-controls apply. The risk assessment process is not a mechanism to reduce compliance obligations — it is a mechanism to ensure the right controls are applied with appropriate depth.

Documentation Requirements Summary

Across all domains, NESA auditors will request evidence in three categories:

Policy documents: Written policies for each domain — IS policy, acceptable use, access control, cryptography, patch management, incident response, BCP, supplier security. These must be formally approved, version-controlled, and reviewed within the past 12 months.

Procedures: Operational procedures describing how each policy requirement is implemented. Policies state what must happen; procedures describe how. Both are required.

Evidence of operation: Logs, records, screenshots, and reports demonstrating that controls are working. This is where most organisations fail — they have documentation but cannot prove the documented controls are actually functioning. Evidence categories include: access review records, patch logs with SLA compliance data, incident logs, backup and recovery test records, training records, audit reports, and penetration test reports.

Common Control Gaps by Domain (What Fails Most Often)

Based on NESA compliance assessments across UAE organisations, these are the most frequently identified gaps at the control level:

T1 Access Control — Orphaned accounts, no formal privileged access review, MFA not enforced for remote access. Accounts belonging to former employees or contractors remain active. Privileged accounts reviewed annually rather than quarterly.

M2 Risk Management — Risk register treated as a one-time document rather than a live register. Risks not re-assessed after significant infrastructure changes, cloud migrations, or new system deployments.

T5 Patch Management (P1) — No documented SLA for critical patches. Patches applied ad hoc without recording completion dates or exceptions. Evidence trail insufficient for audit.

T6 Incident Management (P1) — Incident response plan exists but has not been exercised. No incident log maintained. No procedure for reporting to sector regulator within required timeframes.

T7 Business Continuity (P1) — Backups running but no restoration test records. BIA not updated after organisational changes. RTO/RPO defined but no evidence they have been tested.

M5 Supplier Security — Cloud and SaaS vendor contracts containing no security requirements. No supplier risk register. No evidence of ongoing supplier security monitoring.

What This Page Doesn't Cover

These requirements define what NESA compliance requires at the control level. Two related questions are covered in separate guides:

How does the NESA audit actually work? — assessment phases, auditor roles, evidence submission, timeline, and what happens after the audit. See NESA Audit & Assessment Process →

How do you implement these controls? — gap assessment methodology, implementation sequencing, documentation templates, and how SecurityWall supports the implementation programme. See NESA Implementation Services →

How SecurityWall Supports NESA Compliance Requirements

SecurityWall provides end-to-end NESA compliance support for UAE organisations — from initial gap assessment against the 188 controls through implementation, penetration testing (required for T5 and T6 domains), and audit preparation.

Our assessments are mapped directly to the IAS control framework, with findings presented at the sub-control level and prioritised by P1, P2, P3, and P4. Gap reports include evidence checklists for each control domain so your team knows exactly what documentation is required before an auditor arrives.

Book a NESA Gap Assessment →