GCC Cybersecurity Compliance: How to Build a Multi-Jurisdiction Model

Group compliance teams in the Gulf tend to start with the same instinct. Pick the strictest regime in the region, apply it everywhere, and call the result a GCC standard. It feels safe. It is also the first design decision that tends to fail, because enterprises answer to national regulators, and the national regimes were written separately, for different reasons, by different authorities.

Consider a hypothetical logistics and payments group with entities in Saudi Arabia, the UAE and Qatar. The Saudi entity runs infrastructure that brings it inside the National Cybersecurity Authority’s scope. The UAE entity is onshore and has a free-zone sibling. The Qatari entity holds a payment license. That is at least three regulators and three incident channels, plus a board asking whether the group is compliant in the Gulf. The question has no single answer. A model that pretends otherwise produces a status color, not an answer.

Six national regimes, not one regional one

The table lists the anchor instruments a group usually maps first. It is a starting point, not an inventory. Sector rules and free-zone rules sit on top.

The names matter less than the pattern. Saudi scope is largely defined by who the entity is: a government body or a critical national infrastructure operator. UAE scope is defined by where the entity sits and what it does. The smaller regimes are defined by license and by data. A group that reads every regime as “applies to us” will overbuild in some places and miss obligations in others.

Where the regimes diverge, and why a mapping spreadsheet will not show it

Control content converges more than most teams expect. Governance, access control, logging, incident handling, third-party oversight and resilience appear in nearly every framework, and a baseline built on ISO/IEC 27001 or the NIST Cybersecurity Framework covers much of the common ground. The cost sits in six places where a regime asks for something a baseline cannot supply.

Applicability. The NCA’s Essential Cybersecurity Controls bind government bodies and private owners, operators or hosts of critical national infrastructure, and the NCA encourages everyone else to adopt them. The same control can be optional in one country and mandatory in another, with a different standard of evidence in each.

Data location and transfer. Hosting and transfer rules often sit outside the cyber frameworks. Saudi localization questions now point to the national data management authority rather than to the cyber controls. In the UAE, health data and banking data carry their own location rules, and free zones run separate data protection regimes. A cyber control owner rarely owns these rules, so the register has to name who does.

Incident clocks and recipients. Regulators differ on channel, on definition and on deadline. Groups usually discover this the first time one event touches two entities. Decide in advance which internal clock governs. A workable rule is the earliest regulator deadline among the affected entities, started at the moment of awareness, with one incident record feeding every notice.

People. Saudi controls tightened nationalization expectations for cybersecurity roles in covered entities between the first and second versions of the Essential Cybersecurity Controls. A control mapping will not show this, yet it can shape how a group staffs a regional SOC, whether a shared service center is workable, and what a managed-service contract can promise. Check the exact wording and your entity’s coverage against the Arabic text, which the NCA states is the binding version.

Cloud and third parties. The Saudi controls include a domain on third-party and cloud computing cybersecurity, and the UAE Cybersecurity Council has published a national cloud security policy. A global cloud landing zone designed once will meet some of this and miss the rest, particularly where a control asks something of the vendor rather than of you.

Proof. Regulators test differently. The NCA evaluates compliance through self-assessments, periodic compliance tool reports and field audits. A group that assesses itself once a year in a spreadsheet and then meets a field audit finds that its evidence is stale and its owners unfamiliar with it.

A model with three layers

Layer one is the baseline. One control set, written once, owned centrally, mapped to a recognized standard. Its job is to make the common ground uneventful. Raise it to the strictest requirement only where doing so is cheap everywhere or costly to vary: multi-factor authentication for privileged access, centralized logging, a single incident classification scheme. Do not raise it for localization, staffing or reporting. Those are local by nature.

Layer two is the obligation register. One row per obligation per legal entity: source, jurisdiction, why it applies, the trigger, the control it maps to, the owner, the evidence, the review cycle. “Why it applies” is the column most registers leave out and the one a regulator will probe. If the reasoning is not written down, the next regulatory change reopens the question from scratch.

Layer three is local ownership. Each entity has a named compliance owner with authority over its overlay and its exceptions. The group sets the baseline. The entity answers to its regulator. Exceptions to the baseline carry expiry dates, because an undated exception is a permanent one.

Two alternatives are common, and both have costs. Country-by-country programs give each regulator what it expects and leave the group with six control sets that drift apart. A single strictest-wins program gives the board one number and gives local teams controls they cannot evidence or do not need. The layered model takes more design effort up front and a standing change process. It pays back when a regulation changes, because a new requirement becomes a row in a register rather than a project.

What goes wrong in practice

The register gets built from regulatory text and never connected to the people who run the controls, so it describes obligations nobody operates. Frameworks get treated as checklists, when they tell you what the regulator expects to see and say little about how your architecture should deliver it. Change goes untracked. In the UAE, onshore personal data protection duties have depended on executive regulations that were slow to arrive, so confirm their current status before assuming either enforcement or exemption. And contractual requirements, such as security schedules in government and large-enterprise contracts, are left out of the register because no regulator issued them.

Where to start

1. List every legal entity with its location (onshore or free zone), its licenses, its sector, and whether it operates or hosts critical infrastructure. Scope comes from this list, not from the countries the group operates in.

2. Build the register for the entities facing the strictest regulators first, and write the “why it applies” reasoning as you go.

3. Agree the incident clock rule and the single incident record, then test them with a tabletop that affects two entities in different jurisdictions.

4. Set a review cadence. Name one reader per jurisdiction who checks regulator publications each quarter and records what changed.

Once those four exist, the board’s question becomes answerable entity by entity, with evidence and a list of what has changed since the last time it asked.

Sources

1. National Cybersecurity Authority (Saudi Arabia): Essential Cybersecurity Controls – Scope, structure, Arabic-text note and compliance evaluation methods.

2. CMS: Expert Guide to Data Protection and Cyber Security Laws, UAE – Federal, emirate and free-zone framework; Cybersecurity Council; cloud policy.

3. Clyde & Co: commentary on the Essential Cybersecurity Controls update – Changes between the first and second versions, including localization and nationalization.

4. UAE Legislation Portal – Check the current status of executive regulations under the federal personal data protection law.