Data Sovereignty / Source date:

Two Decades of Data Sovereignty: What Actually Changed

From offshore contracts to sovereign AI, the constant is that control, not location, determines real exposure.

Illustration of a data-estate control model, export case and provider-responsibility register on a technical workbench.

Twenty years ago, where data lived was an infrastructure detail. You put the server in the room with the air conditioning, and the only jurisdictional question anyone asked was whether the backup tapes were in a different building. The phrase data sovereignty did not appear in procurement documents because nothing in procurement depended on it. It is worth looking back at what actually changed over those two decades, because the accumulated story is less about regulation and more about a shift in who controls the systems companies depend on.

Sovereignty did not become important because laws changed. It became important because organisations stopped owning the machines, and the law spent twenty years catching up to that

Here is what genuinely shifted, and what turned out to be noise.

The four real transitions

From location to control. The early debate was about geography, and it took most of a decade to establish that the binding question is who controls the entity holding the data, not which country the disk is in. Everything built on the geographic framing had to be revisited. From transfer to access. Early rules governed moving data across borders. The operative concern now is who can compel access to data that never moves, which is a different problem with different controls. From storage to processing. Sovereignty frameworks assumed data at rest. The value of data now sits in what is done with it, and the processing is increasingly performed by systems the data owner does not operate. From compliance to commerce. For most of this period sovereignty was a legal obligation. It is now a procurement requirement — customers ask, tenders score it, and the cost of a poor answer is revenue rather than a fine.

Four changes in the sovereignty questionA qualitative organization of the article's argument, not a chronology of legal enactments.
Earlier focusQuestion the article adds
Storage locationWho controls the entity and systems holding the data?
Cross-border transferWho can obtain or compel access without moving the data?
Data at restWhere and by whom is the data processed?
Legal complianceWhat do customers and procurement processes require?

Qualitative summary of this article's source text, not a measured outcome or performance estimate.

What turned out to be noise

The recurring prediction that the internet would split into incompatible technical networks. It did not; the fragmentation was legal and operational, which was both less dramatic and more expensive. The idea that a single global adequacy framework would settle matters. Every attempt was struck down or renegotiated, and the pattern is stable enough now to plan around. And the assumption that sovereignty was a European preoccupation. It is now a requirement across the Gulf, much of Asia and Latin America, frequently with stricter localisation than Europe ever imposed.

What has not changed at all

The underlying tension is exactly what it was in 2007: states want access to data about their citizens and their economies, and organisations want to run systems wherever they run best. No technical or legal development in twenty years has resolved that, and none is going to. The practical consequences are also stable. Hold less. Know where things are. Know who controls them. Be able to leave. Every durable piece of advice from the past two decades reduces to those four, and the organisations that followed them have spent the period adapting rather than rebuilding.

Practical Guidance for Sovereignty Strategy Retrospective

  • Assess control, not geography — the lesson that took a decade.
  • Design for access requests, not only for transfers.
  • Treat processing location as seriously as storage.
  • Hold less; it is the only control that helps universally.
  • Maintain exit capability as a standing requirement.
  • Expect frameworks to be renegotiated, and build accordingly.
  • Track sovereignty as a commercial requirement, not only legal.
  • Keep the map current; every architecture change moves it.

The Regional Angle

The first regional observation is that the Gulf moved from having essentially no data protection framework to having operative, enforced regimes in under a decade — a compression of what took Europe thirty years. Organisations that had operated regionally on the assumption of permissiveness had very little time to adjust, and the ones that adjusted well were generally those that had already built for European requirements and could extend rather than start. The second is that the region's position shifted from rule-taker to rule-maker faster than most observers expected. Saudi and Emirati frameworks are not copies; they impose localisation and transfer conditions that Europe does not, and they were drafted with an explicit view of national capability rather than purely individual rights. Companies that treated regional compliance as a lighter version of European compliance were consistently wrong about which obligations would bind them. The third is the infrastructure story, which is the most consequential and least discussed. Two decades ago sovereignty in the Gulf was unachievable in practice because the infrastructure was not here — there was no compliant option to choose. Sovereign cloud regions, domestic model development and regional data centre investment have changed that, which means the question facing a regional organisation today is a genuine choice with a price rather than an aspiration with no supplier.

The objection worth taking seriously

The strongest objection to any retrospective of this kind is that it imposes a narrative on what was really a series of unconnected reactions. There was no trajectory from location to control; there were court rulings, political ruptures, a few large enforcement actions and a great deal of vendor marketing, and the tidy progression is visible only because we are selecting the events that fit it. Organisations reading this as a direction of travel will extrapolate confidently from a pattern that was never there. The warning is fair, and most of the major turning points were genuinely unforeseen at the time. What survives the objection is narrower but more useful: not a trajectory, but a set of things that repeatedly turned out to matter regardless of which way events went. Control over geography was the right answer before the rulings that confirmed it and remained right after. Holding less helped under every regime that emerged. Exit capability was valuable in every scenario including the ones nobody predicted. Those are not predictions about direction; they are observations about which positions were robust across twenty years of surprises. That is the only kind of lesson a retrospective can honestly offer, and it is enough to plan with.

Common Questions

What was the single most consequential shift?

The move from asking where data sits to asking who controls the entity holding it. Nearly every architecture built on the earlier question had to be redone.

Did any of the global frameworks hold?

None permanently. Planning on the assumption that the current arrangement will be renegotiated has been correct every time so far.

What should a company starting today do differently?

Build exit capability from the beginning and hold less than feels necessary. Both are cheap at the start and very expensive to retrofit.

What should we expect over the next twelve months?

Expect processing and inference location to become the active frontier. Expect more markets to add localisation in specific sectors. Expect the commercial weight of sovereignty answers to keep growing faster than the regulatory weight. And expect the underlying tension to remain unresolved, as it has for twenty years.


Sovereignty Strategy Retrospective — we look at which of your positions would have survived the last twenty years, because those are the ones worth keeping.

Continue reading

Talk to OPS

Start with the operating problem.