# Understanding data sovereignty and jurisdictional risk > Source: > Published: 2026-06-19 20:27:03+00:00 # Understanding data sovereignty and jurisdictional risk The political landscape is changing rapidly. Across Europe and other non-US markets, dependence on US-controlled technology platforms, cloud providers, and frontier AI services is moving from a theoretical concern to an active strategic risk. Recent events have made that risk tangible. Within days of Anthropic releasing its latest Claude Fable 5 and Mythos 5 models, [the US government imposed export-control restrictions](https://x.com/AnthropicAI/status/2065597531644743999) requiring Anthropic to suspend access for foreign nationals. That included non-American users in allied countries and, according to reporting, [even affected Anthropic employees without US citizenship](https://www.anthropic.com/news/fable-mythos-access). Anthropic subsequently disabled access to the affected models globally while it worked through the regulatory issue. For non-US organisations, the lesson is: capability built on foreign-controlled platforms can be interrupted not only by technical failure, commercial change, or supplier instability, but by geopolitical decisions outside the customer's control. Data sovereignty, jurisdiction, and operational control have therefore become board-level technology concerns. Organisations running workloads in the cloud, storing customer data, or processing information through third-party platforms need to understand not only where their data resides, but who can compel access, restrict service availability, or alter the operating conditions under which that capability is delivered. This matters because the security, privacy, and availability of user data is increasingly concentrated in a small number of hyperscalers and frontier technology labs. As a result, technology dependency is no longer just an architectural or procurement consideration. It is becoming a resilience, sovereignty, and strategic control issue. Technology and product leaders must therefore develop a more nuanced understanding of data sovereignty, jurisdictional exposure, and operational portability in cloud environments. The objective being to make informed decisions about concentration risk, exit optionality, regulatory exposure, and the level of control required for systems that are strategically or operationally critical. ### Contents [What is sovereignty?](/blog/understanding-data-sovereignty#sovereignty)[Achieving sovereignty](/blog/understanding-data-sovereignty#achieving)[Practical implications for technology leaders](/blog/understanding-data-sovereignty#implications)[Closing thought](/blog/understanding-data-sovereignty#closing) ### What is sovereignty? Sovereignty means supreme power or authority. In practical terms, it describes who has ultimate legal authority, control, and decision-making power. A sovereign authority can make, interpret, and enforce the laws, controls, and regulations that apply to it, without being overruled by another external authority. In the context of data and cloud services, sovereignty is concerned with who ultimately has the power to control, access, regulate, restrict, or compel action over data, infrastructure, providers, and operations. If we are serving a population of UK users, those users would reasonably expect their data to be stored, processed, and governed in a way that preserves the rights and protections afforded to them under applicable UK law. Ideally, those rights should apply end to end: across the application, the data, the infrastructure, the cloud provider, and any third-party processors involved in delivering the service. The sovereignty concern arises when another jurisdiction, government, regulator, or legal authority can override those protections, compel access to the data, restrict service availability, or require either the organisation or its suppliers to act in a way that conflicts with the expectations and protections established under UK law. ### Achieving sovereignty **Infrastructure Locality** The first layer of sovereignty is infrastructure locality: ensuring that data is stored, compute is hosted, and workloads are processed within the intended country or region. For organisations serving a single region, the controls are relatively straightforward: choose the right hosting region, limit replication, constrain support access, manage encryption keys, and ensure suppliers process data within the required jurisdiction. For organisations serving customers across multiple regions, the challenge becomes more complex, requiring geo-aware request routing, regional hosting, regionalised data storage, controlled failover patterns, and clear policies governing where data is processed, replicated, accessed, and supported. However, infrastructure locality is only one dimension of sovereignty. Physical location matters, but it does not, on its own, guarantee sovereign control. Organisations must also consider provider ownership, operational access, support models, administrative control planes, encryption key custody, supplier dependencies, cross-border data flows, legal compulsion powers, and the jurisdictions under which service providers operate. **Jurisdictional Considerations** Jurisdiction is the harder and often more misunderstood dimension of sovereignty. While infrastructure locality is concerned with where data and compute physically reside, jurisdiction is concerned with which legal authorities can assert power over the data, the service, the provider, or the organisations involved in operating it. This distinction matters because data can be stored in one country while still being exposed to the laws of another. For example, a cloud provider, software vendor, support organisation, parent company, or subcontractor may be incorporated, headquartered, operated, or legally accountable in a different jurisdiction from the one in which the data is stored. As a result, organisations must look beyond the hosting region and consider the full legal and operational chain of control. Key questions include: - Which legal entity provides the service? - Where is that entity incorporated? - Where is its parent company based? - Which jurisdictions can compel the provider to disclose data or metadata? - Which jurisdictions govern support, operations, and administrative access? - Where are encryption keys generated, stored, managed, and accessed? - Can provider personnel outside the target jurisdiction access systems, logs, telemetry, backups, or support data? - Are subcontractors or third-party processors involved in service delivery? - Do contractual commitments align with the organisation's sovereignty requirements? - Are there legal mechanisms that could override contractual, technical, or operational controls? This is where sovereignty becomes more than a deployment decision. A workload may be hosted in the UK, processed in a UK cloud region, and configured to avoid cross-border replication, while still being subject to legal, operational, or ownership structures that introduce exposure to another jurisdiction. Sovereignty risk must be assessed across the full service model, not simply the physical location of the infrastructure. True sovereignty requires understanding who can access, administer, compel, regulate, or disrupt the service, and under which legal authority they may be able to do so. ### Practical implications for technology leaders The practical implication for technology and product leaders is that sovereignty can no longer be treated as a narrow hosting decision. It must be understood as an architectural, legal, operational, commercial, and strategic concern. Leaders should be able to assess and explain: - where customer data is stored - where workloads are processed - where backups, logs, telemetry, and support data reside - who can access production systems and under what controls - which legal entities provide and operate the service - which jurisdictions can compel access to data or metadata - how encryption keys are generated, stored, managed, and accessed - which third parties or subcontractors participate in service delivery - how data moves across regions during normal operations, failure scenarios, support activity, and incident response - what exit, portability, or continuity options exist if a provider becomes strategically unsuitable This requires a more mature view of cloud architecture. Regional hosting is necessary, but insufficient. Contractual commitments are important, but not complete. Encryption is critical, but only as strong as the custody, access, and operational model surrounding the keys. A sovereign cloud posture therefore requires deliberate design across several dimensions: **Architecture:** ensuring workloads, data, backups, and failover models align to sovereignty requirements.**Operations:** controlling who can administer, support, observe, or recover the service.**Security:** protecting data through encryption, key management, access control, monitoring, and segregation of duties.**Legal and procurement:** understanding supplier ownership, contracting entities, subcontractors, applicable law, and compulsion risk.**Resilience:** ensuring that service continuity does not depend on a single provider, jurisdiction, or geopolitical assumption.**Governance:** maintaining evidence that the organisation understands and controls where data resides, who can access it, and under which legal authority. ### Closing thought Data sovereignty and jurisdiction are no longer peripheral compliance topics; they are core concerns for trust, resilience, security, and long-term digital independence. Organisations that understand who has the power to access, control, compel, restrict, or disrupt the services and data users depend on will be better positioned to make informed decisions about cloud strategy, supplier selection, architecture, and operational risk. Those that do not may find that their technical controls, contractual assurances, and regional hosting choices provide less protection than they assumed. In an increasingly unstable geopolitical environment, that distinction matters.