A security team serving clients across the Gulf soon finds that "GCC compliance" is not one thing: Saudi Arabia, the UAE, Qatar and Bahrain each set cyber controls through different authorities, with different scopes, assessment models and cloud rules. Saudi Arabia's National Cybersecurity Authority (NCA) publishes mandatory control sets such as the Essential Cybersecurity Controls (ECC) and Cloud Cybersecurity Controls (CCC). The UAE layers a federal Information Assurance standard over emirate rules such as the Dubai Information Security Regulation and Abu Dhabi's healthcare standard. Qatar's National Cyber Security Agency (NCSA) runs a certification scheme against its National Information Assurance (NIA) policy, and Bahrain's National Cyber Security Center works alongside sector regulators such as the Central Bank of Bahrain. This map compares the four side by side: who is bound, what the controls demand, how compliance is proven, how cloud services are treated and where identity and machine credentials are examined. It is written for CISOs, GRC leads and architects at regional groups, and for vendors and managed service providers who inherit these rules through contracts. Countries are listed in the same order throughout; order is not a ranking.
Status line: checked on 14 November 2026 against nca.gov.sa, u.ae, desc.gov.ae, doh.gov.ae, ncsc.gov.bh, bahrain.bh and the Central Bank of Bahrain Rulebook. Qatar's NCSA portal and the UAE Cyber Security Council's policy listing did not serve readable text when checked, so the Qatar and UAE v2.1 points below come from cloud providers' compliance documentation, an ADGM regulator notice and published professional analysis, and are flagged as such. Confirm the current text with the authority before scoping an assessment.
Key takeaways
- Saudi Arabia is the most codified. ECC-2:2024 sets 108 main controls and 92 subcontrols across 4 domains and 28 subdomains, mandatory for government entities, their companies and private operators of critical national infrastructure (CNI), with CCC-2:2024 extending it to cloud providers and tenants.
- The UAE is federal plus emirate. The TDRA Information Assurance Regulation binds entities designated critical under the CIIP Policy, a v2.1 standard was reported in November 2025, and Dubai and Abu Dhabi add their own mandatory standards for government and health entities.
- Qatar is built around certification. NCSA's National Information Security Compliance Framework (NISCF) awards NIA certificates after an audit by an accredited auditor, with data classification levels (C1 to C3 appear in cloud certificates) shaping scope.
- Bahrain's detail sits with sector regulators. The NCSC publishes a 2025-2028 national strategy and guidance; for banks, the Central Bank of Bahrain Rulebook sets hard numbers such as twice-yearly penetration tests and a one-hour incident call.
- One control set can serve all four, with local overlays. Map once to a common baseline, then add Saudi staffing and remote-access location rules, UAE designation and emirate standards, Qatar certification scope and Bahrain sector reporting clocks.
Regulations and frameworks at a glance
| Country | Main instruments | Issuer | Legal force | Current version noted |
|---|---|---|---|---|
| Saudi Arabia | Essential Cybersecurity Controls (ECC); Cloud Cybersecurity Controls (CCC); OT Cybersecurity Controls (OTCC) | National Cybersecurity Authority (NCA) | Mandatory for in-scope entities under Article 10(3) of the NCA statute and High Order No. 57231 | ECC-2:2024 (NCA page last updated 19 July 2026); CCC-2:2024 |
| UAE (federal) | UAE Information Assurance Regulation; UAE IA Standard v2.1 | TDRA (regulation); UAE Cyber Security Council (v2.1, as reported) | Mandatory for entities TDRA designates as critical under the UAE CIIP Policy | Regulation v1.1 (2020); v2.1 reported as released November 2025 |
| UAE (Dubai) | Information Security Regulation (ISR); IoT, ICS, connected vehicle and biomedical device standards | Dubai Electronic Security Center (DESC) | Applies to all Dubai Government Entities; formalised under Resolution No. 13 of 2012, maintained under Dubai Law No. 11 of 2014 | Version not stated on the DESC page |
| UAE (Abu Dhabi health) | Abu Dhabi Healthcare Information and Cyber Security Standard (ADHICS) | Department of Health Abu Dhabi | Applies to any Abu Dhabi entity handling health information | ADHICS V2, published May 2024, effective August 2024 |
| Qatar | National Information Assurance (NIA) policy and NIA certification | National Cyber Security Agency (NCSA), within its NISCF | Policy applies to agencies and their information assets unless exempted by statute; certification awarded by NCSA | NIA v2.1 (as stated in cloud providers' certification documentation) |
| Bahrain | National Cyber Security Strategy 2025-2028; sector rules such as CBB Rulebook module OM-5.5 | National Cyber Security Center (NCSC); Central Bank of Bahrain (CBB) | Strategy is policy; CBB Rulebook is binding on licensees | Strategy 2025-2028; OM-5.5 incident reporting paragraphs amended April 2022 |
For the single-country deep dives, see the Saudi NCA Essential Cybersecurity Controls Guide and the UAE Information Assurance Standards Guide. AI-specific rules in the same countries are covered in Gulf AI Regulation.
Scope: who each regime binds
The biggest practical difference between the four is not the control text but the trigger. A multinational can be fully in scope in one country and only contractually affected in the next.
| Country | Directly bound | Pulled in indirectly | Usually outside |
|---|---|---|---|
| Saudi Arabia (ECC) | Government agencies inside and outside the Kingdom, their affiliated companies, and private entities that own, operate or host CNI | Suppliers, through ECC subdomain 4-1 third-party requirements written into contracts | Other private entities, which the NCA encourages to adopt the controls voluntarily |
| Saudi Arabia (CCC) | Cloud tenants that are in ECC scope and use or plan to use cloud, and cloud providers serving them, whether or not the provider is itself in ECC scope | Sub-processors of in-scope providers | Providers serving only non-Saudi entities abroad or only private entities without CNI links |
| UAE (federal) | Entities designated critical by TDRA under the CIIP Policy | The regulation's stated aim covers all entities in the UAE, and suppliers inherit controls through contracts | Financial free zone firms where their regulator says otherwise: ADGM's FSRA stated in October 2025 that adherence to new Cyber Security Council policies was not mandatory for its firms |
| UAE (emirates) | Dubai Government Entities (ISR); Dubai government and semi-government entities (IoT standard); Abu Dhabi health entities, payers and health technology providers (ADHICS) | Contractors, consultants and service providers working for those entities | Private firms with no government or health link |
| Qatar | Agencies and their information assets unless a statute or regulation exempts them | Any organisation seeking NIA certification, including cloud providers serving Qatari customers | Organisations with no Qatari government or certification driver |
| Bahrain | CBB licensees under the Rulebook (for banks, module OM) | Service providers through outsourcing and contracts | Sectors without a sector regulator rule, which rely on NCSC guidance |
Worked scenario: a managed security provider headquartered in Dubai runs a SOC for a Saudi ministry, a Qatari government agency and a Bahraini bank. In Saudi Arabia it is a third party under ECC 4-1, and ECC control 4-1-3-2 requires managed security operations centres that use remote access to be located entirely inside the Kingdom, so a Dubai SOC cannot simply serve the ministry remotely. In Qatar the agency will usually expect the services it relies on to sit within an NIA-certified scope. In Bahrain the bank must call the CBB within one hour of a cyber incident, so the provider's escalation runbook has to feed that clock. In Dubai itself the provider is outside ISR unless it serves a Dubai Government Entity.
Control structure and key obligations
All four draw on ISO/IEC 27001 style management systems, but the level of prescription differs. The table compares obligations that most often drive design work.
| Topic | Saudi Arabia (ECC-2:2024) | UAE (IA Regulation and emirate rules) | Qatar (NIA) | Bahrain (CBB OM-5.5, banks) |
|---|---|---|---|---|
| Structure | 4 domains, 28 subdomains, 108 main controls, 92 subcontrols | Management families M1 to M6 and technical families T1 to T9 with priorities P1 to P4; ADHICS uses Basic, Transitional, Advanced and Service Provider compliance levels | Policy requiring an information security management system, with a high-level classification methodology | Rulebook paragraphs within the operational risk module |
| Governance | Cybersecurity function independent of IT (1-2); positions filled by full-time, qualified Saudi professionals (1-2-2) | Management controls in M1 to M6; v2.1 reported to strengthen executive ownership of cyber risk | ISMS ownership and scope documented for NCSA | Board-approved policy reviewed at least every three years; CISO heads a function independent of IT; quarterly management reports to the board |
| Authentication | MFA for remote access and privileged accounts (2-2-3-2), for remote and webmail access (2-4-3-2) and for external web application users (2-15-3-5) | Access control family T5, including privilege and credential management | Defined through the NIA control catalogue for the certified scope | Identity and access management and privileged access management required in the cyber framework (OM-5.5.18) |
| Logging | Cybersecurity event logs retained at least 12 months (2-12) | Operations and incident families T3 and T8 | Covered within the certified ISMS controls | Monitoring through the cyber framework; incident reporting below |
| Testing | Penetration testing of externally provided services "periodically" (2-11) | Defined through technical controls and emirate standards | In-depth controls assessment during the certification audit | Penetration tests at least twice a year by independent third parties rotated at least every two years, with grey box and black box tests; external vulnerability assessments weekly or more often |
| Incident reporting | Incident and threat management subdomain 2-13 | Incident family T8; ADGM's GEN 3.5.16 incident response plan requirement effective 31 January 2026 for its firms | Set by NCSA for certified and government entities | Call the CBB immediately (within one hour), Section A within two hours, Section B within 10 calendar days, weekly updates until resolved |
The Bahrain column covers conventional banks under Rulebook Volume 1; other licensee categories have their own modules, so confirm the volume that applies. For a cross-country view of reporting deadlines, see the Cyber Incident Reporting Requirements Map.
Assessment, certification and enforcement
- Saudi Arabia, continuous assessment: the NCA evaluates compliance through entity self-assessment, periodic reports from its compliance tool and field audit visits. There is no certificate to frame; evidence must stay current, and each subdomain's applicability should be recorded with a reason.
- UAE, designation and sector audit: designated critical entities implement the IA Regulation, and emirate regulators run their own programmes. ADHICS sets a compliance window of six months from programme induction or official release of the standard, whichever comes first, per category.
- Qatar, certification: the route described in cloud providers' documentation is scope preparation for NCSA Governance and Assurance Affairs, engaging an accredited auditor, a compliance audit with the report sent to NCSA, then a certification decision by NCSA. One provider's documentation describes a three-year certificate with annual maintenance audits; another lists its certificate number on the NCSA site and its scope as classifications C1 to C3.
- Bahrain, supervisory rulebook: CBB rules are enforced through ordinary supervision of licensees. The board must receive cyber reports at every meeting, which makes board packs a primary evidence source.
Practically, Saudi and Bahraini assessors look for living evidence (tool reports, board minutes, test reports), Qatari assessors examine a defined certification scope at a point in time and then annually, and UAE assessors start from the entity's risk assessment, because applicability beyond the always-applicable controls follows from it.
Cloud and hosting rules
| Country | Cloud instrument | Data location position | What providers usually show |
|---|---|---|---|
| Saudi Arabia | CCC-2:2024: 4 domains, 24 subdomains; 37 main controls and 94 subcontrols for providers, 18 and 26 for tenants; four levels from top secret (Level 1) to public (Level 4) | The 2024 updates to ECC and CCC removed the localisation subcontrols and moved data localisation to the National Data Management Office (NDMO) at SDAIA; consult NDMO | CCC compliance evaluated through self-assessment, compliance tool reports or on-site audit |
| UAE | Cloud controls within the federal standard; the Cyber Security Council has issued cloud security policy (per the ADGM notice) | v2.1 reported to tighten data location, key management and operational autonomy controls | Federal and emirate assessments; check the emirate and sector regulator |
| Qatar | NIA certification of the provider's scope | Classification levels drive which services and regions are certified | NIA v2.1 certificates naming regions and classification levels in scope |
| Bahrain | CBB outsourcing and cyber rules for licensees | Set by the sector regulator | Contractual assurance to the licensee |
The Saudi cloud rules are covered in depth in Saudi NCA Cloud Cybersecurity Controls (CCC). A frequent mistake is to read the removal of localisation subcontrols as freedom to host anywhere: the requirement moved to another authority, and staffing and remote-access location rules in ECC and CCC still apply.
Where identity and non-human identities are examined
None of the four instruments has a separate chapter on non-human identities, but every one reaches them through access control. Service accounts, API keys, cloud workload roles and SOC tooling credentials are accounts in scope like any other, and they are where assessors find the gaps.
- Saudi privileged account controls: ECC 2-2 requires least privilege, privileged access management and periodic access review, with MFA for privileged accounts. Shared admin and service credentials used by integration tools fall here; if a service account cannot use MFA, record the compensating control and the impact assessment the control asks for.
- Saudi 12-month logging: privileged and machine account activity must be in logs retained for at least 12 months, which affects SIEM licensing and cloud log retention settings.
- UAE T5 controls: registration, privilege management and access review apply to service accounts and API credentials. Map each to an owner and review cycle.
- Qatar certification scope: auditors sample accounts within the certified scope; undocumented automation accounts are a common finding in any ISMS audit.
- Bahrain PAM requirement: CBB OM-5.5.18 names privileged access management, so vaulting and session control for administrators and tooling accounts are expected.
See Audit Readiness for AI Agents and NHIs for an inventory and evidence approach that produces the evidence all four regimes ask for.
Decision guidance: building one Gulf control set
- Classify your footprint per country. For each entity and service, record whether you are directly bound (Saudi government or CNI, UAE designated critical, Qatari agency, CBB licensee) or contractually affected. This decides whether you need full evidence or flow-down clauses.
- Choose the strictest baseline as the core. For most groups ECC-2:2024 is the most prescriptive published baseline, so map it to your existing ISO/IEC 27001 controls first, then trace UAE T-family and NIA requirements onto the same rows.
- Add numeric overlays. Hard numbers differ: 12-month log retention (Saudi), twice-yearly penetration tests and the one-hour incident call (Bahraini banks), six-month ADHICS compliance windows (Abu Dhabi health). Keep them in a single overlay table so the strictest value wins where a system serves several countries.
- Plan location and staffing early. Saudi rules on Saudi cybersecurity staff and in-Kingdom managed SOCs, and NDMO data rules, shape the operating model more than any technical control.
- Sequence certification. If Qatari customers require NIA certification, fix the scope (regions, services, classification levels) before the audit, and reuse ISO/IEC 27001 evidence.
- Test and maintain. Run an internal mock assessment per country, track findings in one register, and review the overlay whenever an authority publishes a new version. Roll back a control change only with a documented risk acceptance signed by the accountable executive.
Small versus large organisations: a small supplier serving one Saudi ministry needs the ECC flow-down clauses and the relevant controls, not a full four-country programme. A large regional group should run one common control framework with country owners, because duplicated programmes drift apart.
Common failure patterns
- Mapping to a replaced version: control matrices still built on ECC-1:2018 (which had an industrial control systems domain, now moved to OTCC) or on the NESA-era UAE text.
- Treating NCA localisation as repealed: data location moved to NDMO, and staffing and SOC location controls remain.
- Assuming free zones follow federal policy: ADGM's regulator stated that adherence to the new Cyber Security Council policies was not mandatory for its firms while imposing its own incident response plan rule.
- Certifying the wrong scope in Qatar: a certificate that names regions and classification levels does not cover services or data outside them.
- Missing the Bahrain one-hour call: provider runbooks that escalate in business hours cannot meet a one-hour clock for a bank customer.
- Leaving machine accounts outside access reviews: integration and SOC tooling accounts with standing privilege are the usual finding against ECC 2-2, UAE T5 and CBB PAM requirements.
Practitioner checklist
- Record, per country and entity, whether you are directly bound or contractually affected, with the legal basis.
- Confirm the current version of each instrument on the authority's site and note the check date.
- Build one control matrix with ECC-2:2024 as the core and UAE, Qatar and Bahrain columns.
- Keep a numeric overlay table: log retention, test frequency, incident clocks, compliance windows.
- Check Saudi staffing, managed SOC location and NDMO data rules before choosing an operating model.
- Fix NIA certification scope (regions, services, classification levels) before engaging an auditor.
- Wire Bahraini bank customers' one-hour and two-hour reporting steps into incident runbooks.
- Inventory service accounts, API keys and tooling credentials, assign owners and include them in access reviews.
- Check emirate and free zone regulators separately from federal UAE rules.
Standards and references
- National Cybersecurity Authority: Essential Cybersecurity Controls ECC-2:2024
- National Cybersecurity Authority: Cloud Cybersecurity Controls CCC-2:2024
- UAE Government Portal: UAE Information Assurance Regulation
- Department of Health Abu Dhabi: ADHICS Standard V2
- Central Bank of Bahrain Rulebook: Volume 1, Module OM Operational Risk Management
- National Cyber Security Center Bahrain: National Cyber Security Strategy 2025-2028
- Google Cloud: Qatar National Information Assurance compliance
- Microsoft Learn: Qatar National Information Assurance offering
Related NHI Mgmt Group resources: Saudi NCA Essential Cybersecurity Controls Guide · UAE Information Assurance Standards Guide · Gulf AI Regulation · Critical Infrastructure Regulation Map · Global Cybersecurity Regulatory Map. This guide summarises cybersecurity regulations in Saudi Arabia, the UAE, Qatar and Bahrain and is not legal advice.