Sovereign by design

Cloud strategy has become a routine item on board agendas in the Kingdom. The harder questions rarely reach the same table: where the institution’s most sensitive data sits tonight, which jurisdictions could compel access to it and what it would cost, in money and in time, to move it.

That gap is becoming harder to carry. Sovereign cloud regions are coming online, and expectations under the NCA Essential Cybersecurity Controls, the standards of the National Data Management Office (NDMO) and the Personal Data Protection Law continue to sharpen. Where a workload runs now determines regulatory exposure, institutional control and long-term cost. Those are board matters, yet the choices behind them are usually made early, by a project team working to a deadline, and inherited by every program that follows.

The pattern is familiar. The program succeeds on its own terms: workloads move, the data center contract shrinks, the program closes on schedule. A few years later the institution finds that its residency position depends on configurations nobody owns, its security baseline varies by project, its bill has outgrown the business case, and leaving its main provider would outlast the strategy horizon. Each outcome is the sum of reasonable technical decisions made without a governing intent.

We believe five decisions belong at the top. They are few enough to fit on one page and consequential enough that delegating them is itself a decision.

01Residency starts with classification

Residency tends to be framed as geography: keep the data in the Kingdom and the obligation is met. Geography is necessary and rarely sufficient. Sovereignty also turns on who operates the platform, who holds the encryption keys and who can reach administrative functions from abroad.

An institution that has classified its data in line with NDMO standards and its sector’s rules can derive residency requirements from that scheme. One that has not will negotiate residency workload by workload, with each project team interpreting the rules for itself. Classifying individual datasets is management’s work. The board’s part is to own the scheme, name an accountable executive for each class and require that the scheme is applied before migration begins.

Key custody deserves a line of its own. When the institution manages its own encryption keys, sovereignty becomes far simpler to evidence. When the provider holds them, the institution’s control rests on contract terms that few directors have read.

02Placement is a policy

Regulated estates will remain hybrid for the foreseeable future: some workloads on premises, some in sovereign regions, some on global public cloud and many spanning more than one. That mix is sensible. Arriving at it by accident is expensive.

A placement policy translates classification into permitted destinations. For each class of data and tier of criticality, it states which options are allowed, which require an exception and who may grant one. It also sets the default, which matters because most decisions follow it: when the compliant option is also the easy one, teams choose it unprompted. The strongest policies are written against criteria such as jurisdiction, operator and key custody, so they stay valid as new sovereign offerings reach the market.

Leadership teams should resist two instincts. The first is to place everything in the most restrictive environment, on the theory that caution is free. It is expensive: sovereign and on-premises options carry real cost, sometimes a narrower service catalog and slower access to new capabilities, including the AI services many Vision 2030 programs depend on. The second is to default to global public cloud and argue sovereignty case by case, which yields a backlog of exceptions and a residency position nobody can fully describe.

03The landing zone is the constitution

The landing zone is the set of accounts, networks, identity controls, logging and guardrails that every workload lands in. It is commissioned as an engineering deliverable and behaves like a constitution: it determines what is possible, what is prohibited and what is recorded, for every team, from the first day.

That makes the security baseline a governance artifact. Controls written into the landing zone as code are applied consistently and can be evidenced on demand. Controls that live only in policy documents are applied when someone remembers them. Mapping the baseline to the NCA Essential Cybersecurity Controls at design time makes compliance a continuous property of the platform.

The board’s request here is simple: one baseline, owned centrally, inherited by every workload. Variation by project is among the most persistent sources of security debt, and it stays invisible until an incident or an audit exposes it.

04Cost and exit are settled on the way in

Cloud promises to align spending with use. It keeps that promise only for institutions that can see, attribute and act on their consumption. Many cannot, because financial discipline was deferred until the migration had already fixed architecture, sizing and commercial commitments.

FinOps belongs in the first phase. Tagging standards built into the landing zone let every cost trace to a product and an owner. Unit economics for major services let leaders discuss the cost of serving a beneficiary or processing a transaction, a better conversation than the size of the invoice. Multi-year commitments should be made with the whole portfolio in view, since they shape placement and portability long after signature. For public institutions this is also a matter of accountability: spending that cannot be tied to an outcome is hard to defend.

Exit follows the same logic. Every cloud decision is easier to make than to reverse. Proprietary managed services, data gravity, specialized skills and contractual commitments accumulate quietly, and the cost of leaving rises long before anyone proposes to leave. Full portability for every workload would give up much of what makes cloud worth adopting. The realistic goal is narrower: know what an exit would involve for each critical workload, and decide in advance how much dependency to accept.

Exit terms belong in procurement, before signature: export formats, transition assistance, key custody and the treatment of data at contract end. As the Kingdom’s sovereign cloud market matures, institutions that kept the ability to move will negotiate from strength. The rest will renew on the provider’s terms.

05A one-page cloud charter

The board’s task is to treat a few cloud choices as institutional policy: written down, enforced by the platform and revisited each year. In practice that means a short charter, approved by directors or by the risk or technology committee, that sets out:

• A data classification scheme mapped to residency obligations, with a named executive accountable for each class.
• A placement policy stating which hosting options each class may use, which need approval and which are prohibited.
• A security baseline written as code into the landing zone, with evidence mapped to the NCA Essential Cybersecurity Controls.
• A unit-cost model for each major service, reviewed alongside the benefits case it was meant to deliver.
• An exit plan for each critical workload: export formats, rebuild path, contract terms and a candid estimate of how long a move would take.

Institutions that settle these questions early move faster afterward. Migration waves stop stalling on residency debates, security reviews become confirmations and cost conversations start from shared numbers. Sovereignty added later is costly and always partial. Designed in from the start, it becomes a property of the platform, and only the board has the standing to require that.