For most of the previous decade, the question of where data lived was answered somewhere below the level anyone senior noticed. An infrastructure manager chose a region because latency was good and capacity was available. A procurement officer accepted a vendor's standard terms because negotiating them would have delayed a project. The word "sovereignty" appeared in tender responses, not in board packs. That changed in 2018, and it changed for an unromantic reason: the consequences became large enough to reach the people who are accountable for large consequences. A regulatory regime with penalties expressed as a percentage of global turnover is not an IT risk. It is a financial risk with a legal trigger, sitting alongside currency exposure and credit concentration in the category of things a board is expected to have considered. What made data sovereignty a boardroom topic was not any single event. It was the convergence of four pressures that each, independently, turned a technical placement decision into a matter of corporate strategy.
The four pressures that moved it up the agenda
Penalty scale relative to turnover. Previous data protection regimes carried penalties that a large organisation could absorb as a cost of doing business. Framing maximum exposure as a proportion of worldwide annual turnover removed that option. Once a risk is capable of being material to the financial statements, it belongs in the risk register the audit committee reviews, and the question of who approved the arrangement that created it becomes a governance question. Conflicting legal obligations. Through 2018 it became clear that an organisation could be subject to two regimes issuing incompatible instructions — one jurisdiction compelling disclosure of data held by a provider under its control, another restricting that same disclosure. That is not a problem an IT department can resolve. Choosing which exposure to accept, and documenting that choice, is a board-level decision because there is no compliant answer, only a defensible one. Customer contracts became binding representations. Enterprise customers began requiring specific commitments on where data is stored, who can access it, which sub-processors are used and under what conditions data crosses a border. Those commitments appear in contracts with liability attached. An organisation that cannot honour them has a contractual exposure and a revenue risk, and the sales function was signing them long before anyone verified they were true. Market access. Localisation requirements in a growing list of countries turned data placement into a condition of operating. A sovereignty decision that excludes a market, or forces a duplicated estate to enter one, is a capital allocation decision. It has a cost, a return and a strategic rationale, which is precisely the set of things boards exist to weigh.
What a board can usefully decide
The common failure is that sovereignty arrives at the board as a compliance briefing — a slide on the regulation, a slide on the programme, a slide of green statuses — and leaves without a decision having been made. Briefings do not discharge oversight. Decisions do. Four decisions are genuinely the board's, and cannot be delegated without delegating the accountability with them. Risk appetite by data category. Not all data warrants the same protection. Deciding which categories — customer identity documents, employee medical records, pricing and margin data, source code, strategic plans — justify the cost of jurisdictional control, and which can be held in a commercially convenient location with the residual risk accepted and recorded, is a business judgement rather than a technical one. Jurisdictional footprint. Which countries the organisation will operate data in, which it will not, and what it is prepared to pay to enter a market with localisation requirements. This belongs with strategy, not with infrastructure. Acceptance of unresolvable conflicts. Where two regimes cannot both be satisfied, someone must accept the residual exposure explicitly. A board that has never been asked to accept a risk has not exercised oversight; it has received reassurance. Investment in partitionability. The single most valuable architectural property in a world of changing rules is the ability to separate data and processing by jurisdiction without re-platforming. It costs money now to avoid a much larger cost later, which makes it an investment decision rather than an engineering preference.
| Decision | Position to record |
|---|---|
| Risk appetite by data category | Which sensitive categories justify jurisdictional controls |
| Jurisdictional footprint | Where the organisation will and will not operate data |
| Residual conflicts | Which unresolved exposures are explicitly accepted |
| Partitionability investment | What to fund so data and processing can be separated later |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What to ask for, and what to ignore
The reporting that boards receive on this topic is unusually poor, because it tends to describe activity rather than position. A programme status is not a risk position. Three questions produce more signal than a full compliance deck. Where can our most sensitive data be accessed from, and by whom — including our own providers, their sub-contractors and the integrators who administer our systems? This is harder to answer than it sounds, and the difficulty is itself the finding. Which of our customer contracts contain data location or access commitments, and can we evidence that we are meeting them? A surprising number of organisations discover they cannot. If a regulator or a major customer asked us to demonstrate our data map tomorrow, what would we show them? The gap between the answer and the expectation is the real status report. What to discount: counts of policies published, training completion percentages, and assurance that a provider holds certifications. None of those describe where data is, who can reach it, or what happens when two laws disagree.
Practical Guidance for Board-Level Data Governance Framework
- Put data sovereignty on the risk register with a financial exposure, not a compliance status. If it cannot be expressed as potential loss, it will not be governed like a risk.
- Require a decision at each review, not a briefing. Risk acceptance, footprint changes and investment approvals are the artefacts of oversight.
- Classify by data category and set appetite explicitly. Uniform protection is either unaffordable or inadequate, and usually both in different places.
- Ask where data can be accessed from, not only where it is stored. Access location is the gap in almost every residency claim.
- Audit the commitments sales has already made. Contractual data location representations are enforceable and frequently unverified.
- Name a single accountable executive. Sovereignty spans legal, IT, security, procurement and the business; without one owner it defaults to nobody.
- Fund partitionability as insurance. The rules will change again; the ability to separate by jurisdiction without re-platforming is what makes the next change survivable.
- Record accepted risks with an expiry date. An acceptance with no review date becomes a permanent undocumented position.
The Regional Dimension
In the Gulf, data sovereignty reached the board earlier than in many Western markets, and for different reasons — which changes what regional boards should be asking. The first driver is that government and semi-government business is a large share of regional revenue, and public sector procurement has carried in-country data requirements for years. For a great many regional organisations, sovereignty is not a regulatory abstraction; it is a tender qualification. Losing the ability to bid on government work is a revenue event, which makes the topic commercially legible to a board in a way that a hypothetical penalty is not. The same logic extends through in-country value and local content programmes, where infrastructure and capability decisions carry procurement weight. The second is group structure, which is the regional detail most often missed. A typical Gulf group holds a mainland operating company, one or more free zone entities, possibly a DIFC or ADGM entity with its own data protection regime, offshore holding companies, and frequently international subsidiaries or investors. Obligations attach per entity, not per group, and a shared platform serving all of them can be simultaneously compliant for one entity and exposed for another. Boards routinely receive a single consolidated status for an estate whose legal position varies by subsidiary. The right question is which entity is exposed, not whether the group is compliant. The third is the local regulatory build-out that followed, which turned a foreign compliance exercise into a domestic one: Saudi PDPL and cloud framework requirements, the UAE federal data protection framework, the separate DIFC and ADGM regimes, sector rules from central banks and health regulators, and national cybersecurity authority requirements. A regional board now governs several overlapping regimes rather than one, and the practical consequence is that a single global policy is guaranteed to be wrong somewhere. Three further specifics are worth building into regional board reporting. The hyperscaler build-out in the UAE and Saudi Arabia, together with locally controlled sovereign operators, has made in-country hosting a genuine option — with two caveats boards should hear: regional capacity has frequently been priced above the largest global regions, and new services arrive there later, so a sovereignty decision has a feature and cost consequence that should be stated rather than discovered. Integrator-operated estates mean standing privileged access into production from delivery centres abroad, which is the most common reason a confident residency statement turns out to be inaccurate. And commercial sensitivity, rather than privacy, is usually the framing that gets a sovereignty review funded here — boards that are unmoved by a data protection briefing engage immediately when the question is whether a competitor's home jurisdiction could compel access to pricing, tender or margin data.
The objection worth taking seriously
The strongest criticism is that board-level attention to data sovereignty has produced expensive architecture in service of a risk that rarely materialises, and has crowded out attention on risks that do. The evidence deserves respect. Compelled government access to enterprise application data is, by the volumes that providers publish, a rare event. Meanwhile the incidents that have actually destroyed value in the past decade were unglamorous: unpatched systems, stolen credentials, phishing, ransomware, poorly managed third-party access. An organisation that spent heavily on jurisdictional partitioning while running an estate it could not patch quickly made the wrong trade, and several did exactly that. There is also a real pattern of sovereignty being used commercially rather than analytically — as a differentiator by local providers, as a delaying tactic in procurement, and as a reason to prefer an incumbent — and boards are not well equipped to tell an architectural argument from a sales one. A fair reading also notices that the consistency is poor. Organisations conducting elaborate analysis of one jurisdiction frequently accept others with broader state access powers and less transparency without comment, because the analysis follows regulatory attention rather than actual risk. And the sovereignty conversation has been notably silent about the mandated channels — tax platforms, payroll systems, customs and immigration portals — where data placement is not a choice at all. The defensible position is narrow and practical. Most data does not warrant jurisdictional control, and the honest treatment is classification, acceptance and a note in the register. A small category — identity documents, medical records, pricing and margin data, material non-public information, and anything a customer contract commits you on — genuinely does. For that category, spend on partitionability rather than relocation, because the specific rules will change and the ability to separate is what survives the change. And keep the basic security work funded ahead of all of it, because a sovereign estate that cannot be patched is a more likely loss than a well-run one in the wrong jurisdiction.
Common Questions
Why is this a board topic rather than an IT one?
Because the decisions are about risk appetite, market access and capital allocation. Where data sits is an engineering implementation; which exposures the organisation is prepared to carry, and what it will pay to avoid them, is governance.
What should the board actually receive?
A risk position rather than a programme status: which data categories are exposed, in which entities, what has been accepted and by whom, and what the accepted risks would cost if they materialised. Policy counts and training percentages are activity, not position.
Is sovereignty mainly a regulatory concern?
Not in practice. Customer contract commitments, government and large-enterprise procurement requirements, and market access conditions usually create more immediate commercial exposure than regulatory penalties do.
How does AI change the board's view of this?
It reopens a question most boards believed they had closed. Enabling an AI feature can move data, or a derived form of it, to a model provider in another jurisdiction — and it can happen through a vendor product update rather than a procurement decision, which means the governance trigger the board relies on never fires. The derived artefacts are the harder part: retained prompts and outputs, embeddings built from your documents, and fine-tuned weights are copies that sit outside the data map and cannot be deleted by a routine written for a database. Three things worth mandating at board level: that enabling AI capabilities over sensitive data categories is a governed decision with a named approver, that vendor contracts require notice before such features are switched on, and that inference location and retention are reported alongside storage location in whatever data map the board receives. A residency position that covers databases and not inference is describing last year's estate.
Board-Level Data Governance Framework — set appetite by data category, decide the jurisdictional footprint deliberately, and fund the ability to partition.