UAE Information Assurance (NESA / SIA)

Introduction: The UAE Information Assurance Standard

The UAE Information Assurance (IA) Standard is the national cybersecurity baseline that governs how organisations across the Emirates protect information and the systems that process it. Originally published by the National Electronic Security Authority (NESA) and now administered under the UAE Cybersecurity Council, with the Signals Intelligence Agency (SIA) succeeding NESA's operational mandate, the Standard sets out mandatory and optional controls that entities operating critical information infrastructure, government bodies and regulated sectors must implement. This guide is an auditor-grade deep-dive intended for compliance leaders, information security managers, internal audit teams and board sponsors who must plan, execute and evidence a UAE IA assessment. It is written from the perspective of practitioners who have delivered CERT-In empanelled assessments and PCI QSA engagements, and who understand that regulatory language must be translated into concrete, testable evidence.

Throughout this guide we walk through the full architecture of the Standard: its management and technical control families, the threat-based prioritisation model, the four assurance tiers, the scoping method for identifying in-scope information assets, a phased implementation approach, and a master assessment checklist that enumerates every control family with the specific evidence an auditor will expect to see. Our aim is to give you a document you can hand to an implementation team and to an external assessor alike, so that the path from gap analysis to sign-off is unambiguous.

What is the UAE Information Assurance Standard?

The UAE IA Standard is a risk-based information security framework whose purpose is to raise the minimum level of protection applied to information assets held by entities that are important to the national interest. It was created to address a fragmented pre-2012 landscape in which different government and semi-government bodies applied inconsistent security practices, leaving critical infrastructure exposed. The Standard consolidates good practice drawn from international frameworks such as ISO/IEC 27001, ISO/IEC 27002 and the NIST family, and adapts them to the UAE's threat environment, regulatory context and sector-specific concerns.

Two features distinguish the UAE IA Standard from a generic adoption of ISO 27001. First, it is explicitly threat-based: controls are prioritised according to their effectiveness against the threats that most commonly affect UAE entities, so that organisations with limited resources implement the highest-impact controls first. Second, it defines mandatory controls that all in-scope entities must implement regardless of their own risk appetite, alongside a larger body of controls that are applied on the basis of a formal risk assessment. This combination of a non-negotiable floor and a risk-driven ceiling is central to how assessments are scoped and scored.

The Standard is organised into two control layers. Management controls set out the governance, strategy, risk management, awareness, human resources security, compliance and third-party management practices that provide the organisational scaffolding for security. Technical controls address the operational safeguards applied to systems, networks, applications, data and physical environments. Together these layers form a coherent management system that mirrors, but is broader and more prescriptive than, an ISO 27001 Information Security Management System.

The threat-based prioritisation model

A defining characteristic of the UAE IA Standard is that its controls are not treated as an undifferentiated list. Each control is associated with the threats it counters, and threats are ranked according to their prevalence and impact within the UAE operating environment. This allows an entity to sequence its investment so that the controls addressing the most damaging and most frequent threats are implemented first. In practice this means an organisation beginning its journey should not spend its early budget on niche controls that address rare threats while leaving high-frequency threats such as phishing, credential compromise, unpatched vulnerabilities and misconfigured perimeter services unaddressed. Assessors will look for evidence that this prioritisation logic informed the remediation roadmap, and that the roadmap is traceable back to the risk assessment and the mandatory control baseline. Where an entity has deviated from the recommended priority ordering, it must be able to justify that deviation with its own risk data.

The threat model also drives the concept of always-implement, or mandatory, controls. These are the controls judged so fundamental against high-priority threats that no entity is permitted to opt out of them on the basis of a favourable local risk score. The remaining controls are applied selectively, based on the outcome of the entity's own risk assessment, its risk appetite and its assurance tier. Understanding which controls fall into each category is one of the first tasks in any implementation, because it determines the non-negotiable floor around which the rest of the programme is built.

Relationship to the UAE IA Regulation and sector regulators

The IA Standard sits within a wider UAE IA Regulation that establishes governance roles, the entity classification process, reporting obligations and the compliance lifecycle. Sector regulators, including those overseeing energy, finance, telecommunications, health, aviation and government services, may layer additional or more stringent requirements on top of the national baseline. An entity's total obligation is therefore the union of the national IA Standard and any applicable sector supplement, and a competent assessment must reconcile both. It is common for a bank, for example, to be subject simultaneously to the national IA baseline, its central-bank information security regulation and, where it processes cardholder data, to PCI DSS. A mature programme maps all of these obligations onto a single unified control set so that one control implementation satisfies multiple mandates and generates one body of evidence, rather than maintaining parallel and duplicative compliance efforts.

Who must comply with UAE IA?

Applicability is driven by whether an entity owns, operates or supports Critical Information Infrastructure (CII) or is otherwise designated by the competent authority. The scope has widened over successive iterations of the Regulation, and many organisations that supply services to designated entities are pulled in through the supply chain. The table below summarises the principal categories of obligated and affected parties.

Structure of the UAE IA Standard

The Standard is built from control families grouped under the two layers described above. Each family contains a set of controls, and each control decomposes into sub-controls or requirements. Controls carry a priority derived from the threat model and are flagged as mandatory (the compliance floor) or risk-based (applied where the entity's risk assessment justifies them). The following table sets out the control families as they are commonly organised across the management and technical layers. Family names below are descriptive paraphrases; consult the official Standard for authoritative identifiers.

An assessment evaluates each control family for the presence, design adequacy and operating effectiveness of its controls, and rolls the results up to a family-level and programme-level conclusion. Mandatory controls that are absent or ineffective are treated as material findings irrespective of the entity's own risk view.

It is worth clarifying the distinction between a control's design and its operation, because assessment failures cluster around this boundary. Design adequacy asks whether a control, as written and configured, would achieve its objective if it operated as intended: is the access control policy actually enforcing least privilege, does the change process require independent approval, is multi-factor authentication configured for the right population? Operating effectiveness asks whether the control actually worked over the look-back period: were access reviews genuinely performed each quarter, were changes actually approved before deployment, did every privileged login in fact require a second factor? An organisation can have flawless documentation and still fail on operating effectiveness because the records show the control lapsed. This is why the master checklist below pairs every design check with an evidence expectation drawn from operating records rather than from policy alone.

Master assessment checklist

This is the core working section of the guide. It enumerates every control family and, for each, states what an assessor must verify and the typical evidence that demonstrates conformance. Use these tables directly during fieldwork: verify each row against design documentation and then against operating evidence over a defined look-back period. No family is omitted; where the official Standard subdivides a family into many controls, we group the checks so that all requirement areas are represented.

M1 — Strategy and planning

M2 — Information security risk management

M3 — Awareness and training

M4 — Human resources security

M5 — Compliance

M6 — Performance evaluation and improvement

T1 — Asset management

T2 — Physical and environmental security

T3 — Operations management

T4 — Communications and network security

T5 — Access control

T6 — Third-party security

T7 — Systems acquisition, development and maintenance

T8 — Information security incident management

T9 — Business continuity management

Scoping the assessment

Scoping determines which information assets, systems, locations and business processes are subject to the IA controls, and it directly shapes the effort and cost of both implementation and assessment. Under-scoping risks leaving critical assets unprotected and produces findings during regulator review; over-scoping wastes resources and dilutes focus. The scoping exercise should be evidence-led and documented so that it can be defended to an assessor.

1. Identify the essential services and business functions the entity provides that are relevant to the national interest or sector mandate.
2. Map the information assets, applications, systems and data flows that support each essential service, including upstream and downstream dependencies.
3. Determine which of these constitute or support Critical Information Infrastructure and are therefore mandatory in scope.
4. Include the management-layer processes (governance, risk, HR, compliance) that apply across the whole organisation.
5. Identify third parties, cloud services and shared platforms that store, process or transmit in-scope information and define the shared-responsibility boundary.
6. Document scope inclusions and any justified exclusions, and obtain executive and, where required, regulator agreement.

Cloud and shared-platform scoping deserves particular care. Where an in-scope service runs on infrastructure-as-a-service, platform-as-a-service or software-as-a-service, responsibility for controls is split between the entity and the provider along a shared-responsibility boundary that differs for each service model. The entity remains accountable for the overall compliance of the in-scope service even where control operation is delegated to the provider. An assessor will expect a documented shared-responsibility matrix that names, for every relevant control, which party operates it and what evidence is available. Provider attestations, independent audit reports and configuration evidence from the entity's own tenancy together close the assurance gap. Assuming the provider handles security without documenting the boundary is a frequent and avoidable finding.

Implementation approach

A UAE IA implementation is best delivered in phases so that governance is established before technical controls, and so that risk drives prioritisation. The following phased approach has each phase defined by its activities and the deliverables that mark its completion. The sequencing matters: attempting to deploy technical safeguards before the asset inventory, risk assessment and control ownership are in place tends to produce orphaned controls that nobody maintains and that generate no evidence. Establishing the management layer first ensures that every technical control implemented in later phases has an owner, a documented objective and a place in the risk treatment plan.

Phase 1 — Initiation and governance

Activities: secure executive sponsorship, appoint the IA lead and steering committee, confirm in-scope designation with the authority, and define the programme scope and objectives. Deliverables: approved IA policy and strategy, governance charter and RACI, scope statement, and a funded programme plan.

Phase 2 — Risk assessment and gap analysis

Activities: build the asset inventory, apply the risk methodology, assess current controls against the Standard, and identify mandatory controls not yet met. Deliverables: asset register, risk register, control gap analysis and statement of applicability, and a prioritised remediation roadmap.

Phase 3 — Control design and remediation

Activities: design and implement missing controls, starting with mandatory and high-priority threat-based controls, update policies and procedures, and configure technical safeguards. Deliverables: updated policy suite, implemented technical controls, control-owner assignments and updated risk treatment plan.

Phase 4 — Operationalisation and evidence generation

Activities: embed controls into business-as-usual, run awareness, begin logging and monitoring, and generate the operating evidence assessors require over a look-back period. Deliverables: operating records (logs, tickets, reviews), completed awareness campaigns, and populated metrics.

Phase 5 — Internal audit and readiness

Activities: conduct an independent internal audit, remediate findings, and run a mock assessment against the checklist in this guide. Deliverables: internal audit report, corrective action closure evidence and a readiness sign-off.

Phase 6 — Formal assessment and continual improvement

Activities: undergo the formal assessment, respond to findings, and establish the ongoing monitoring and review cadence. Deliverables: assessment report, remediation plan for any residual findings and an established continual improvement cycle.

Maturity and capability model

UAE IA compliance is expressed through assurance tiers that reflect how completely and effectively controls are implemented and operated. Organisations use a capability scale during self-assessment to gauge readiness and to prioritise investment. The table below sets out a five-level capability scale that maps naturally onto the Standard's expectation that mandatory controls are fully embedded and operating.

For mandatory controls, the target is at least Level 3 (Defined) and ideally Level 4 (Managed), because assessors expect these controls to be standardised and evidenced rather than merely present. Risk-based controls are targeted according to the residual risk the entity is willing to accept.

When plotting a maturity uplift plan, resist the temptation to raise every control to Level 5. Optimised operation carries a real cost in tooling, staff and process overhead, and it is only justified where the underlying risk warrants it. A pragmatic target profile sets mandatory and high-priority threat-based controls at Level 4, controls that protect the most sensitive assets at Level 4 or 5, and lower-priority risk-based controls at Level 3. Document this target profile explicitly, because it becomes the yardstick against which the assessment measures gaps, and it demonstrates to the assessor that maturity investment is deliberate and risk-aligned rather than arbitrary. Re-baseline the profile annually so that it tracks changes in the threat landscape and in the entity's asset footprint.

Assessment and audit approach

A defensible assessment follows a consistent sequence from planning through reporting. The steps below describe how a competent assessor structures an engagement against the IA Standard.

1. Plan the engagement: confirm scope, applicable sector supplements, look-back period, assessor independence and the evidence sampling approach.
2. Review documentation: examine policies, procedures, the statement of applicability, risk register and prior audit reports to assess control design.
3. Conduct interviews and walkthroughs: confirm that documented controls reflect actual practice with process owners and operators.
4. Test operating effectiveness: sample records over the look-back period and perform technical validation such as configuration review and scan analysis.
5. Evaluate mandatory controls specifically: treat any absent or ineffective mandatory control as a material finding regardless of risk rating.
6. Rate each control family: assign a capability or conformance rating supported by evidence references.
7. Aggregate results: roll family ratings up to a programme-level conclusion and identify systemic themes.
8. Report findings: document nonconformities with severity, root cause and recommended remediation.
9. Agree remediation and re-test: track corrective actions to closure and re-test critical findings before sign-off.
10. Establish surveillance: define the ongoing monitoring and periodic reassessment cadence.

Evidence request list

The following categorised list is what an assessor typically requests at the start of fieldwork. Preparing these artefacts in advance dramatically shortens the engagement and reduces the number of open items.

• Governance: IA policy and strategy, governance charter, RACI, steering committee minutes, appointment letters.
• Risk: risk methodology, current risk register, risk treatment plan, risk acceptance forms, statement of applicability.
• Asset and classification: asset inventory/CMDB extract, classification policy, sample labelled data, disposal records.
• Access control: access control policy, provisioning/deprovisioning tickets, MFA and password configuration, privileged account inventory, access recertification records.
• Network and operations: network diagrams, firewall rule base and review records, change tickets, backup and restore-test evidence, malware protection status, logging configuration.
• Development and vulnerability: SDLC policy, code review and SAST/DAST results, vulnerability scan reports, patch records, cryptographic policy and key management procedures.
• People: screening records, employment contracts and NDAs, awareness completion reports, role-based training matrix, leaver checklists.
• Third party: vendor risk assessments, contracts with security clauses, SLA and service review reports, third-party access inventory.
• Incident and continuity: incident response plan and playbooks, incident tickets and regulatory notifications, BIA, BCP/DRP, DR test reports.
• Physical: site plans, access-control logs, CCTV coverage, environmental monitoring records.
• Compliance and improvement: legal/regulatory register, internal audit reports, CAPA register, KPI dashboards, management review minutes.

Roles and responsibilities

Clear accountability is a prerequisite for both implementation and a clean assessment. The table below sets out the principal roles in a UAE IA programme and their core responsibilities.

KPIs to track

Metrics turn a static control set into a managed programme and provide the evidence assessors expect at higher capability levels. Track a balanced set covering coverage, timeliness and effectiveness.

• Percentage of mandatory controls fully implemented and operating.
• Percentage of in-scope assets inventoried, owned and classified.
• Awareness training completion rate and phishing simulation click/report rates.
• Mean time to detect and mean time to respond to security incidents.
• Percentage of critical and high vulnerabilities remediated within SLA.
• Patch compliance rate across in-scope systems.
• Percentage of privileged accounts under privileged access management and reviewed on schedule.
• Access recertification completion rate and outstanding excessive-privilege count.
• Backup success rate and restore-test pass rate.
• Third-party assessments completed on time as a percentage of the supplier population.
• Number and ageing of open nonconformities and overdue corrective actions.
• DR/BCP exercises completed against plan and objectives met (RTO/RPO).

Readiness checklist

Use this checklist as a final gate before a formal assessment. Each item should be answerable with concrete evidence, not intent.

• In-scope designation and scope statement are documented and agreed.
• IA policy and strategy are approved by the executive and current.
• Asset inventory is complete, owned and classified.
• Risk assessment is current and the risk treatment plan is being executed.
• All mandatory controls are implemented and generating evidence.
• Access reviews and privileged access controls are operating and evidenced.
• Backups are running and restore tests have passed within the period.
• Vulnerability and patch management meet defined SLAs.
• Awareness training is complete for the current cycle.
• Third-party assessments and contract clauses are in place for in-scope suppliers.
• Incident response plan is tested and regulatory reporting paths are confirmed.
• BCP/DRP are documented and have been exercised.
• An independent internal audit has been completed and findings closed.
• Metrics dashboards and management review minutes are available for the look-back period.

Common gaps

Across UAE IA engagements, the same weaknesses recur. Addressing these early materially improves assessment outcomes.

• Incomplete or stale asset inventories that leave in-scope systems unclassified and unprotected.
• Treating mandatory controls as risk-based and deferring them, then finding they are material at assessment.
• Documented policies with no operating evidence, so controls fail effectiveness testing despite good design.
• Weak privileged access management: shared admin accounts, no session logging and no periodic recertification.
• Backups that run but are never restore-tested, leaving recovery capability unproven.
• Poor network segmentation that pulls out-of-scope systems into scope through unsegmented connectivity.
• Third-party risk managed at onboarding only, with no ongoing monitoring or contract flow-down.
• Incident response plans that exist on paper but are never exercised and lack regulatory notification timelines.
• Awareness treated as a one-off rather than a measured, recurring programme.
• Absence of metrics and management review, keeping the programme stuck at a low capability level.

UAE IA mapped to other frameworks

Because the IA Standard draws on established international frameworks, organisations can reuse existing control implementations and evidence. The mapping below is indicative and helps teams leverage prior ISO or NIST work; it is not a substitute for a control-by-control crosswalk against the official Standard. The value of a crosswalk is twofold. First, it lets an organisation that already holds ISO 27001 certification or has adopted the NIST Cybersecurity Framework identify the delta it must close rather than starting from a blank sheet, which typically compresses the implementation timeline substantially. Second, it enables a single evidence artefact, such as an access recertification record or a vulnerability scan report, to satisfy multiple frameworks at once, reducing the ongoing cost of maintaining several compliance programmes in parallel. The residual work after a crosswalk is usually concentrated in the UAE-specific obligations: the mandatory control baseline that overrides local risk decisions, the regulatory incident-notification timelines, and any sector supplement, none of which map cleanly onto generic international frameworks.

Frequently asked questions

Need help with UAE IA?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.