Cyber sovereignty in the GCC — what boards actually need to decide

The shift the board actually needs to see

For a decade, cyber briefings in the GCC have followed the same shape: a maturity score, a heat map, a shopping list of tools. That conversation is finished. UAE Information Assurance, the SAMA Cyber Security Framework, NCA ECC and OTCC, the NESA and Dubai Electronic Security Center standards — regulators have converged on the same expectation. Compliance is the floor, not the ceiling. What boards now have to decide is a governance question, not a technology one: who controls the data, who holds the keys, who runs the detections, and under whose jurisdiction do those functions sit when something goes wrong at 3am on a public holiday.

What we mean by sovereignty

We use sovereignty in the practical sense — the ability to keep operating, investigating and recovering without depending on a party you cannot compel. That splits cleanly into three layers. Data sovereignty is where the bytes physically live and which law applies to them. Operational sovereignty is who can actually push a change, rotate a key or read a log at 2am. Technical sovereignty is whether the platforms you run on can be substituted, extended or forked if a supplier relationship changes. Cloud residency alone answers only the first. Most GCC organisations we assess have solved residency and quietly conceded the other two.

“Cloud residency answers where the bytes live. It does not answer who can read them at 2am, or who can stop reading them at your instruction.”

Five decisions we put in front of every board

1) Key custody. Are your production encryption keys held in a customer-controlled HSM inside your jurisdiction, or in a hyperscaler-managed KMS? Both are defensible, but only one is a sovereign posture. 2) Detection ownership. Is your SOC a service you buy, or a capability you own — with the analysts, playbooks and threat intelligence sitting inside the entity? 3) Identity root of trust. Where does privileged identity actually terminate, and who can create a break-glass admin outside your view? 4) Third-party reach. Which of your integrators, OEMs and MSPs can push code, credentials or configuration into production without a human on your side approving it? 5) Exit. If your primary cloud, MSSP or core platform vendor became unavailable for 90 days, what would you lose and how fast could you rebuild?

The operating model is the deliverable

A sovereign posture is not a product purchase. It is a set of roles, a decision rights matrix, and a small number of contracts written differently. In every mandate we run, the largest single artefact is not the technology roadmap — it is the target operating model: who owns policy, who owns platforms, who owns detections and response, and how the CISO organisation interlocks with the CIO, the DPO, the legal team and the regulator. Technology purchases follow that model. When they precede it, they entrench the problem they were bought to fix.

Where we start

Our first six weeks with a new client are deliberately not about tools. We map regulatory obligations to a concrete decision rights matrix, we test three real incident scenarios against the current model — a ransomware event, a hyperscaler outage, a privileged insider — and we produce a one-page board paper that names the five sovereignty decisions and the cost of deferring each. From there, the technology roadmap almost writes itself.