NCA ECC-2 and the UAE IA Standard Overlap More Than You Think — Here's Where
Updated: Sep 4
A PRAECEPTA Cybersecurity Regulatory Intelligence Paper
Audience: [C-SUITE/EXEC] with [TECHNICAL] annexes | Jurisdictions: Kingdom of Saudi Arabia; United Arab Emirates
Executive Summary
Most GCC dual-market organisations run two compliance programmes: one for the Saudi National Cybersecurity Authority's Essential Cybersecurity Controls, and one for the UAE Information Assurance Standard. They staff them separately, evidence them separately, and audit them separately. In our assessment, this is one of the most expensive avoidable inefficiencies in regional cyber governance.
At the level of control intent, ECC-2:2024 and UAE IA v2 converge to a very high degree. Both are ISO/IEC 27001:2022-rebased, both organise around governance-plus-technical-defence-plus-resilience, and both have converged in their latest revisions on the same emerging-risk agenda: cloud, third-party and supply chain, secure development. A well-built control library serves both.
But — and this is the part that gets organisations into trouble — the overlap is at the control layer, not the obligation layer. The two frameworks differ fundamentally in what triggers a control's applicability, what constitutes acceptable evidence, which regulator adjudicates, and which controls are legally non-transferable across the border. Teams that mistake control-text similarity for regulatory equivalence commit what we term the Compliance Arbitrage Fallacy: harmonising the easy 85% while silently failing the 15% that carries the enforcement risk.
This paper maps the genuine overlap, isolates the "false friends," and proposes a Single Control, Dual Evidence operating model.
1. The Frameworks as They Now Stand
Both baselines were revised recently. Any harmonisation work built on the prior versions is now structurally out of date.
NCA ECC-2:2024 (KSA) | UAE IA Standard v2 (2025) | |
Issuing authority | National Cybersecurity Authority (NCA) | UAE Cyber Security Council (lineage: NESA / TDRA) |
Predecessor | ECC-1:2018 (5 domains, 29 subdomains, 114 controls) | UAE IA Regulation v1.1 (15 families, ~188 controls) |
Current structure | 4 domains, 28 subdomains, 108 main controls, 92 subcontrols | 15 families (M1–M6, T1–T9), reported 134 controls / 449 sub-controls |
Applicability model | Mandatory minimum baseline; non-applicability requires justification to the regulator | "Always Applicable" vs. "Based on Risk," retaining P1–P4 priority phasing |
International rebase | ISO 27001/27002:2022 aligned | ISO 27001/27002:2022, ISO 27005:2022; NIST SP 800-53 Rev 5 and CIS v8 referenced |
These figures are consistently reported across advisory commentary but should be verified against the controlled-distribution primary document before being used in a client-facing gap assessment. ECC-2:2024 counts are confirmed against the NCA's published document.
Critical structural note: ECC-2:2024's reduction from 114 to 108 controls is not a relaxation. It reflects descoping and reallocation — ICS/OT controls moved out to OTCC-1:2022, and data localisation authority moved to the National Data Management Office. The obligation did not disappear; it changed instrument. Any mapping that reads the reduction as reduced burden is wrong.
2. Where the Overlap Is Real
The following mapping is at the level of control intent and is, in our assessment, defensible for control-library consolidation. It is not defensible as an evidence substitution matrix — see Section 3.
2.1 Governance Layer
ECC-2:2024 Subdomain | UAE IA v2 Family | Convergence |
1-1 Cybersecurity Strategy | M1 Strategy and Planning | High |
1-2 Cybersecurity Management | M1 / M6 | High |
1-3 Policies and Procedures | M1 / M5 Compliance | High |
1-5 Cybersecurity Risk Management | M2 Information Security Risk Management | High — both now ISO 27005:2022-consistent |
1-6 Cybersecurity in IT Project Management | T7 Acquisition, Development and Maintenance | Moderate–High |
1-7 Compliance with Regulations | M5 Compliance | High |
1-8 Periodic Review and Audit | M6 Performance Evaluation and Improvement | High |
1-9 Human Resources | M4 Human Resources Security | High (with one major exception — Section 3.3) |
1-10 Awareness and Training | M3 Awareness and Training | Very high |
2.2 Defence Layer
ECC-2:2024 Subdomain | UAE IA v2 Family | Convergence |
2-1 Asset Management | T1 Asset Management | Very high |
2-2 Identity and Access Management | T5 Access Control | Very high |
2-3 Information System & Processing Facilities Protection | T3 Operations Management | High |
2-4 Email Protection | T4 Communications | High — both revisions expanded beyond SPF alone |
2-5 Network Security Management | T4 Communications | Very high |
2-6 Mobile Devices Security | T5 / T1 | Moderate |
2-7 Data and Information Protection | T1 / T3 | Diverges sharply on residency — see 3.2 |
2-8 Cryptography | T3 (cryptographic controls) | High |
2-9 Backup and Recovery Management | T9 Continuity Management | High |
2-10 Vulnerability Management | T3 Operations Management | Very high |
2-11 Penetration Testing | T3 / M6 | High |
2-12 Event Logs and Monitoring Management | T3 Operations Management | Very high |
2-13 Cybersecurity Incident and Threat Management | T8 Incident Management | High — but reporting obligations diverge |
2-14 Physical Security | T2 Physical and Environmental Security | Very high |
2-15 Web Application Security | T7 Acquisition, Development and Maintenance | High |
2.3 Resilience and Third Party
ECC-2:2024 | UAE IA v2 | Convergence |
3-1 Cybersecurity Resilience (BCM aspects) | T9 Information Systems Continuity Management | Very high |
4-1 Third-Party Cybersecurity | T6 Third-Party Security | Very high |
4-2 Cloud Computing and Hosting Cybersecurity | T6 + v2 cloud security additions | Moderate — sovereignty divergence, see 3.2 |
2.4 The Underappreciated Convergence: The 2024–25 Modernisation
The most significant finding is not the static mapping — it is that both regulators modernised in the same direction within roughly twelve months. Both revisions added or materially strengthened cloud security, third-party and supply-chain risk, and secure software development. UAE IA v2 went further, adding explicit AI/ML and IoT coverage.
PRAECEPTA assessment: GCC regulatory baselines are converging on a shared modern control canon. This is a structural trend, not coincidence, and it means harmonisation investment now has a longer useful life than it did under ECC-1 and IA v1.1.
Forward-looking : UAE IA v2 commentary references post-quantum cryptography readiness. ECC-2:2024 does not carry an equivalent explicit provision. Organisations should treat PQC migration planning as a UAE-leading, KSA-lagging indicator and build cryptographic inventory capability now — it will be demanded on both sides of the border within the next revision cycle.
3. Where the Overlap Is Deceptive — The False Friends
This is the section that determines whether harmonisation succeeds or produces a compliance failure.
3.1 The Applicability Trigger Is Not the Same
This is the single most consequential divergence, and it is invisible in any control-text mapping.
ECC-2:2024 operates as a mandatory minimum. The default posture is that controls apply, and exclusion requires justified non-applicability handled through the regulator's process.
UAE IA v2 operates on a bifurcated model: "Always Applicable" controls plus "Based on Risk" controls, with P1–P4 phasing.
Consequence: A control can be legitimately risk-descoped in the UAE and simultaneously mandatory in KSA. Organisations that build a single risk-based scoping engine and apply it to both jurisdictions will systematically under-implement in Saudi Arabia. We have seen this failure mode in shared-service GRC deployments where the UAE risk methodology was adopted as the group standard.
Architectural implication: your control library can be unified. Your applicability engine cannot be. It must be jurisdiction-parameterised.
3.2 Data Residency and Sovereignty — The Trap of the Removed Control
ECC-2:2024 removed data localisation and in-country hosting requirements from the ECC, with that authority moving to the NDMO. This creates a specific and dangerous misreading.
The wrong conclusion: "ECC-2 dropped localisation, so our regional cloud architecture is now simpler."
The correct conclusion: The obligation moved instrument and regulator. It did not weaken. An ECC-2 gap assessment will no longer surface it, which means it will be missed unless you are separately tracking NDMO instruments.
On the UAE side: sovereignty obligations similarly do not live wholly inside IA v2. They are distributed across cloud policy, sectoral regulation, and — critically — the separate legal regimes of DIFC (DP Law 2020) and ADGM (DP Regulations 2021), which are distinct jurisdictions from onshore UAE.
Jurisdiction conflict flag: a single regional data lake serving KSA and UAE entities can be simultaneously compliant with both ECC-2 and IA v2 as control sets while breaching NDMO instruments, DIFC/ADGM transfer rules, or KSA PDPL 2021 cross-border provisions. Control-set compliance is not data-sovereignty compliance. These must be assessed as separate workstreams.
3.3 Saudization — The Non-Transferable Control
ECC-2:2024 expanded Saudization requirements from senior cybersecurity roles to all cybersecurity roles. There is no UAE IA analogue.
This is, in our view, the most underestimated control in the GCC regulatory landscape, because it is a workforce-composition control with direct architectural consequences:
A consolidated regional SOC in Dubai or Riyadh serving both markets may be structurally non-compliant.
Follow-the-sun models with offshore tier-1 analysts touching Saudi in-scope systems require careful review.
Managed security service contracts must be examined for nationality-composition obligations, not merely SLA and control coverage.
PRAECEPTA position: Saudization is not an HR matter to be delegated. It is a SOC architecture and sourcing constraint and belongs in the target operating model design, at the same decision layer as tooling and telemetry.
3.4 OT/ICS — Different Regulatory Topologies
ECC-2:2024 removed OT/ICS as an ECC domain, relocating it to OTCC-1:2022 as a dedicated instrument. The UAE does not mirror this topology; OT obligations are handled within IA v2 alongside sector-specific regulators and critical-infrastructure authorities.
Consequence for energy, utilities, and industrial operators: you cannot run a single OT control set. A KSA refinery and a UAE refinery in the same group face structurally different regulatory instruments governing the same Purdue Level 2–3 assets. Harmonise the IEC 62443 engineering baseline; do not harmonise the compliance mapping.
3.5 Incident Reporting — Same Control, Different Clock
Both frameworks mandate incident management (ECC 2-13; IA v2 T8) and the control text is highly similar. Notification obligations are not. Reporting recipients, thresholds, and timelines differ, and in both jurisdictions sectoral regulators — SAMA, CBUAE, and the financial free-zone authorities — impose additional and sometimes shorter obligations that override the general baseline.
We deliberately do not state specific notification windows here. Timelines are the most frequently amended element of both regimes and must be confirmed against the current primary instrument and applicable sectoral overlay at the time of playbook drafting.
Practical control: build one detection and triage capability, and multiple notification decision trees keyed to entity, jurisdiction, and sector. Rehearse the notification decision itself, not just the technical response. In our experience, dual-market organisations fail the notification decision under time pressure far more often than they fail containment.
3.6 The Framework-Family Problem
ECC-2 is one tier of a multi-instrument NCA family — critical systems controls, OT controls, cloud controls, telework and data instruments, and the national cryptographic and strategy layers. UAE IA v2 is a single standard with applicability tiering, supplemented by emirate-level and sectoral overlays including Dubai's DESC regime and Abu Dhabi's health-sector ADHICS.
Consequence: ECC-2 compliance is a floor, and the binding requirement for a critical-infrastructure operator may sit in an entirely different NCA document. Mapping ECC-2 to IA v2 and declaring dual-market readiness is a category error — you have mapped one Saudi tier against the entire UAE stack.
4. The PRAECEPTA Operating Model: Single Control, Dual Evidence
Conventional harmonisation produces a unified control matrix and stops. That is insufficient, because the divergences above are almost entirely in the obligation and evidence layers, not the control layer.
We recommend a four-layer separation.
Layer | Harmonise? | Rationale |
1. Control Library (technical control statements) | Yes — fully | ~85–90% intent convergence. One library, dual-tagged. |
2. Applicability Engine (what applies, to whom, when) | No | ECC mandatory-baseline vs. IA always-applicable/risk-based logic are incompatible. Parameterise by jurisdiction. |
3. Evidence and Assurance (artefacts, assessment route) | No | Different regulators, assessment mechanisms, and certification paths. Tag every artefact to its regime at creation. |
4. Obligation Register (notification, sovereignty, workforce) | No — segregate entirely | Non-transferable obligations. Where enforcement risk actually concentrates. |
Recommended Sequence
Build the unified control library first. Map to ISO 27001:2022 as the pivot, then dual-tag to ECC-2:2024 subdomains and IA v2 families. ISO as intermediary survives future revisions of both.
Parameterise applicability by jurisdiction. Never let one risk-scoping decision propagate across the border unchecked.
Tag evidence at creation, not at audit. Retrofitting regime attribution to an existing artefact repository is the most common source of audit overrun we encounter.
Maintain a segregated Non-Transferable Obligation Register. Saudization, data residency and sovereignty, incident notification, sectoral overlays. Owned at CISO level, reviewed quarterly, with named legal counsel per jurisdiction.
Treat OT separately. Harmonise on IEC 62443 engineering; keep OTCC-1:2022 and UAE OT compliance mappings distinct.
Version-control your regulatory baseline. Both frameworks revised inside twelve months. Assume a rolling revision cycle and diff-assess on issuance rather than at audit.
Expected Outcome
Organisations executing this model should expect meaningful reduction in duplicated control implementation and testing effort, with the saving concentrated in the technical defence domains where convergence is highest. We deliberately do not publish a percentage figure; the realisable saving is highly sensitive to sector, existing GRC tooling maturity, and the extent of critical-systems and OT scope. It should be modelled per engagement, not assumed from a benchmark.
5. Board-Level Framing
[BOARD] The Kingdom and the Emirates are asking us for substantially the same security controls. They are not asking us for the same proof, the same scoping decisions, or the same staffing. We can and should build the control environment once. We must maintain the compliance evidence, the incident notification decisions, and the workforce and data-location obligations separately — because that is precisely where regulatory penalty and enforcement attention sit. Consolidating those to save cost would convert a manageable cost into an unmanageable exposure.
6. Conclusion
The statement that ECC-2 and the UAE IA Standard overlap more than expected is correct — and, in our assessment, materially understated at the control layer. The 2024–25 revisions moved both regulators toward a shared modern control canon, and that convergence is durable enough to justify serious harmonisation investment.
But the strategic insight is the inverse: precisely because the control overlap is so high, the residual divergences are disproportionately dangerous. They hide in plain sight behind near-identical control language. Saudization. The ECC-2 localisation removal that relocated rather than removed an obligation. The bifurcated versus mandatory applicability logic. The OT descoping to a separate instrument. These are not edge cases — they are where enforcement lands.
Harmonise the controls. Segregate the obligations. Never confuse the two.
PRAECEPTA CYBERSECURITY LLC — Regulatory Intelligence Practice
Comments