Beyond Data Residency: What Cloud Sovereignty Actually Means

Storing data in a European region constrains its physical location. It does not, by itself, change which legal regimes can reach the organisation that operates the service. Where a European cloud service is provided by the subsidiary of a parent company established in another jurisdiction, the data that sits in Europe can fall within that parent's "possession, custody, or control" and may be reachable through the parent jurisdiction's legal process [S55]. This is a legal-structure question, not a map question. The bytes are in Frankfurt or Dublin; the corporate control over them may sit elsewhere.

This is the core of the residency-versus-sovereignty gap. Residency looks at geographic location. Sovereignty looks at jurisdictional reach and at who, in practice, can access data and under what compulsion [S55]. Encryption and a regional address reduce some risks, but they do not on their own resolve the question of legal control.

It is important to be precise about what the law says, and to keep it separate from how analysts and vendors interpret it. Two instruments are the anchor here.

The law. In its judgment of 16 July 2020 in Case C-311/18 (commonly called Schrems II), the Court of Justice of the European Union invalidated the European Commission adequacy decision underpinning the EU-US Privacy Shield, and held that Standard Contractual Clauses remain valid, but that a data exporter must verify, and where necessary supplement, the level of protection in the destination country [W1]. Separately, the General Data Protection Regulation, Regulation (EU) 2016/679, sets the conditions for transfers of personal data to third countries in Chapter V, Articles 44 to 50, beginning from the principle that a transfer must not undermine the level of protection the Regulation guarantees [W2].

The interpretation. What organisations should do in response, and how much residual risk a given architecture carries, is the subject of professional interpretation by law firms, analysts, and academics. That interpretation is legitimate and useful, but it is not the law, and it is not legal advice. Where this article describes implications, it is reporting interpretation and analysis, and a qualified legal review of a specific situation remains necessary.

Holding that line matters because much sovereignty marketing blurs it, presenting an interpretation of risk as if it were a settled legal requirement, in either direction.

If residency is one input, what are the others? A useful way to read the literature is that sovereignty is not a single property but a set of dimensions, and an architecture can be strong on some and weak on others [S62][S26][S55]. The dimensions worth assessing include:

• Legal and jurisdictional control: which legal regimes can reach the data and the operator, including extraterritorial reach over a parent company [S55].
• Operational control: who performs administrative and break-glass access, and whether that access is confined to personnel within the target jurisdiction [S62].
• Technical control: whether isolation is enforced at the hardware and software level, not only by policy [S03][S62].
• Data and key control: who holds the encryption keys, and whether they sit outside the provider's reach [S62].
• Supply-chain and subcontractor dependencies: which third parties and upstream vendors the service depends on.
• Portability and exit: whether the workload and its data can be moved out without prohibitive cost.
• Transparency and audit evidence: whether the customer can see and prove how the service is operated.
• Business continuity and contractual rights: what guarantees and remedies exist if circumstances change.

No provider or architecture is automatically sovereign across all of these. The major hyperscalers have converged on portfolio approaches precisely because no single pattern satisfies every dimension for every requirement [S62][S55]. The practical consequence is that "sovereign" is not a badge a service either has or lacks. It is a profile across dimensions that has to be matched against a specific organisation's obligations.

Three of these dimensions are where residency-focused thinking most often falls short, so they are worth drawing out.

Operational control asks who can touch the system. A service can store data in-region and still rely on administrators or site reliability engineers located in, or subject to, another jurisdiction. Some sovereignty patterns therefore aim for a form of human confinement, so that administrative and break-glass access is performed only by personnel within the target jurisdiction [S62]. Where the data sits is a different question from who can operate on it.

Technical and key control ask whether protection is enforced by the architecture rather than promised by policy. Confidential computing is the relevant technique. By processing data inside hardware-protected execution environments, it allows sensitive workloads to run even in an environment the customer does not fully trust, without exposing the data in plaintext to the operator [S03][S62]. Combined with customer-held or externally managed encryption keys, it shifts some control from the provider to the customer at the technical layer [S62]. These mechanisms are powerful and also not absolute: hardware enclaves have documented side-channel limitations, and externally held keys introduce an availability dependency, because losing them can halt the workload [S62]. They are tools that strengthen specific dimensions, not a guarantee of sovereignty.

Stronger sovereignty is not free. One vendor-affiliated analysis describes a "sovereignty tax", the combination of cost premiums, latency and throughput penalties, and feature lag that tends to accompany more strongly isolated or jurisdictionally confined architectures [S62]. That analysis comes from a single source with a commercial position, so the specific magnitudes should be treated as its estimates rather than as established fact. The qualitative point is widely consistent with how these trade-offs work: the more you confine and isolate, the more you tend to give up in performance, cost, or access to the newest services. An honest sovereignty decision weighs those costs against the actual obligation, rather than maximising sovereignty for its own sake.

A defensible sovereignty assessment does a few unglamorous things. It starts from the organisation's actual obligations rather than from a provider's label. It evaluates the dimensions above together, legal and jurisdictional control, operational control, technical and key control, supply-chain dependencies, portability, transparency, continuity, and contractual rights, rather than treating residency as a proxy for all of them. It keeps the legal layer separate from interpretation, and seeks qualified review where a specific obligation is material. And it records the reasoning, so the decision can be revisited as law and circumstances change.

This is the work of evaluating sovereignty, compliance, operational, and cost criteria together in support of a cloud workload decision, rather than reading any single dimension in isolation. A control layer that helps an organisation make and record those evaluations can support the assessment, but it does not replace legal judgement or determine compliance. The aim is an honest profile across dimensions, not a claim that any architecture is fully sovereign.

Two honest caveats belong here. First, the likelihood that a foreign-access risk is actually realised is genuinely contested and hard to quantify. Some accounts point to low recorded numbers of cross-border production orders, while others note that secrecy regimes make such numbers an unreliable measure [S55]. The right posture is to treat the risk as real but uncertain, and to size the response to the sensitivity of the workload, rather than to assume either that it never happens or that it is constant. Second, sovereignty regulation and guidance continue to develop, and specific positions taken by individual regulators should be checked against current, primary sources before they are relied upon. The framework in this article is durable; the regulatory details around it are not static.

Data residency answers where. Sovereignty answers under whose authority, and operated by whom, with which keys, and provable how. A region selector addresses the first and leaves the rest open. For a regulated organisation, the useful move is to stop asking whether a service is "sovereign" and start asking how it scores across the dimensions that matter for a specific obligation.

Map which sovereignty dimensions your current architecture actually satisfies, and which you have been assuming because the data sits in-region. The gap between the two is usually where the real exposure lives.