Residency Is Not Sovereignty
Data sovereignty in software contracts turns on a distinction most buyers miss: data residency is about where data is stored; data sovereignty is about whose laws govern it. The two come apart sharply in practice. Even when data sits in a data centre in Frankfurt or Paris, if it is managed by a US-headquartered provider it can be reached under the US CLOUD Act — without involving the data subject or any European authority. Residency is a configuration setting; sovereignty is a legal status, and only the contract can pin it down.
That gap is why sovereignty has become a procurement criterion rather than a compliance afterthought. It sits alongside the data protection obligations covered in our GDPR and software contracts guide — SCCs allocate responsibility for transfers, but they do not neutralise extraterritorial government access — and both belong in the governance operating model set out in the compliance and governance guide.
The Law: CLOUD Act, Data Act, DORA
Three legal instruments now shape sovereignty terms. The first is the US CLOUD Act, which creates the extraterritorial reach described above and sits in direct tension with the GDPR. The second is the EU Data Act, in force since September 2025, which regulates international and third-country governmental access to non-personal data and requires cloud providers to take legal, technical, and organisational measures to prevent unlawful access or transfer of EU-held data. The third is the Digital Operational Resilience Act (DORA), which from 2025 obliges financial-services firms to ensure their ICT providers meet stringent resilience and continuity standards — pushing regulated buyers toward EU-based or radically more transparent providers.
For an enterprise buyer the message is consistent: the location of the data is necessary but not sufficient. The contract must address who operates the service, who holds the encryption keys, and what happens when a foreign authority makes a demand. These questions also bear on continuity, because where data sits determines whether you can lawfully recover it elsewhere — the link to software escrow and exit planning.
Data stored in Frankfurt but operated from Seattle is resident in Europe and sovereign to the United States. Only the contract — operational control, key custody, and a clear stance on government demands — closes that gap.
Sovereign Cloud Options and SEAL Levels
The hyperscalers have responded with sovereign offerings, and the EU has begun to define what "sovereign" must mean. The European Commission's Cloud Sovereignty Framework translates the concept into measurable procurement criteria across eight objectives, and introduces Sovereignty Effectiveness Assurance Levels (SEAL) running from SEAL-0 (no sovereignty) to SEAL-4 (a full EU supply chain from chips to software). Under the Commission's own €180m sovereign-cloud procurement, providers had to reach SEAL-2 — abiding by EU law without requiring customers to add their own technical safeguards — to be eligible.
On the vendor side, Microsoft completed its EU Data Boundary in February 2025 and now markets a Sovereign Public Cloud with European-controlled operations and customer-held encryption keys, while Google has expanded its sovereign-cloud portfolio with in-region operational models and validation services. These options carry a premium and real functional trade-offs, so the right SEAL level is a business decision, not a default. The Microsoft vendor hub details where the EU Data Boundary applies, and the commercial structuring of any such commitment runs through cloud contract negotiation.
The Clauses to Negotiate
Sovereignty is won or lost in a handful of clauses. Specify the data-residency region in writing rather than relying on a console setting. Define operational sovereignty — who can access the data, and from which jurisdiction — and require that support and administration occur within the agreed region for regulated workloads. Address government-access demands explicitly: notification obligations where lawful, and a commitment to challenge overbroad requests. Secure customer-held encryption keys so the provider cannot unilaterally decrypt. And require advance notice of any change to processing location or sub-processor that would alter the sovereignty position.
For regulated sectors, align these terms with DORA and with the residency expectations covered alongside FedRAMP and EU AI Act obligations, since a single agreement increasingly has to satisfy all of them. The Cloud Contract Framework white paper sets out the full clause set. To pressure-test a sovereign-cloud commitment before you sign, request a confidential briefing.
Operationalising Sovereignty Across the Estate
Sovereignty clauses are only as good as the understanding of which data they need to protect. The starting point is a data-flow inventory: a map of what categories of data each major system holds, where they are stored, who operates the platform, and from which jurisdictions it is administered. Most enterprises discover, when they build this map, that a meaningful share of regulated data sits in services they had assumed were domestic but are in fact operated under foreign control — exactly the residency-versus-sovereignty gap that the contract is meant to close.
With the map in hand, classify workloads by sensitivity and match each to an appropriate assurance level rather than applying a single standard everywhere. A marketing analytics platform and a core banking system do not warrant the same sovereignty posture; forcing both to the highest SEAL tier wastes budget and functionality, while leaving the banking system at a low tier is a regulatory failure. The Cloud Sovereignty Framework's tiered SEAL model exists precisely to support this kind of proportionate decision. Embed the resulting requirements into procurement so sovereignty is assessed before signature, not retrofitted after a regulator asks the question.
Sovereignty is also not a one-time determination, because the position of a service can change without the customer touching it. A provider that restructures its operations, shifts support to a new region, or is acquired can move a workload from compliant to non-compliant overnight — which is why advance-notice and change-control clauses matter as much as the initial residency commitment. Review the classification on a fixed cadence and whenever a vendor announces an operational or ownership change, and keep an exit path open for the most sensitive workloads so that a deterioration in a provider's sovereignty posture does not trap you. Treated as a living control rather than a procurement checkbox, sovereignty becomes something the enterprise can actually defend to a regulator, not merely assert.