Sovereignty Is a Stack of Controls, Not a Place

A sovereign cloud works by binding stored and processed data to a chosen jurisdiction through enforceable controls over location, legal exposure, operator access, encryption keys, and software operation, instead of treating a border as protection by itself. Sovereignty in that sense is a stack of five separable controls, and a service qualifies as sovereign only to the degree that the weakest of the five holds. A strong data center location fails if a foreign court reaches the operator, strong encryption fails if the operator holds every key, and strict local staffing fails if software updates arrive from an uncontrolled foreign pipeline without review or refusal rights.

The five controls answer different questions and fail in different ways. Location decides the territory holding hardware and copies. Legal exposure decides which states can compel disclosure. Operator access decides which employees and contractors can reach systems in practice. Key custody decides which party can decrypt data or authorize decryption. Software and exit decide which code runs the platform and whether a customer can leave without losing data or function. Separation matters because marketing language often merges the five into a single country label, while contracts, court orders, and engineering choices pull each control toward a different jurisdiction and a different holder with different duties.

European and American law illustrate the separation with unusual clarity. The General Data Protection Regulation, Regulation 2016/679 of the European Union, governs personal data processing and restricts transfers outside the European Economic Area under conditions set in Chapter Five. The Clarifying Lawful Overseas Use of Data Act of the United States, enacted in 2018 and called the CLOUD Act, requires covered providers to disclose data within possession, custody, or control regardless of storage location. A platform placed in Frankfurt can therefore sit in Germany, employ German operators, and still face an American disclosure duty through a parent company incorporated in the United States.

Providers answer that tension through distinct operating structures rather than through geography alone. Examples include Amazon Web Services with a European sovereign platform organized in Germany, Microsoft with data boundary commitments for European customers, Google Cloud with partner-operated offerings in France through S3NS with Thales, and Oracle with isolated regions for government customers. Each structure allocates board authority, support access, incident response, and update control differently. Legal form becomes part of engineering because the employer of an administrator, the parent of a subsidiary, and the holder of administrative credentials determine which orders can reach a system and which refusals carry legal force in a dispute.

Assessment therefore follows the chain rather than the label. Procurement records for a hospital in Ontario, a tax authority in the Netherlands, or a defense supplier in Australia gain value only when each control names a holder, a jurisdiction, a contract term, and a technical test. Location receives a facility address and a replication map. Legal exposure receives a disclosure protocol. Operator access receives identity logs and clearance rules where law imposes them. Key custody receives a hardware security module design. Software and exit receive source, update, export, and deletion terms. A gap in any single record lowers the whole claim to that gap, regardless of strength elsewhere.

The Problem a Sovereign Cloud Exists to Solve

The problem begins with a mismatch between where computing happens and where authority sits. A ministry in France, a bank in Singapore, or a hospital group in Brazil can rent computing capacity from a provider headquartered in another state, administered from a third state, and built from software maintained in a fourth state. Each link creates a lawful path for a foreign order, a foreign intelligence demand, or a foreign sanctions rule to reach data that local law treats as protected. Ordinary hosting contracts allocate price, uptime, and liability with precision, yet leave that chain of foreign authority largely untouched and largely untested.

The dispute between Microsoft and the United States government over email stored in Dublin made the mismatch concrete. Federal investigators sought messages held in Ireland in 2013, Microsoft refused disclosure under a domestic warrant theory, and litigation reached the Supreme Court of the United States in the case called United States v. Microsoft Corp. Congress then passed the CLOUD Act in 2018, and the Court vacated the case as moot. The sequence settled a narrow warrant question while confirming a broader principle for cloud design: possession, custody, and control can matter as much as the physical address of a disk.

European concern deepened through litigation over transatlantic transfers. In the judgment called Data Protection Commissioner v. Facebook Ireland and Maximillian Schrems, delivered on July 16, 2020, the Court of Justice of the European Union invalidated the Privacy Shield framework for transfers to the United States. The Court cited American surveillance law, including Section 702 of the Foreign Intelligence Surveillance Act of 1978, and limits on redress for European data subjects. The ruling did not ban American providers. The ruling instead exposed a structural conflict between Regulation 2016/679 and a foreign legal system that could compel access without equivalent safeguards.

Other states answer the same pressure through localization and state access rules of varying severity. The Cybersecurity Law of China, effective in 2017, requires operators of critical information infrastructure to store personal information and important data collected in China within China. The Data Security Law of China of 2021 restricts provision of data stored in China to foreign judicial or law enforcement bodies without approval. The Federal Law on Personal Data of Russia, amended in 2014, requires databases holding personal data of Russian citizens to sit in Russia. Each statute treats location as a lever of state authority rather than as a neutral engineering choice.

Sectors with duties of confidentiality feel the conflict first and most sharply. Defense contractors handle export-controlled technical files under the International Traffic in Arms Regulations of the United States. Health systems hold records under the Health Insurance Portability and Accountability Act of 1996. Central banks and payment processors operate under prudential supervision that demands audit access, incident reporting, and recovery inside defined borders. For such institutions, loss of control rarely appears as theft alone. Loss appears as a compelled disclosure order served on a parent company, a support session opened from a foreign office, or an update channel that local administrators cannot inspect, delay, or reject. Insurance groups face similar duties under solvency supervision in the European Union, where Directive 2009/138/EC, adopted in 2009, ties risk governance to supervisory access and reporting. A failure in any one setting exposes contracts, licenses, and public trust at the same time for the operator.

Layer One: Where the Data Physically Sits

Physical location is the oldest control and the easiest to audit, and facility design explains why place still matters even though place alone settles little, since how data centers work determines power redundancy, network entry points, media handling, and the legal address at which officers can be served. A sovereign deployment names exact facilities rather than a marketing region, records street addresses in contracts, and limits construction, maintenance, and physical entry to parties under local authority. In Germany, a deployment tied to facilities in Frankfurt and Berlin faces German construction, energy, employment, and policing law at the building level before any dispute over data begins.

Data residency gives location a narrower technical meaning that contracts often blur. Residency describes where particular data rests, and a complete residency map covers far more than a primary database. Production records, replicas, backups, archives, caches, search indexes, message queues, crash dumps, support logs, and telemetry each follow separate placement rules inside large platforms. A database pinned to a facility in Amsterdam satisfies little if nightly backups replicate to Ireland, support logs flow to the United States, and deleted records persist in an archive in Sweden. Residency therefore demands an inventory by data class, with a named region and a retention period attached to every copy.

Geography also shapes failure and recovery in ways that law cannot repeal. Flood risk on the Dutch coast, seismic exposure near Istanbul, heat stress in Arizona, and grid instability in South Africa all affect site selection for facilities that must run without interruption. Distance adds latency measured in milliseconds, and latency governs whether a trading system in London, a hospital imaging archive in Toronto, or a government portal in Canberra can use a distant region at all. Sovereign design accepts some inefficiency as the price of jurisdiction, placing capacity inside the territory that claims authority even when a foreign site offers cheaper power or faster links.

Providers translate location into region architecture with uneven precision. Amazon Web Services opened a region in Paris in 2017 and a region in Milan in 2020, Microsoft built data center campuses in Dublin and Amsterdam, and Google Cloud opened a region in Warsaw in 2021, each step placing hardware under European law at the facility level. Newer sovereign structures tighten the promise further. Operations planned for Brandenburg in Germany for the AWS European Sovereign Cloud separate European personnel, European corporate control, and European support from the wider company. The distinction matters because a standard region sells proximity, while a sovereign region sells a bounded physical and corporate perimeter.

Physical control extends to hardware life cycles that receive less attention than buildings. Servers arrive through supply chains that cross Taiwan, South Korea, and the United States, and firmware from vendors in several states runs below the operating system. Disks leave service under destruction rules that vary by contract, and a certificate from a facility in Lyon or Madrid carries weight only if serial numbers match retirement records. Media sanitization practice guided by the National Institute of Standards and Technology Special Publication 800-88, first issued in 2006 and revised in 2014, gives auditors a shared reference for clearing, purging, and destroying storage devices. Auditors test the map against network traces and backup schedules, since a single unrecorded copy outside the territory defeats the residency claim in practice during inspection.

Layer Two: Which Law Can Reach the Data

Legal exposure asks a harder question than location because statutes follow persons and companies as readily as territory. A provider incorporated in Delaware, listed in New York, and employing administrators in Hyderabad carries duties from each jurisdiction into daily operations. Corporate structure decides which entity signs the customer contract, which entity employs support staff, which entity holds administrative credentials, and which entity receives a court order first. Sovereign design treats that structure as a technical fact, documented alongside network diagrams, because a disclosure order served on the wrong affiliate can still reach the right systems through shared tooling and shared personnel.

Does storing data in a country keep it under that country’s law alone?

No. Storage in one country places data under that country’s law, but other states may claim reach through the provider that controls the data. The US CLOUD Act of 2018 follows control rather than location, while European rules under the GDPR restrict transfers and disclosure in conflicting situations.

The CLOUD Act states the control principle in statutory form. Enacted on March 23, 2018 as part of the Consolidated Appropriations Act of 2018, the statute amended the Stored Communications Act of 1986 and obliges covered providers to disclose data within possession, custody, or control regardless of where that data sits. A challenge mechanism allows a provider to seek modification or quashing of an order that conflicts with law of a qualifying foreign government, a category tied to executive agreements on access to data. The United States signed such an agreement with the United Kingdom in 2019 and with Australia in 2021, each agreement setting reciprocal rules for cross-border demands.

European law pushes from the opposite direction through Regulation 2016/679. Article 48 of the GDPR provides that a judgment of a court in a third country requiring transfer or disclosure of personal data may be recognized or enforceable in the European Union only if based on an international agreement, such as a mutual legal assistance treaty, between the requesting country and the Union or a member state. Chapter Five of the same Regulation conditions transfers on adequacy decisions, appropriate safeguards, or narrow derogations. A subsidiary in Ireland that receives an American order for data of French citizens therefore faces two valid legal commands pointing in opposite directions, with penalties attached to disobedience of either command.

Blocking statutes and secrecy laws widen the field of conflict beyond Europe and the United States. Article 36 of the Data Security Law of China of 2021 bars organizations and individuals in China from providing data stored in China to foreign judicial or law enforcement authorities without approval from competent Chinese authorities. Swiss banking secrecy under Article 47 of the Federal Act on Banks and Savings Banks of 1934 criminalizes certain disclosures by bank personnel. French Law Number 68-678 of July 26, 1968 restricts communication of economic and technical information for use in foreign proceedings. Each statute converts a routine disclosure request into a conflict-of-laws problem that contract language alone cannot dissolve.

Resolution therefore depends on design choices made before any order arrives. A locally incorporated operator with local directors, local administrators, and no foreign parent holding administrative access presents a court with a different target than a branch of a foreign platform. Contract clauses can require notice to the customer where law permits notice, narrow compliance to the entity holding the data, and fund litigation against overbroad orders.

The CLOUD Act and the End of Location as a Shield

The Clarifying Lawful Overseas Use of Data Act, enacted by the United States Congress in March 2018 and known in shortened form as the CLOUD Act, settled a jurisdictional question by removing geography from the answer. The statute amended the Stored Communications Act of 1986 and provided that a provider of electronic communication service or remote computing service must disclose the contents of a wire or electronic communication, and other records pertaining to a customer, whenever that material sits within the provider’s possession, custody, or control, regardless of whether the material is located inside or outside the United States.

The dispute that forced the question began in December 2013, when federal investigators obtained a warrant under the Stored Communications Act for the contents of an email account held by Microsoft. Microsoft stored the account contents in a data center in Dublin, Ireland, and refused to produce the material, arguing that an American warrant stopped at the border. A magistrate judge and then a district judge ruled against Microsoft, and the company carried the case upward. In July 2016 the United States Court of Appeals for the Second Circuit ruled for Microsoft, holding that the Stored Communications Act contained no clear statement of extraterritorial application and that the seizure authorized by the warrant would occur where the data sat, in Ireland.

The Supreme Court of the United States granted review, heard argument in February 2018, and never decided the underlying question. Congress passed the CLOUD Act weeks after oral argument, the President signed the measure on March 23, 2018 as part of a consolidated appropriations law, and the Department of Justice obtained a replacement warrant under the amended statute. On April 17, 2018 the Supreme Court vacated the Second Circuit judgment and remanded with instructions to vacate the district court rulings as moot, in the case captioned United States v. Microsoft Corp.

The amended statute did add a comity mechanism, and the limits of that mechanism define the practical exposure. A provider may move to modify or quash process where disclosure would require a violation of the law of a qualifying foreign government, meaning a government that holds an executive agreement with the United States under the CLOUD Act framework, and where the interests of justice favor relief after a multi-factor balancing test. The United Kingdom signed the first such agreement in October 2019, and Australia signed a further agreement in December 2021. For a customer in a state without an agreement, the statutory challenge route narrows sharply, and common law comity arguments remain discretionary rather than guaranteed.

For the five-control test, the CLOUD Act attacks the second control, legal exposure, without touching the first control at all. A residency contract can promise that disks stay in Amsterdam while the parent company that owns the disks, employs the engineers, and answers American process remains unchanged, and the promise and the exposure then coexist without contradiction. Microsoft itself, through President Brad Smith, had argued in the Ireland litigation that unilateral extraterritorial warrants threatened the trust on which cross-border computing depended, while the Department of Justice argued that a control test merely reflected how providers treat data as movable across a global network. The statute adopted the government reading on reach while creating the agreement framework that the technology sector had sought for cross-border requests. Location remained a fact about hardware. It ceased to function as a shield.

The European Answer: Transfer Law After Schrems II

European law answered the same problem from the opposite direction, by regulating the transfer rather than the provider. The General Data Protection Regulation, Regulation 2016/679 of the European Union, adopted in April 2016 and applicable from May 2018, governs personal data under the Charter of Fundamental Rights of the European Union. Chapter V of the Regulation, spanning Articles 44 to 49, permits a transfer of personal data to a third country only where the conditions of the Regulation are met, through an adequacy decision by the European Commission, through appropriate safeguards such as standard contractual clauses or binding corporate rules, or through a narrow derogation for specific situations.

The judgment that gave Chapter V its force was delivered on July 16, 2020 by the Court of Justice of the European Union in Data Protection Commissioner v. Facebook Ireland and Schrems, known as Schrems II. The Austrian lawyer and activist Maximilian Schrems had complained to the Irish Data Protection Commissioner that Facebook Ireland transferred personal data to Facebook, Inc. in the United States, where American surveillance law exposed the data to access by intelligence agencies without protections essentially equivalent to European standards. The Grand Chamber invalidated Commission Implementing Decision 2016/1250, the Privacy Shield adequacy finding, on the ground that American surveillance programs were not limited to what was strictly necessary and that European data subjects lacked effective judicial redress against American authorities. The same judgment preserved standard contractual clauses as a valid transfer instrument in principle, while imposing on exporters and importers a duty to verify, case by case, whether the law of the destination country allowed the importer to honor the clauses in practice.

The American authority at the center of the reasoning was Section 702 of the Foreign Intelligence Surveillance Act. The underlying statute dates to the Foreign Intelligence Surveillance Act of 1978, Section 702 was added by the FISA Amendments Act of 2008, and Congress reauthorized Section 702 in April 2024 with a two-year extension and procedural amendments. Section 702 permits the Attorney General and the Director of National Intelligence to authorize targeting of persons reasonably believed to be located outside the United States, who are not United States persons, to acquire foreign intelligence information, with assistance compelled from electronic communication service providers.

Maximilian Schrems and NOYB, the European Center for Digital Rights, maintained that Section 702 and Executive Order 12,333 made transfers to American providers structurally incompatible with the Charter, because contractual clauses bind companies and cannot bind the National Security Agency. The European Data Protection Board supported a strict version of that reading in Recommendations 01/2020, urging exporters to add technical supplementary measures, above all encryption with keys held solely in Europe, and to suspend transfers where effective measures were unavailable. The opposing reading, advanced by the European Commission under Justice Commissioner Didier Reynders and by Meta Platforms Ireland in litigation that followed, held that reforms in American law could restore equivalence. The Commission adopted an adequacy decision for the Data Privacy Framework in July 2023, resting on an executive order of October 2022 that limited signals intelligence and on a Data Protection Review Court for European complaints.

The dispute turned on a specific mechanism, compelled assistance under Section 702, a specific rights instrument, the Charter, and a specific question about whether executive reforms in the receiving state can supply equivalence that a treaty or a statute did not.

Layer Three: The Operator and Its Administrators

The third layer of the stack concerns people rather than statutes. Every operator employs administrators, site reliability engineers, and support staff whose duties require privileged access to the systems that store and move customer data. A hypervisor administrator can snapshot a virtual machine. A storage engineer can clone a volume. A support engineer handling a ticket can collect diagnostic bundles and read logs that contain file names, account identifiers, query strings, error traces, and fragments of the underlying content. Encryption at rest protects a stolen disk and an improperly discarded drive. It does not, by itself, protect plaintext from the platform that must decrypt data to process it, because the running service, the memory of the virtual machine, and the administrative interfaces around the service all stand inside the boundary that disk encryption defends.

Microsoft documents a feature called Customer Lockbox for Azure and Microsoft 365, under which a Microsoft engineer seeking access to customer data to resolve a support incident must obtain explicit customer approval, with the request, the justification, and the access window recorded. Google Cloud offers Access Approval, under which Google personnel require customer authorization for many administrative actions, paired with Access Transparency logs that record actions taken by Google staff. Amazon Web Services describes the Nitro System, a combination of dedicated hardware and a hypervisor with a reduced function set, as a design under which no Amazon employee can access a Nitro-based instance or the data on it through an operational interface.

Delos Cloud, formed by SAP in Germany to deliver Microsoft-based services to the German public sector, places operations in the hands of a German company with personnel in Germany, while the underlying platform technology comes from Microsoft. S3NS, the joint venture between Thales and Google in France, and Bleu, the venture formed by Capgemini and Orange with Microsoft technology in France, follow the same licensed operator pattern, in which a European company holds the customer relationship, staffs the operations, and seeks qualification under the French SecNumCloud framework administered by the National Cybersecurity Agency of France, ANSSI. Sovereignty claims strengthen or weaken with the employment contracts, security clearances, and reporting lines of the people who hold administrative rights.

Personnel controls therefore take concrete forms that a contract schedule can either specify or omit. Vetted operators restrict privileged roles to staff who hold a stated citizenship or residence status and a stated clearance level, require background checks conducted under domestic law, and bar subcontracted support from jurisdictions whose process the customer seeks to avoid. Just-in-time elevation replaces standing privilege with time-limited grants that expire after an incident window, and break-glass procedures reserve emergency access for named scenarios under dual authorization, with two authorized officials required before credentials are released.

Data stored in a Frankfurt region under an operator whose administrators sit in a jurisdiction with compelled disclosure duties, whose support queue routes tickets across continents overnight, and whose engineers hold standing hypervisor rights presents a different risk profile from identical data in the same building under an operator whose administrators are locally vetted, whose support stays within the region, and whose privileged actions require customer approval. Residency describes the building. The operator layer describes the keys to the building, the roster of staff who may enter the machine rooms and the management consoles, and the rules that govern entry. A sovereignty claim that names a region and stays silent about administrators has answered the easiest question in the stack and left the harder question unasked.

The Control Plane Is Where Sovereignty Is Won or Lost

Cloud architecture separates into two planes, and the distinction decides much of the sovereignty argument. The data plane performs the work for which a customer rents the service. It stores objects in buckets, writes blocks to volumes, executes queries, runs virtual machines and containers, and returns results across a network. The control plane governs the data plane. It receives the application programming interface calls that create, modify, and delete resources, authenticates identities and evaluates permissions, applies configuration and policy, provisions networks and attaches disks, starts and stops instances, creates snapshots, assigns encryption keys to workloads, and writes the logs that record what happened. Anyone who compromises or compels the operator interacts with the whole estate through the control plane, because the control plane holds the authority to redefine the estate itself.

An actor with control plane access can create a new administrative credential, grant an existing account a broader role, attach a storage volume to a different machine, copy a snapshot into another region, alter a network rule to permit traffic to an external address, disable a logging configuration, and change retention settings that govern backups. A foreign order served on an operator therefore gains much of its practical value from the control plane.

Microsoft Azure routes management operations through Azure Resource Manager, Amazon Web Services routes management operations through the AWS Management Console and the associated application programming interfaces and identity service, and Google Cloud routes management operations through Cloud Resource Manager and Identity and Access Management. In each architecture the data plane can be pinned to a region in Frankfurt, Paris, or Milan while control plane services, identity stores, telemetry pipelines, and support systems operate across a wider footprint, with metadata about accounts, configurations, resource names, and activity logs processed in locations that a residency statement about stored content does not describe. Metadata carries weight in legal process as well, because account records, access logs, billing records, and configuration histories reveal who held data, when access occurred, and which systems touched the data, even where content remains encrypted.

A partitioned control plane keeps provisioning, identity administration, and logging for a sovereign region inside that region, under the licensed operator, so that an order or an intrusion reaching the global platform does not automatically reach regional management functions. External key management strengthens the partition, since a snapshot copied through an administrative interface remains ciphertext without a key held in a hardware security module under separate custody. The AWS European Sovereign Cloud, announced in October 2023 for Brandenburg, Germany, was described by Amazon Web Services as a physically and logically separate cloud with its own operations and a dedicated European legal structure, a description that placed separation of operations and management at the center of the claim.

An examiner can ask where identity data is stored, where logs and telemetry flow, which legal entity operates the management interfaces, whether a global operations team can override regional administrators, and whether the customer receives tamper-evident records of operator actions. The five-control stack converges at this layer, because legal exposure becomes practical only when a control plane exists through which an order can be executed, operator access becomes dangerous only where the control plane grants broad authority, and key custody matters only where control plane calls depend on keys that the operator cannot supply alone. Sovereignty is won or lost at the layer that issues instructions, for the plain reason that instructions govern everything beneath them.

Layer Four: Encryption and the Custody of Keys

Encryption is the control that separates possession of data from the ability to read data. The distinction matters because encryption, hashing, and encoding are three different operations that loose language often blends into one. Encryption transforms readable data, called plaintext, into unreadable ciphertext through an algorithm and a key, and possession of the correct key reverses the transformation. Hashing, by contrast, produces a fixed length fingerprint through a one way function such as SHA-256, and the original data cannot be recovered from that fingerprint. Encoding, in formats such as Base64, merely changes the representation of data so that a system can carry it safely, and it provides no secrecy at all.

Can a cloud provider read the data it stores for a customer?

It depends entirely on custody of the keys. Where a provider holds both ciphertext and the keys that unwrap it, the provider retains the technical ability to read stored data. Where keys stay in an external system outside provider control, stored data remains ciphertext that the provider cannot plainly read.

Encryption at rest protects data held in object storage, block volumes, databases, and backups, in services such as Amazon S3, Microsoft Azure Blob Storage, and Google Cloud Storage. The Advanced Encryption Standard with a 256 bit key, written as AES-256, is the standard symmetric algorithm for that layer, and providers encrypt whole disks, whole objects, or individual database fields depending on the service design. Encryption in transit protects data moving between a data center and a remote office, and between services inside a platform, most often through Transport Layer Security in version 1.3. Neither layer, standing alone, answers the custody question. Where one party holds the ciphertext and the keys together, encryption functions as protection against an outside thief who steals a disk or intercepts a connection, rather than as protection against the holder itself.

Most platforms use envelope encryption to make key handling workable at scale. A unique data key encrypts a specific object or volume, and a separate key encryption key wraps, or encrypts, that data key for storage beside the ciphertext. The security of the arrangement depends on where the unwrapping key sits and on which identity may ask for it to be used. Authentication and authorization are separate controls at that point of decision. Authentication establishes that a person, a workload, or a service is the identity claimed, through evidence such as a certificate or a signed token. Authorization then decides which actions that proven identity may perform, such as reading one bucket, unwrapping one key, or administering an entire account.

Hardware security modules give that decision a physical anchor. A hardware security module, or HSM, is a dedicated device built to generate and store keys and to perform cryptographic operations inside a tamper resistant boundary, so that key material does not appear in ordinary server memory. Federal Information Processing Standard 140-3 sets validation levels for such modules, and services including AWS CloudHSM, Azure Dedicated HSM, and Google Cloud HSM sell access to validated hardware on a dedicated or shared basis. External key management extends the same logic beyond the provider estate. Under external arrangements offered through AWS Key Management Service, Azure Key Vault, and Google Cloud Key Management Service, and through independent systems such as Thales CipherTrust and Fortanix Data Security Manager, a key can remain in infrastructure that a customer or a chosen third party controls, with the cloud service calling outward when an operation requires that key.

What Customer-Held Keys Change and What They Do Not

Customer-held keys move the center of cryptographic power away from the provider, yet the design details decide how much power actually moves. Bring your own key, abbreviated BYOK, is the weaker form. Under BYOK, an enterprise generates a key inside an on premises HSM or an existing key service and imports a copy into a provider service such as AWS Key Management Service or Azure Key Vault. The origin of the key is therefore external, and provenance records can show where the key was created. Once imported, however, a copy rests inside provider infrastructure and the provider platform uses that copy under policy, so day to day control resembles provider managed custody with an imported starting point.

Hold your own key, abbreviated HYOK, draws a stricter line. Under HYOK, the key never leaves a system that the customer or an independent operator controls, and the provider holds no usable copy. Google Cloud External Key Manager, built with partners including Thales and Fortanix, follows that pattern, as does AWS External Key Store, which connects AWS Key Management Service to an external key manager through a proxy. Each time a covered service needs to encrypt or decrypt data, a request travels to the external system, policy is checked there, and the operation proceeds or fails on that external decision. Microsoft Double Key Encryption applies a related design for sensitive documents in Microsoft 365, with one key in Azure and a second key held by the customer, so that both parties must participate before protected content opens.

The sharpest change concerns compelled disclosure. A court order or a statutory demand served on a provider can compel production of whatever the provider holds and can read. Where a provider holds only ciphertext and lacks the key, production yields ciphertext: storage contents in an unreadable form, rather than documents, records, and messages in plain form. The legal reach of statutes such as the United States CLOUD Act of 2018 does not vanish, because a demand may instead target the customer or the key holder directly. The technical fact nevertheless changes the value of an order aimed at the provider alone. Customer-held keys also create a credible exit and destruction mechanism. Disabling an external key, or destroying it after retention duties end, renders the associated ciphertext unreadable wherever copies sit, a result often described as cryptographic shredding.

The limits are equally concrete, and they define the honest boundary of the control. Metadata remains visible even where content stays sealed. A provider can still observe account identifiers, object sizes, storage locations, access times, network addresses, and patterns of key requests, and that record can reveal a great deal about activity without exposing a single document. Availability stays in provider hands as well. A provider can suspend an account, suffer a regional failure, withdraw a service, or lose a dispute over payment, and key custody grants no power to run workloads on infrastructure that has stopped answering. Service dependence persists through proprietary application programming interfaces, identity systems such as Microsoft Entra ID, logging formats, and managed databases that have no direct equivalent elsewhere. Finally, many software as a service functions, including search indexing, collaboration, and document rendering, require access to plaintext or to a working key during processing. A key held outside the platform can therefore restrict which features function, and a customer that enables those features may hand back, in practice, much of the access that the key arrangement appeared to withhold.

Confidential Computing and the Data in Use Problem

Data passes through three states across its life in a cloud platform, and encryption historically covered only two of those states. Encryption at rest covers stored data, and encryption in transit covers moving data, while data in use, meaning data being computed on inside a processor and held in memory, traditionally sat exposed to the operating system, the hypervisor, and any administrator with control over the host machine. That exposure is the data in use problem. A database query, a payment calculation, or a machine learning inference requires values in a workable form, and the software stack beneath the application could inspect memory at that moment. Confidential computing closes that gap by processing data inside a hardware enforced trusted execution environment, a protected region of a processor that isolates code and data from the host operating system, the hypervisor, and other tenants on the same machine.

The Confidential Computing Consortium, founded in 2019 under the Linux Foundation, gave the field shared definitions and shared open source projects. Founding members included Alibaba, Arm, Baidu, Google, IBM, Intel, Microsoft, Red Hat, Swisscom, and Tencent, a grouping that joined chip designers, cloud operators, and software firms around one vocabulary. The consortium defines confidential computing as protection of data in use through computation inside a hardware based, remotely verifiable trusted execution environment.

The hardware comes in distinct forms from distinct vendors. Intel Software Guard Extensions created enclaves sized for protected portions of an application, while Intel Trust Domain Extensions protect whole virtual machines. AMD Secure Encrypted Virtualization with Secure Nested Paging encrypts virtual machine memory and isolates guests from the hypervisor. Arm Confidential Compute Architecture extends similar aims across the Arm ecosystem, and AWS Nitro Enclaves isolate sensitive workloads on Amazon Elastic Compute Cloud instances by removing interactive access and persistent storage from the enclave design. Cloud services built on those foundations include Azure confidential virtual machines, Google Cloud Confidential VMs, and confidential containers across the major platforms.

Attestation is the mechanism that makes isolation verifiable rather than merely asserted. During attestation, the hardware produces a signed report that records measurements of the code, the configuration, and the environment into which a workload loaded. A relying party, such as an external key manager operated by a bank or a health authority, compares those measurements against expected values and releases a decryption key only where the report matches an approved state.

The limits of the technique follow from a plain fact: a provider still controls the physical machine. Provider staff control firmware updates, power, cooling, networking, and the scheduling of workloads, and a provider can deny service, delay execution, or disconnect an enclave at will, even where the contents of that enclave stay sealed. Side channel attacks remain a documented concern against enclave designs, with research demonstrations such as Foreshadow and Plundervolt showing routes by which information leaked from Intel enclaves under specific conditions. Trust also shifts rather than disappears. Confidence moves from the cloud operator toward the chip vendor, the firmware supply chain, and the attestation service that validates reports, and a defect in silicon or microcode can weaken every tenant built on that foundation. Metadata, timing, and access patterns remain observable from outside the enclave. Confidential computing therefore narrows the set of parties able to read data in use, and it does so with hardware evidence, while leaving questions of availability, physical control, and vendor trust firmly in place.

Layer Five: The Software Stack and Its Licences

Why does the software licence matter to cloud sovereignty?

A license decides who may use, copy, modify, move, and stop using the software that runs a cloud. A vendor that controls those rights can change prices, terms, and access, and can end the service. Open licenses preserve rights to inspect, modify, and self-host the code.

A cloud is software before it is real estate. Hypervisors carve physical servers into virtual machines, control planes schedule workloads and store objects, identity systems sign users in, and databases hold the records that sovereignty debates concern. Licence terms function as a control channel in their own right, alongside data center location and key custody. A proprietary vendor can raise prices at renewal, restrict use on a rival platform, impose audit rights, withdraw a feature, or terminate a service line, and a customer bound to that stack absorbs each change or pays heavily to escape it.

Named cases show the channel in operation. After Broadcom completed its acquisition of VMware in 2023, licensing for VMware virtualization products shifted toward bundled subscriptions, and many customers and partners reported steep cost increases and reduced choice in support arrangements. The dispute pushed governments and large enterprises to reassess dependence on a single hypervisor vendor. Microsoft licensing for Windows Server and SQL Server has likewise shaped cloud choice for years, because terms governing use on third party clouds affect the relative cost of running the same workload on Azure against a competing platform, a practice that drew regulatory scrutiny in Europe.

Open source software inverts the default allocation of rights, and two projects form the open substrate on which many sovereign platforms rest. OpenStack, launched in 2010 by Rackspace and the National Aeronautics and Space Administration, provides an open control plane for compute, storage, and networking, and operators including OVHcloud and Deutsche Telekom have built public cloud services on that foundation. Kubernetes, released by Google in 2014 and governed by the Cloud Native Computing Foundation, orchestrates containers and has become the common scheduling layer across public and private platforms. Around those pillars sit Linux, the KVM hypervisor, PostgreSQL, and Ceph storage, each distributed under licenses that grant rights to run, study, modify, and redistribute the code. An operator with those rights can inspect how a platform behaves, patch a defect without vendor permission, and run the same stack in a different facility under different legal authority.

Open code does not abolish dependence, although it changes the kind of dependence involved. A managed Kubernetes service such as Amazon Elastic Kubernetes Service, Azure Kubernetes Service, or Google Kubernetes Engine still wraps an open core inside a proprietary control plane, proprietary identity integration, and proprietary pricing. Support and distribution choices create further gravity: Red Hat, SUSE, and Canonical sell tested builds, certifications, and long term support that many regulated operators treat as requirements. License changes can also arrive from inside the open world. HashiCorp moved Terraform to the Business Source License in 2023, and the OpenTofu fork continued under the Linux Foundation, while MongoDB had earlier adopted the Server Side Public License for its database. The software layer therefore completes the sovereignty stack with a legal test that sits under every technical control: an operator that cannot lawfully run, inspect, and move the stack does not fully control the stack, regardless of where servers stand or where keys are held.

Open Source as a Sovereignty Instrument

Open source software occupies a distinctive place in sovereign cloud strategy because it addresses a layer of the stack that contracts and data center addresses cannot reach on their own. Sovereignty, understood as a stack of five controls covering location, operations, personnel, law, and code, holds only as far as its weakest layer. A government may control where data sits and who enters the building while running software whose inner workings remain closed to inspection. Open source removes that particular opacity. Source code that can be read can also be audited, and code that can be audited can be checked for undisclosed data flows, weak encryption handling, and dependencies on external services that a sovereign deployment is meant to exclude.

Nextcloud illustrates the model at the collaboration layer. The platform provides file sharing, document editing, calendar, contacts, and video calls as a self-hostable alternative to proprietary office suites, and its server software is distributed under the Affero General Public License. That license matters to sovereignty for two reasons. First, the code running on a ministry server can be inspected in full, including the parts that handle authentication and storage. Second, the copyleft terms require that modified versions offered as a network service remain available under the same freedoms, which limits quiet enclosure of a public deployment. German federal administration adopted Nextcloud as part of its sovereign workplace efforts. Data, identity integration, and update timing remain with the institution rather than with an external provider.

At the infrastructure layer, OpenStack and Kubernetes perform a comparable function. OpenStack supplies open source components for compute, storage, and networking in private clouds, allowing an operator to build an infrastructure service without licensing a proprietary hypervisor stack from a single foreign vendor. Kubernetes, governed by the Cloud Native Computing Foundation, orchestrates containers through an open application programming interface that many vendors and distributions share. A workload packaged for one conformant Kubernetes distribution can in principle move to another, which weakens the hold of any single platform owner over the operator. The standard is open even where the managed service wrapped around it is commercial, and that distinction preserves a migration path if a commercial relationship ends.

The right to fork gives the instrument its final guarantee. If a maintainer changes direction, raises terms beyond reach, or falls under legal pressure in another jurisdiction, a community or a state backed operator can continue development from the existing code under a new name. Forking rarely happens lightly, because a fork inherits the full burden of security patches and compatibility work, but the credible possibility disciplines maintainers in a way procurement clauses cannot.

The limits are equally concrete. Open source transfers responsibility along with control. An institution that self-hosts Nextcloud or operates an OpenStack cloud must patch vulnerabilities, test upgrades, monitor performance, and retain staff able to do that work through holidays and attrition. Commercial support contracts from firms such as Red Hat or SUSE exist partly because many public bodies prefer a paid throat to hold for that maintenance burden. Talent scarcity raises the cost further in smaller administrations. Open code also does not solve hardware dependence, since servers, chips, and network equipment carry their own supply chains. The instrument strengthens one layer of the stack decisively while leaving the others to be secured by other means.

The Licensed Operator Model in France and Germany

The licensed operator model separates ownership of cloud technology from the legal identity of the company that runs it. A hyperscale provider licenses its platform, tooling, and update stream to a distinct company established under national law, and that company operates the service, employs the staff, holds the customer contracts, and answers to national regulators. The arrangement responds to a specific weakness in the sovereignty stack. A subsidiary can place data centers inside a country and hire locally while its parent remains subject to a foreign legal order. A licensed operator interposes a separate corporate person between the customer and the technology owner, so access to systems, support processes, and administrative credentials sits with an entity whose governance the host state has examined and approved.

France produced the clearest examples through its national strategy for the cloud and the SecNumCloud qualification administered by the national cybersecurity agency, ANSSI. S3NS, announced in 2021 and launched as a joint venture between Thales and Google, offers Google Cloud technology operated by a French company under French law. Thales holds the controlling position in the venture, personnel and operations sit in France, and the service pursued SecNumCloud qualification for its trusted cloud offering. The design keeps Google as technology supplier while placing customer relationships, support access, and operational decisions inside the French entity, a company that French authorities can audit and sanction directly.

Bleu follows the same logic with a different technology partner. Formed by Capgemini and Orange in partnership with Microsoft, Bleu was established as a French company intended to deliver Microsoft Azure and Microsoft 365 services under French control. Its data centers sit in France, its operations are staffed under French employment and security rules, and its stated objective from its announcement in 2021 was a platform meeting SecNumCloud requirements. Capgemini brings integration and public sector delivery experience while Orange brings national network infrastructure as a French telecommunications operator. Microsoft supplies the underlying platform under license. The promise is continuity of the Microsoft ecosystem without direct operational dependence on Microsoft, a distinction that only has meaning because the operator is a separate company with its own governance, premises, and cleared personnel.

Germany took a related but lighter path. In 2021 Google Cloud and T-Systems, the information technology arm of Deutsche Telekom, announced sovereign cloud controls for Germany under which T-Systems would manage and supervise key aspects of Google Cloud infrastructure for German customers. The German arrangement emphasized supervised operations, encryption key oversight, and controls over Google personnel access rather than a fully separate joint venture company on the French pattern. The contrast shows that the licensed operator idea exists on a spectrum, from a new national company with its own equity and qualification to a trusted national partner exercising defined control functions over a provider platform.

Licensing is the legal mechanism that makes the separation durable. Agreements define which updates the operator receives, which data the technology owner may never access, and how support requests are handled. Qualification regimes then test whether practice matches paper. Critics note that dependence on licensed updates preserves a channel of foreign influence, since an operator cannot indefinitely maintain a platform it did not create. Defenders answer that sovereignty is comparative rather than pure, and that a qualified national operator raises the cost and visibility of any external interference. The model therefore trades complete independence for operational capability at scale, with national law and national personnel holding the middle layers of the stack.

The Hyperscaler Sovereign Offerings and Their Legal Structures

The large American cloud providers answered sovereign demand not by withdrawing but by building dedicated offerings whose legal structures are as much a part of the product as the technology. Each structure attempts to move the weakest layers of the sovereignty stack, namely corporate control, personnel access, and applicable law, closer to the customer state while keeping the engineering scale of a global platform. The designs differ in how far separation goes. One offering creates a new company in Europe with its own leadership. Another layers policy controls and confidential computing over an existing platform for government customers. A third builds separate regions operated only by residents of the European Union.

Amazon Web Services announced the AWS European Sovereign Cloud in 2023, with its first region planned in the state of Brandenburg in Germany and an investment commitment of 7.8 billion euros through 2040. The structure rests on a separate company incorporated in Germany, with European leadership, European employees in operational roles, and infrastructure dedicated to the sovereign cloud rather than shared with the standard commercial regions. Operational control, including access to data centers and the authority to grant support access, is reserved to personnel located in the European Union. The parent company retains ownership, but the separate incorporation creates a defined perimeter for audits, certifications, and contractual commitments for public sector bodies and regulated industries.

Microsoft took a different route with Microsoft Cloud for Sovereignty, announced in 2022 as an offering for public sector customers built on Azure. Rather than a separate company, the structure layers governance controls over existing regions: data residency commitments through the European Union Data Boundary, sovereign landing zone configurations, policy controls over data location, and confidential computing options that limit operator access to data in use. Transparency logs and contractual terms govern when Microsoft engineers may access customer systems. Security posture tooling sits inside that layered model, and a public sector administrator weighing configuration and threat protection choices can follow defender for cloud explained for the mechanics of the Defender for Cloud service that reports on posture across Azure workloads. The legal weight of the Microsoft model sits in contracts, residency commitments, and audit rights instead of in a new corporate person, which makes it faster to deploy across countries but dependent on enforcement of those commitments.

Oracle completed the trio with the Oracle EU Sovereign Cloud, launched in 2023 with regions in Madrid and Frankfurt. Oracle placed those regions inside separate legal entities established in the European Union, restricted operations and support to personnel residing in the Union, and kept the sovereign regions logically and physically separate from its commercial regions, with no data movement between the two estates. Customer contracts sit with the European entities. The structure resembles the Amazon approach in its use of incorporation and residency, applied at region level rather than through a single new cloud. Oracle aimed the service at public bodies and private companies subject to European data rules, including regulated banks and health providers.

Across the three offerings, the pattern is a gradient of separation. Incorporation in Europe, resident only operations, dedicated infrastructure, and contractual access controls each address a named layer of the stack, and each leaves the parent relationship intact to a different degree. The structures also create testable claims. A regulator can verify where staff reside, which company signs the contract, and whether data crosses a stated boundary.

Gaia-X and the Attempt to Federate Sovereignty

Gaia-X began in 2020 as a Franco-German initiative, launched by ministers Bruno Le Maire of France and Peter Altmaier of Germany, with an ambition larger than any single national cloud. Rather than building one European provider to rival the American hyperscalers, the project set out to define shared rules under which many providers could interconnect and offer services that customers could compare and combine. The underlying diagnosis was that no single European country, and no single European company, commanded the scale to replicate a hyperscaler alone. Federation was the alternative. Providers would keep their own infrastructure while adopting common standards for identity, data description, portability, and compliance, so that a customer could move workloads between participants or assemble services from several of them under a shared trust framework.

The institutional form chosen for that ambition was an association under Belgian law, the Gaia-X European Association for Data and Cloud, organized as an AISBL and headquartered in Brussels. Incorporation in Belgium placed the body outside the two founding states and inside the legal orbit of the European Union institutions, a deliberate signal that the project belonged to Europe rather than to Paris or Berlin. Membership opened to companies and institutions inside and outside Europe, including, controversially for some founding supporters, the American hyperscalers and Chinese technology firms willing to accept the association rules. A standards body gains influence when large providers adopt its specifications, even if the original political impulse was to reduce dependence on those same providers. Governance through an association also limited what Gaia-X could compel, since an AISBL coordinates members rather than directing them.

The labelling framework became the most concrete output of that coordination. Gaia-X defined compliance criteria and labels intended to state, in a comparable form, what a service guarantees about data location, applicable law, portability, and protection against access under foreign legal orders. Higher label levels were designed to identify services meeting stricter European requirements, including immunity claims in relation to extraterritorial legislation such as the United States CLOUD Act. A catalogue and clearing house functions were meant to let customers filter services by those labels instead of reading separate legal opinions for every vendor. In stack terms, the labels attempt to make the legal and operational layers of sovereignty legible at the point of purchase.

Progress proved slower than the founding rhetoric suggested. Building consensus among hundreds of members with opposed commercial interests produced specifications at a measured pace, and early deliverables leaned toward architecture documents and compliance frameworks rather than running infrastructure that customers could buy. National projects continued in parallel, including the French qualification regime and the German sovereign cloud efforts, which showed that federation complemented rather than replaced state level action.

The attempt still matters for what it reveals about the structure of the problem. Gaia-X treated sovereignty as a property that could be standardized, labelled, and traded across borders, instead of a property that only a national operator could supply. If federation succeeds even partially, the stack of five controls becomes portable: a customer can demand the same legal, operational, and portability guarantees from providers in several countries and can switch when guarantees weaken. If it stalls, the default remains a contest between national champions and global platforms. Either outcome confirms the founding insight that sovereignty in cloud computing is decided as much in standards bodies and association statutes as in data centers.

Certification: SecNumCloud, C5 and the Label Problem

Certification turns a political claim into an audited claim, and the difference matters because sovereignty fails in details that marketing language hides. A provider can promise local hosting, local staff, and local law, yet the promise carries weight only when an independent body has tested the controls behind it, defined the scope, and published conditions that a buyer can inspect. France and Germany built the two most influential European models, and each model answers a different question. One reaches toward immunity from foreign legal compulsion. The other concentrates on disciplined security practice.

France places its qualification in the hands of the national cybersecurity agency, ANSSI, under the SecNumCloud framework. Version 3.2 of the requirements sets demanding conditions on data location, access management, incident handling, encryption, personnel, and the legal structure of the provider. Qualification follows evaluation by approved assessors and remains subject to surveillance. The doctrine behind the French scheme goes further than ordinary security assurance. A qualified provider is expected to be immune to non-European Union law, meaning that corporate ownership, governance, and support arrangements must not expose the service to extraterritorial orders from a foreign state. That expectation targets legislation such as the United States CLOUD Act, under which a provider subject to United States jurisdiction may face a demand for data held abroad.

The French position therefore treats legal exposure as a security property in its own right. A system can resist intrusion and still surrender information through a lawful order served on a parent company. SecNumCloud responds by examining who controls the provider, where decision makers sit, and whether foreign authorities hold a practical route to compulsion. Germany takes a narrower path through the C5 criteria catalogue issued by the Federal Office for Information Security, the BSI. C5 defines control objectives across organization, physical security, system operations, access control, encryption, and incident management, and an independent auditor attests whether a provider meets them. An attestation can address design alone or operating effectiveness across a defined period. C5 strengthens confidence in practice without imposing the French immunity doctrine, so a service can satisfy C5 and remain exposed to foreign legal process through its ownership.

At European level, the draft EUCS certification scheme, developed under the Cybersecurity Act of 2019, proposes a common cloud label with basic, substantial, and high assurance levels. The dispute inside the draft concerns the high level. Some member states argue that high assurance should include sovereignty requirements limiting non-European control, foreign legal exposure, and support access from outside the Union. Other member states and industry groups warn that such conditions fragment the market, raise barriers for established providers, and convert a security scheme into industrial policy. The disagreement is structural rather than technical, because a label cannot settle a political question about acceptable dependence while pretending to measure only controls.

That dispute exposes the label problem. A label certifies a scope, not a whole service. The scope names a particular offering, region, configuration, and period, while adjacent identity systems, support tooling, telemetry pipelines, and subprocessors may sit outside the evaluated boundary. Certificates also age as platforms change through patches, acquisitions, and subcontracting. A buyer that reads only the badge inherits every gap outside the boundary. A buyer that reads the scope statement, the evaluation annexes, and the surveillance conditions learns where protection ends. Certification remains valuable, but only as a map with edges, and sovereignty holds no further than the weakest edge on that map.

Five Controls and the Ways Each One Fails

Sovereignty rests on a stack of controls, and each control guards a different route by which an outside party could reach data, compel disclosure, or shape operations. Location decides where systems run. Law decides whose orders bind the operator. Access decides which hands can touch the platform. Keys decide whether stored data can be read. Software, personnel, and exit rights decide whether dependence deepens or remains reversible. The table settles a narrow point: each control governs a distinct failure path, and strength in one row does not repair weakness in another.

Control	What it governs	How it is implemented	How it fails
Location	Physical and logical placement of data and workloads	Residency enforced in configuration across named local data centers	Replication or backup policies quietly move copies to foreign regions
Legal exposure	Laws that can compel disclosure or technical assistance	Provider structured under local law without foreign parent control	A parent abroad receives an order that local staff cannot resist
Operator access	Ability of administrators to reach systems and data	Privileged sessions limited to vetted local staff and fully recorded	Global support queues grant temporary access that becomes routine practice
Key custody	Control over encryption keys and every use of them	Keys held in local hardware modules under trustee control	Provider controls the key service and can be compelled to decrypt
Software stack	Code, dependencies, and updates running the platform	Signed builds, source review, and local approval for changes	Closed foreign components accept automatic updates without local inspection
Personnel clearance	Trust placed in people holding privileged operational roles	Background checks, residency rules, and strict separation of duties	Scarce cleared staff concentrate duties and weaken independent review
Exit and portability	Ability to leave without losing data or function	Standard formats, tested exports, and deletion duties after migration	Proprietary services embed data and raise switching costs beyond reach

The rows interact in ways that single audits often miss. Local placement means little when a foreign administrator can open a privileged session, and local staff provide limited protection when encryption keys sit in a service controlled elsewhere. Strong key custody loses force when the software stack accepts unreviewed code, because code can change what a system records, transmits, or reveals. Clearance rules lose force when a contract prevents departure, since a customer trapped with a provider has accepted dependence as a permanent condition rather than a managed risk.

Failure also compounds across rows. A backup copied abroad creates a location problem and a legal problem at the same time, because the copy falls under another jurisdiction and another set of disclosure duties. A support exception granted during an outage can normalize remote access, weaken personnel controls, and expose keys through diagnostic tooling in a single incident. For that reason, assessment has to trace complete paths from an external demand or intrusion to the data itself, checking every control on the path rather than scoring each control in isolation. The stack holds only as far as its weakest control, and the weakest control is often the exception that operations staff treat as temporary, minor, or purely administrative.

The Cost of Running a Cloud at National Scale

Sovereign cloud costs more than ordinary cloud for reasons built into its design. Duplication comes first. A national or regional provider must build data centers, networks, power arrangements, cooling, spare hardware, and security operations inside a defined territory, even where a global provider already operates efficient facilities nearby. Redundancy must also stay inside the boundary, so resilience requires at least two local sites rather than a failover path into a larger foreign region. Every duplicated layer carries capital cost before the first customer arrives, and idle capacity held for public sector peaks or emergencies raises unit costs throughout the year.

Personnel adds a second premium. Cleared or residency restricted staff are scarce, and scarce staff command higher wages, longer recruitment cycles, and expensive training. Coverage across nights, weekends, and holidays multiplies the requirement, because a sovereign service cannot route an overnight incident to a follow center in another jurisdiction without reopening the access question. Retention matters as much as hiring, since the departure of a small number of senior engineers can strip a platform of knowledge that documentation never captures fully. Providers also pay for separation of duties, independent review, and audit preparation, all of which consume skilled hours that a leaner commercial operation would spend on product development.

Energy contracts deepen the effect, because a small buyer lacks the volume to secure favorable long term power prices or priority access to grid capacity during periods of scarcity and expansion. Scale creates the deepest disadvantage. Hyperscalers spread research, hardware purchasing, energy contracts, and platform engineering across an enormous global customer base, and high utilization keeps their unit costs low. A sovereign provider serves a smaller market, negotiates smaller hardware orders, and refreshes equipment on longer cycles. Demand for sovereign artificial intelligence compute sharpens the gap, because understanding how AI accelerators work shows why serious clusters need dense power, fast interconnects, specialized cooling, and steady replacement of short lived hardware. A small national facility pays near market prices for accelerators while spreading the supporting infrastructure across far fewer workloads, so each unit of compute carries a heavier share of the building, the network, and the staff.

Payment falls on identifiable parties rather than on an abstract market. Governments pay through procurement premiums, anchor tenancy, direct subsidy, or state backed financing. Regulated companies pay through higher service prices, and households pay where those companies pass costs into banking, energy, health, or telecommunications bills. Taxpayers pay again when a state funds capacity that commercial demand alone would not sustain. A hidden form of payment also appears as narrower features, slower hardware refresh, and fewer integrated services, costs that users bear as lost capability rather than as a line on an invoice.

None of that makes the expenditure irrational. The premium buys insurance against foreign compulsion, continuity during geopolitical conflict, domestic technical skills, and bargaining power that a pure customer never holds. The failure mode lies in paying the premium without securing the control, for example by funding local buildings while leaving keys, software, and support under foreign direction. Honest accounting therefore pairs every cost with the control it purchases, names the party bearing the cost, and states which dependence remains after the money is spent. Sovereignty bought at national scale is a long public commitment, renewed through every refresh cycle, hiring round, and contract extension.

Operations: Patching, Telemetry and Support Access

Daily operations test sovereignty more severely than architecture diagrams, because operations involve repeated decisions under time pressure. Patching presents the sharpest tension. A critical vulnerability demands rapid correction, while sovereign control demands local review of code arriving from a foreign vendor. Delay leaves known holes open for attackers, and haste installs unexamined changes across the platform. Mature operators resolve the tension through staged deployment, signed packages, automated testing against local configurations, and an emergency path that permits fast installation with retrospective review inside a fixed window. The cadence itself becomes a control, documented in advance rather than improvised during a crisis, with clear authority for the official who accepts either risk. Patch records then show which systems run approved versions and which carry accepted exceptions.

Can a software update become a channel of foreign control?

Yes. An update signed abroad can alter logging, access rules, encryption behavior, or telemetry destinations before local staff detect the change. Control therefore requires advance notice, reproducible builds, independent signature verification, staged deployment, rollback rights, and a contractual power to refuse a release without losing support.

Telemetry creates a quieter exposure. Monitoring systems collect logs, performance metrics, error traces, and usage patterns, and vendor platforms often receive that material for analysis outside the territory. Individual records may look harmless, yet aggregated telemetry can reveal workload timing, user behavior, system weaknesses, and the shape of sensitive applications. Sovereign operation keeps collection local where possible, strips identifiers before any external transfer, limits retention, and treats diagnostic exports with the same discipline applied to customer data. Contract terms must state where telemetry flows, which staff can read it, and how long copies survive after a support case closes. Access reviews add a further operational test, because dormant accounts, expired approvals, and unrecorded vendor sessions reveal whether written rules survive contact with daily practice or exist only as policy documents filed for auditors and procurement committees during contract renewal.

Remote support access requires similar discipline. Vendor engineers hold deep product knowledge that local teams may lack, so a blanket refusal can prolong outages and damage the service the controls exist to protect. The workable model is conditional access rather than permanent reach: named engineers, approval for each session, strict time limits, full recording, no standing credentials, and separation between the control plane and the data plane so that a support session cannot become a route to stored content. Each exception leaves a record that auditors can review, and repeated exceptions trigger a review of staffing or training rather than quiet acceptance.

Subprocessors extend the operational boundary further. A prime provider may rely on outside firms for hardware maintenance, security monitoring, payment handling, or specialist software, and each firm brings its own staff, tooling, and legal exposure. Sovereign contracts therefore require advance notice of subprocessor changes, flow down of residency and access conditions, and a right to object when a new subprocessor weakens the control stack. Recovery planning exposes the same dependencies, because how ransomware recovery works clarifies that clean backups, isolated credentials, and rehearsed restoration decide whether an operator can rebuild without emergency help from foreign vendor teams. Operations hold sovereignty only when patching, telemetry, support, and recovery each follow rules set locally, tested regularly, and enforced during the incidents that create pressure to abandon them.

Failure Modes: The Order That Arrives From Elsewhere

A sovereign cloud can pass every residency test and still fail at the moment that matters most. The data rests in a named region, under a named jurisdiction, behind controls that an auditor has inspected. Then a legal order arrives from another country, addressed not to the institution that owns the data but to the company that operates the platform, and the geography that looked decisive turns out to be only one layer of a larger stack. Sovereignty, understood as a stack of five controls covering location, legal exposure, operator access, key custody, and software and exit, holds only as far as its weakest control.

The litigation that exposed the fault line began with a warrant for email stored in Ireland. In 2013, investigators in the United States sought content from an account held by Microsoft, and Microsoft produced records held domestically but resisted disclosure of content stored on a server in Dublin. The company argued that a domestic warrant did not reach data held abroad, and that compulsion belonged to the jurisdiction where the data sat, through mutual legal assistance channels. In 2016, the United States Court of Appeals for the Second Circuit agreed, holding that the statute behind the warrant showed no clear intent to apply outside the country.

Congress answered by changing the statute. The Clarifying Lawful Overseas Use of Data Act, known as the CLOUD Act, became law in 2018. The Act provides that a provider subject to United States jurisdiction must disclose data within its possession, custody, or control, regardless of whether the data is stored inside or outside the United States. The Supreme Court, which had agreed to hear the Microsoft case, dismissed the dispute as moot in 2018 because the new statute governed the warrant at issue. The decisive fact stopped being the country holding the disk and became the country holding authority over the provider. A European subsidiary, a European data center, and European staff do not remove a parent company from the jurisdiction in which the parent is incorporated.

Compelled disclosure under such a statute operates through familiar legal instruments: a warrant, a subpoena, or a court order served on the provider, backed by sanctions for refusal and by a defined route for challenge. The CLOUD Act added a procedure for raising a conflict with the law of another qualifying government in certain cases, decided by a court weighing the interests of both states. Alongside compulsion sit gag provisions, orders that forbid the provider from notifying the customer whose data is sought for a defined period, granted where a court finds that notice could endanger an investigation or another protected interest. The customer may learn of a disclosure long after it occurred, or hold a contract promising prompt notice that a court order has lawfully overridden. Lawful process, working as designed, reaches the data through the operator and around the border.

For procurement, the lesson is a discipline of questions. Exposure attaches to every entity in the operating chain, including parents, subsidiaries with control over the platform, and support organizations able to reach the data. A residency guarantee answers where data rests. It does not answer whose courts can compel the operator, which secrecy orders can attach to that compulsion, or whether the customer would ever be told. By the logic of the weakest control, a stack with hardened location and exposed legal reach is a stack whose sovereignty ends at the foreign courtroom door.

Failure Modes: The Exit That Exists Only on Paper

What makes leaving a cloud provider genuinely possible?

Leaving becomes genuinely possible when data exports in open formats, restores into an independent environment, transfers keys and configurations, and completes within a tested time and budget, all proven through a rehearsed migration rather than promised in contract language alone before any dispute or deadline forces the move under pressure.

The second failure mode arrives without any court order at all. It arrives at renewal, at a price increase, or at the moment leadership decides that a platform no longer fits. The contract contains an exit clause promising return of data in a standard format within a stated period after termination. On paper, the institution is free. In practice, freedom depends on details that the clause rarely captures, and the distance between a contractual exit and a tested exit is where dependence hardens into permanence. Friction alone, applied across formats, fees, and forgotten dependencies, can hold a customer more reliably than any lock on a door.

Proprietary formats supply the first layer of friction. A database exported as a proprietary backup may restore only into the same vendor’s engine. An analytics service may export results while withholding the models, transformations, and lineage that produced them, leaving flat files where a working system once stood. Identity configurations, workflow rules, and automation scripts often live in vendor-specific structures that export tools omit entirely. The machinery that gives those records meaning travels badly, and an institution that recovers its files without its machinery has recovered an archive rather than an operation. The test is not whether data can leave, but whether a functioning service can be rebuilt elsewhere from what leaves.

Egress cost supplies the second layer, and it operates as simple arithmetic. Providers commonly charge for data moving out while charging nothing for data moving in, an asymmetry that stays trivial during ordinary use and grows decisive at departure scale. Years of accumulated records, images, backups, and logs can carry a transfer bill large enough to require its own budget approval, at the moment when a successor platform also demands payment. Contractual caps, waived egress fees for full departures, and pre-priced exit scenarios change that arithmetic at signing, when leverage exists.

Undocumented dependencies supply the third layer, and they are usually discovered in the worst order. A reporting tool reads a vendor-specific interface that no inventory recorded. A partner organization exchanges files through a managed service buried inside the platform. Backups, monitoring, key management, and single sign-on arrangements lean on the incumbent in ways that accumulated gradually, until the platform became load-bearing structure. Together such dependencies mean that exit requires rebuilding connections that nobody fully listed, on a timetable set by a contract clock that started at notice. A dependency register maintained during ordinary operation is the difference between a migration plan and an archaeology project.

A tested exit answers all three layers at once. A rehearsal that restores exported data into an independent environment, reconnects a sample of dependent services, and measures elapsed time and total cost produces evidence. A clause produces language. Institutions with real leverage treat exit the way engineers treat disaster recovery, as a capability proven by exercise, with named staff, a runbook, and a measured result that a board can inspect. Exit is the fifth control because every other control can be revoked by a provider that knows the customer cannot leave. A customer that can leave can enforce the rest.

A Worked Case: A School System Chooses Its Cloud

Consider a composite school system, assembled from features shared by many real institutions and belonging to none of them. The system serves fourteen thousand pupils across twenty-one schools in a single metropolitan area. Its records divide into three families. Pupil records hold enrollment, attendance, grades, health notes, and family contact details. Safeguarding data holds the most sensitive material of all, case notes concerning children at risk, referrals to outside agencies, and records whose disclosure could endanger a child rather than merely embarrass an institution. Examination material holds papers before administration, scripts after it, and results before release, a family whose value is time-bound and whose early disclosure destroys fairness for an entire cohort.

The procurement began with location. A regional data center offering satisfied the board’s first instinct, that records concerning local children should rest within the country. The five-control test slowed the decision and widened it. On legal exposure, the leading bidder was the domestic arm of a foreign parent, subject to the compelled disclosure law of its home jurisdiction. On operator access, the bidder routed support through staff in several countries, with privileged access to systems granted case by case. On key custody, the standard offer held encryption keys within the provider’s own key service, with a customer-held option as an extra. On software and exit, the proposal leaned on proprietary formats for its safeguarding casework module and priced egress by volume, with no rehearsed migration offered.

The evaluation did not treat the three families as one risk, and that separation produced the eventual decision. Pupil records, the board concluded, carried real but manageable sensitivity, and the deciding factors were cost, reliability, and access controls that staff would actually use. Safeguarding data sat in another category entirely. The harm from compelled foreign disclosure, or from broad operator access, fell not on the institution but on identifiable children, and the board judged that no contractual promise from a foreign-controlled operator could carry that weight regardless of where the servers stood. Examination material fell between the two, sensitive chiefly within a narrow window, and manageable through custody and access controls with strict timing.

The school system therefore split the estate instead of awarding it whole. Pupil records and ordinary administrative systems went to the large commercial bidder, under a contract that moved key custody to keys the system itself held, restricted support access to named domestic staff with logged and time-limited grants, capped egress charges, and required an annual export rehearsal as a condition of renewal. Safeguarding data went elsewhere, to a smaller domestic operator whose parent, support chain, and key arrangements all sat within the same jurisdiction as the schools, at a higher price per record that the board accepted openly as the cost of the control obtained. Examination material followed the safeguarding arrangement during assessment windows under the same custody rules.

The decision satisfied no purist, and the board minutes recorded the trade plainly. The system paid more than the single-bidder offer, accepted the burden of two supplier relationships, and took responsibility for integration work that a single platform would have absorbed. In exchange, each family rested behind a stack whose weakest control matched the harm that family could cause. The safeguarding stack was sovereign in the full five-control sense, at a price justified by the children in the files. The administrative stack was sovereign in location and custody, exposed in legal reach, and chosen with that exposure named and accepted rather than hidden behind a residency label.

The Complication: The Case That Residency Is Enough

The strongest opposing case deserves its best form, because a test that survives only weak opposition proves little. Hyperscaler sovereign offerings, and several European industry voices supporting them, argue that practical sovereignty does not require national operators or a full domestic stack. On this account, residency inside the customer’s jurisdiction, binding contractual commitments that constrain how a provider handles data and contests improper demands, and customer-held encryption keys together deliver the substance of sovereignty in a form that ordinary institutions can actually buy. A provider bound by contract, audited against published commitments, and unable to read data sealed under keys it does not hold offers a control that is real rather than ceremonial. The legal exposure of a foreign parent is acknowledged and then discounted, on the ground that a provider holding only ciphertext has little of value to surrender under compulsion.

The second half of the opposing case concerns quality, and it is the harder half to answer. Security at scale is a function of investment, talent, and repetition. A large operator patches vulnerabilities across a vast estate at a speed that a small national provider, maintaining bespoke infrastructure for a handful of public customers, struggles to match. Resilience engineering, hardware supply, and incident response all reward scale, and a full-stack national cloud that wins on operator nationality may lose on patch speed, on the depth of its security team, and on the maturity of its tooling. For many institutions, the realistic threat is criminal intrusion, ransomware, and operational failure rather than state compulsion. Against those threats, a sovereign label attached to a weaker platform could reduce actual safety while increasing formal control.

The honest response is to narrow the thesis rather than to abandon it. The five-control test was never a ranking of cloud quality. It measures one thing, legal reach, meaning the set of courts, operators, and key holders that can lawfully or practically arrive at the data against the customer’s wishes. It says nothing direct about patch speed, uptime, price, or usability, and a platform that scores at the top of the test can still be the worse platform on every one of those measures. Treating the test as a total verdict confuses a measurement with a judgment. Treating residency as a total answer commits the mirror error, answering a question about legal reach with evidence about geography and service quality, neither of which settles who can be compelled to produce the keys or the plaintext.

Narrowed in that way, the thesis leaves room for the residency offering to be the right choice, and often enough the right choice is exactly that. Where the threat model is commercial, where the feared events are breach, extortion, vendor failure, and competitive exposure rather than an order from a foreign court, residency plus contractual commitments plus customer-held keys addresses the threats that dominate the register. A hospital group or a retailer may rationally prefer that patch speed and security depth, and spend the saved money on nearer dangers. The five controls still earn their place in that decision, not as a gate that forbids the purchase but as the instrument that names the residual exposure precisely, so that acceptance is a recorded judgment rather than an unnoticed assumption. Sovereignty as a stack remains the correct account of legal reach. Whether legal reach is the risk that matters most is a question each institution must answer from its own threat model.

What Sovereignty Cannot Do

A sovereign cloud narrows the circle of parties that can reach data, compel its disclosure, or operate the systems that hold it. That narrowing has a hard boundary, and honest description of the boundary matters as much as description of the protection. Sovereignty is a stack of five controls covering location, legal exposure, operator access, key custody, and software and exit, and a service is sovereign only to the extent that the weakest of those controls holds.

The first limit is the home state itself. Moving data into a domestic facility, under domestic law and domestic operation, reduces exposure to foreign legal process, but it does not place the data beyond law altogether. The state that provides the shelter also retains courts, police powers, intelligence mandates, and regulatory authority of its own, and a provider operating inside that jurisdiction must answer lawful demands issued there. A ministry that stores records in a national cloud has traded one sovereign for another rather than escaping sovereignty as such, and in some cases domestic authorities hold broader or faster access powers than the foreign authorities the arrangement was built to exclude. Tenants with a genuine need to limit even domestic access must rely on separate instruments, such as encryption with keys held entirely outside the provider, split knowledge arrangements, or a decision not to store the material in connected systems at all. Sovereign hosting alone delivers none of those outcomes, and a buyer that confuses jurisdictional preference with immunity from its own government has misunderstood the product.

The second limit is internal security, which sovereignty does not repair. A cloud can satisfy every residency and staffing rule and still run weak identity controls, unpatched hypervisors, permissive network rules, and poor logging. Most breaches in practice trace to stolen credentials, misconfigured storage, unmonitored service accounts, and insiders with excessive privilege, and none of those failure modes cares about the nationality of the data center. An attacker who phishes an administrator password needs no court order in any country, and a tenant that leaves an object store open to the public internet has surrendered confidentiality more completely than legal process could manage. Sovereign controls govern who may legitimately reach a system and under whose law, while ordinary security engineering governs whether illegitimate access succeeds, and strength in one discipline does not substitute for weakness in the other.

The third limit is dependence that sits below and beside the cloud itself. A domestic operator still runs processors, accelerators, network switches, and firmware designed and often fabricated abroad, assembled into supply chains that cross many borders. The software stack leans on global open source projects, foreign controlled compilers and libraries, certificate authorities, and standards set by international bodies. Connectivity depends on carriers, undersea cables, and routing arrangements outside any single state, and power, cooling, and replacement parts arrive through markets that no hosting contract can nationalize. A fault, an export restriction, or a compromised update in that deeper layer can weaken a sovereign service without any change in data location, operator nationality, or key custody. Full self sufficiency in computing would require fabrication plants, design teams, and standards influence on a scale that only a handful of states possess, and even those states trade with one another. Sovereignty, measured honestly, describes a reduction in external leverage and a clearer line of legal accountability, not independence from the wider technical world.

How a Buyer Tests a Sovereignty Claim

Institutions that test a sovereignty claim before signing treat the claim as a set of verifiable propositions rather than as a label, and the table of five controls and their failure modes supplies the structure for that testing. Each control generates its own evidence, and a claim that survives for one control may fail for another.

The contract review comes first, because so many sovereignty questions reduce to legal exposure. Institutions ask which law governs the agreement, which courts hear disputes, and whether the provider, its parent, and every subcontractor in the chain can receive legal process in a foreign jurisdiction for data they hold or can reach. They press on notification: whether the provider must inform the tenant of a disclosure demand unless a court forbids it, whether the provider commits to challenging demands that conflict with the law of the hosting jurisdiction, and how much time the tenant receives to seek a remedy. They examine audit rights, breach notification periods, personnel screening standards, and the list of subprocessors, together with a right to object when that list changes. If you read only one part of a sovereignty proposal closely, the subprocessor and parent company clauses repay that attention, because hidden depth in the corporate and supply chain is where jurisdictional promises most often leak.

The key custody test is practical rather than documentary. Institutions generate keys outside the provider environment where the design permits it, hold those keys in hardware under their own control, and then test whether the provider can decrypt a sample workload without tenant participation. A sound design produces a clear negative result: provider staff, following their own tooling, cannot reach the plaintext. Institutions also rehearse rotation and revocation, confirming that a revoked key renders protected data unreadable to the service, that backup copies behave the same way, and that key loss on the tenant side has a defined recovery path rather than an informal workaround through provider support. Where keys live inside provider hardware, institutions ask who administers that hardware, which firmware it runs, and what attestation evidence the tenant can inspect independently.

The operator access test follows the same pattern, treating access as an event that must leave evidence. Institutions request the complete access model in writing: which roles can reach tenant data, from which locations, under which approvals, and with what session recording. They then stage a support incident and observe the model in operation, watching whether access requires tenant approval, whether it expires automatically, and whether the resulting log reaches the tenant in a form the tenant can retain. A break glass procedure receives particular scrutiny, since emergency paths bypass normal controls by design and therefore need stronger logging and after the fact review.

The exit rehearsal closes the examination, because software and exit control determines whether the other four controls remain choices or harden into captivity. Institutions export a representative workload with its data, configurations, identity settings, and keys, rebuild that workload in a second environment, and measure the time, cost, and manual effort the move required. They test data formats for proprietary extensions, confirm that egress charges match the contract, and verify deletion from the original environment once the move completes, including backup media schedules. Institutions that complete all four examinations hold evidence, control by control, of where a service stands, and a record against which later drift in ownership, staffing, subprocessors, or terms can be detected and challenged.

The Longer Contest Over Digital Sovereignty

Concern about foreign access to data stored by cloud providers acquired political force after the disclosures made by Edward Snowden in 2013. Documents published from that year described large scale collection programs operated by the United States National Security Agency, and governments in Europe and elsewhere confronted evidence that data entrusted to foreign controlled providers could be reached by a foreign state on a scale that contracts had not conveyed.

Litigation in the United States then exposed a second question, namely whether legal process stops at a border when the provider does not. In the Microsoft Ireland case, federal prosecutors served a warrant in 2013 seeking email stored on a server in Ireland, and Microsoft challenged the demand on the ground that a domestic warrant did not reach data held abroad. In 2016 an appeals court ruled for Microsoft, holding that the statute behind the warrant carried no clear statement of application outside the United States. The dispute reached the Supreme Court, but Congress intervened before a final judgment on the original question, and the case was dismissed as moot once new legislation governed the matter.

Congress answered the question directly in the CLOUD Act of 2018, a statute whose full name is the Clarifying Lawful Overseas Use of Data Act. The Act requires a provider subject to United States jurisdiction to disclose data within its possession, custody, or control regardless of where that data sits, while also creating a mechanism through which a provider can challenge a demand that conflicts with the law of a qualifying foreign government.

European law moved on a parallel track through the Schrems II judgment of 2020, delivered by the Court of Justice of the European Union in a case brought by the Austrian privacy campaigner Maximilian Schrems. The court invalidated the Privacy Shield arrangement that had supported transfers of personal data to the United States, finding that United States surveillance law did not limit collection to what was strictly necessary and that European individuals lacked effective redress against that collection. The judgment left standard contractual clauses in place but made their use depend on an assessment of the law in the destination country, which pushed transfer risk from a paperwork exercise into a substantive legal analysis for thousands of organizations. In the same year, 2020, France and Germany led the founding of Gaia-X, an initiative to build a federated European data infrastructure with common rules on identity, catalogs, and compliance rather than a single state run cloud. National programs reinforced the same direction: France developed its SecNumCloud qualification and a doctrine favoring cloud services insulated from non European law for sensitive state and industry data, while Germany pursued federal cloud infrastructure and supported the Sovereign Cloud Stack, an open source platform intended to let European operators run compatible services without dependence on a foreign hyperscaler stack.

Taken together, these events explain why sovereignty became a durable category rather than a passing reaction. A disclosure, a court case, a statute, a judgment, and a set of industrial programs each tightened the same knot from a different side, and each left institutions with obligations that a purely commercial cloud market had not imposed on itself. The contest continues through adequacy decisions, executive agreements, qualification schemes, and procurement rules, and its direction is consistent even where its instruments differ: states assert that control over data infrastructure is an attribute of governing power, and providers design services in response to that assertion.

Where Control Finally Rests

Control over cloud data rests wherever the five controls leave it, and that resting place is rarely the single point a sovereignty label suggests. Location decides which territory physically holds the machines, legal exposure decides which states can compel the parties involved, operator access decides whose hands can reach the system in ordinary work and in emergencies, key custody decides whether compelled or permitted access yields readable material, and software and exit decide whether a dissatisfied tenant can leave without losing the value stored in the service. A weakness in any one of these redirects control toward the party positioned to exploit that weakness, whether a foreign court, a parent company, an engineering team, a key administrator, or a platform whose proprietary formats raise the price of departure beyond what a tenant can pay.

That structure has consequences for how sovereignty claims deserve to be read. A claim framed around one control, most often location, invites attention toward the strongest element of a service and away from the weakest, and governments have learned to interrogate the remaining elements through qualification schemes, transfer assessments, and procurement conditions. Sovereignty in the market therefore behaves less like a property a service either has or lacks and more like a negotiated distribution of powers among tenant, provider, and states, recorded in contracts, architectures, and logs, and revised whenever ownership, law, or technology shifts beneath it.

For states, the implication is that purchasing a sovereign service does not discharge the underlying policy problem. A government that wants durable control over its digital infrastructure still faces questions about domestic technical capacity, the depth of its supplier base, the skills of its auditors and engineers, and the credibility of its own access laws in the eyes of citizens and partner states. States that invest only in the label acquire the appearance of control for the length of a contract, while states that invest in capacity acquire the ability to test claims, to switch providers, and to write rules that providers must meet in order to sell at all.

For institutions, the corresponding implication is discipline rather than geography. The strongest sovereignty position available to most buyers comes from holding keys independently, limiting operator access to approved and logged events, keeping workloads portable enough to move, and reading contracts for the foreign legal exposure of every party in the chain. Institutions that build those habits treat sovereignty as an operating condition to be maintained and retested, through key ceremonies, access reviews, and exit rehearsals repeated across the life of a service, rather than as an attribute settled permanently at signature.

The structural implication reaches beyond any single contract. As more states encode sovereignty requirements into law and procurement, control over cloud infrastructure becomes a standing feature of relations between states and the companies that operate across their borders, shaping where facilities are built, how subsidiaries are structured, which personnel may hold privileged roles, and what evidence of compliance a provider must produce to compete. Power in that arrangement belongs neither wholly to governments nor wholly to platforms. It belongs, in practice, to whichever party holds the weakest control in a given stack and understands that it holds it, because that control determines what every other promise in the arrangement is finally worth.

Readers keeping notes on the five controls may use a companion reference tool and a second reference point alongside those notes.

Frequently Asked Questions

Q: What is a sovereign cloud in simple terms?

A sovereign cloud is a cloud environment built so that data, systems, and day-to-day operations remain under the law of a defined jurisdiction. Storage sits in data centers inside that territory, support and administration are performed by personnel bound by local rules, and contracts restrict transfer or access from elsewhere. The model addresses a gap in standard cloud services, where data may rest in one country while the provider answers to courts and regulators in another. By aligning location, staffing, encryption, and governance, a sovereign cloud gives public bodies and regulated industries a way to use shared computing capacity without surrendering legal control over records, workloads, and the decisions that govern access to them. Procurement documents for such a service specify the territory, the operator, the key holder, and the audit rights that make the arrangement enforceable rather than descriptive.

Q: How is a sovereign cloud different from ordinary data residency?

Ordinary data residency controls only where data is stored at rest. A sovereign cloud controls a wider set of questions, including where data is processed, who can administer the systems holding it, which courts can order its disclosure, and where copies, logs, and backups travel. A provider can promise residency in a European data center while support staff in a third country retain administrative access, leaving foreign law able to reach the data through the provider. Sovereignty removes or tightly restricts that path by limiting personnel, control systems, and legal exposure to the chosen jurisdiction, and by requiring evidence for each claim rather than a storage location alone. The distinction matters during procurement, because residency is a property of storage, while sovereignty is a property of the whole service, its operator, and its legal position.

Q: Why does the CLOUD Act matter to clouds outside the United States?

The CLOUD Act of 2018 clarified that a provider subject to United States jurisdiction must produce data within its possession, custody, or control after a lawful demand, regardless of where that data is stored. Location alone therefore offers incomplete protection when the provider, its parent company, or a key subsidiary answers to United States courts. A database held in Frankfurt or Paris can still fall within reach if a United States provider controls the service. Sovereign designs respond by separating legal control, operations, and key custody from the foreign parent, or by placing the service with a provider outside that chain of jurisdiction. The statute also created a process for challenging a demand where compliance would conflict with the law of a foreign government with a qualifying agreement.

Q: What did the Schrems II judgment change for data transfers?

In Schrems II in 2020, the Court of Justice of the European Union invalidated the Privacy Shield framework for transfers between the European Union and the United States. The court found that United States surveillance law did not give European data subjects protections essentially equivalent to those under the GDPR, Regulation 2016/679. Standard contractual clauses survived, but only where an exporter assessed the destination law in practice and added supplementary measures where needed. The judgment pushed organizations toward technical controls such as strong encryption with keys held in Europe, because a contract alone could not prevent access by a foreign intelligence service. Later transfer tools and adequacy arrangements did not remove that assessment duty for transfers outside approved destinations, and regulators gained grounds to suspend flows that lacked effective safeguards.

Q: Who holds the encryption keys in a sovereign cloud?

Key custody varies by design, and the allocation decides how much protection encryption actually provides. In weaker models, the provider generates, stores, and uses the keys, so a legal order served on the provider can reach both ciphertext and keys together. In stronger models, the customer or an independent trustee inside the jurisdiction holds the keys in hardware security modules and releases them only under defined conditions. That separation means a provider holding the encrypted data cannot read it on demand. Contracts, audit logs, and technical architecture should each state plainly which party can create, rotate, revoke, and use every key. Where a trustee holds the keys, release conditions, dual control, and logging of every use become central evidence in audits of the sovereignty claim.

Q: What is the difference between bring your own key and hold your own key?

Bring your own key allows a customer to generate a key and import it into a key service operated by the provider. The arrangement improves oversight and supports revocation, but the provider still stores and uses the key inside its own systems. Hold your own key, abbreviated HYOK, keeps the master key outside the provider environment, typically in hardware security modules under customer or trustee control inside the jurisdiction. Each use requires a call to that external service, so the provider never holds a copy. HYOK gives stronger sovereignty and harder revocation, at the price of added latency, complexity, and dependence on the external key service remaining available. The naming follows industry usage from providers such as Google Cloud and Microsoft Azure, where the two options sit at different points on a shared responsibility model.

Q: Can a government compel a cloud provider to hand over data stored abroad?

In many legal systems, a government can compel a provider within its jurisdiction to produce data the provider controls, even when the storage sits in another country. The CLOUD Act of 2018 states that rule expressly for providers subject to United States jurisdiction, subject to challenge where disclosure would violate the law of a qualifying foreign government. Other states assert similar powers through court orders, national security laws, and mutual legal assistance treaties. Sovereign architecture tries to narrow what any single government can obtain by splitting control among entities, jurisdictions, and key holders, raising the legal and technical cost of any one demand. Practical outcomes depend on where assets, executives, and infrastructure sit, because enforcement follows persons and property as much as it follows stored records.

Q: What is a control plane and why does it matter for sovereignty?

A control plane is the management layer that provisions resources, sets permissions, routes traffic, collects logs, and applies configuration across a cloud. The data plane, by contrast, carries the actual workloads and stored content. Sovereignty fails quietly when data stays local but the control plane runs abroad, because administrators and systems outside the jurisdiction can still issue commands, view metadata, and alter access rules. A sovereign design keeps the control plane inside the boundary, or isolates it under local operation, and treats its logs and telemetry as regulated material. Auditors therefore examine the control plane before accepting claims based on data center location. Procurement reviews therefore ask for diagrams and access records covering the control plane, not only certificates listing the addresses of the data centers.

Q: Why do sovereign clouds favour open source software?

Sovereign clouds favor open source software because inspectable code reduces dependence on a single foreign vendor and allows independent review for hidden access paths, telemetry calls, and update channels. Licenses that permit local modification also allow an operator to build, patch, and run a service without permission from an overseas supplier, and to keep running if a supplier withdraws support. Open source does not guarantee security, since a poorly maintained project can carry serious flaws. It changes who can verify and repair the software. That verifiability, combined with local skills and portable workloads, explains its central place in many European sovereignty programs. Community projects such as Kubernetes and OpenStack also supply building blocks that a local operator can assemble without building every layer from scratch.

Q: What is SecNumCloud and what does it require?

SecNumCloud is a French qualification for cloud services, issued by the national cybersecurity agency ANSSI, with version 3.2 setting demanding requirements. A qualified provider must protect data against non-European law, keep operations and support within the European Union, meet strict organizational and technical controls, and show that shareholders and governance cannot expose the service to foreign compulsion. The scheme covers infrastructure, platform, and software services used by French public bodies and operators of vital importance. Qualification involves audits, documentation, and continuing surveillance rather than a single assessment. Because the bar is high, few services hold the qualification, and it functions as a demanding reference point across Europe. The qualification also demands incident handling, personnel vetting, and separation from suppliers subject to extraterritorial access laws, tested through documentary review and on-site inspection.

Q: What is Gaia-X trying to build?

Gaia-X, founded in 2020 by French and German backers and later broadened across Europe, works to build a federated model for data infrastructure rather than a single rival cloud. Participants describe services, data sets, and providers through common labels covering identity, compliance, portability, and sovereignty, so a customer can compare offerings and move between them. The initiative produces specifications, trust frameworks, and clearing house functions for checking claims. Critics note slow delivery and complex governance, and Gaia-X operates no data centers of its own. Its influence lies in defining shared rules by which independent providers can present interoperable and verifiable services. Membership grew to include hundreds of associations, companies, and research bodies, although converting that breadth into widely used commercial services remains an unfinished task.

Q: How do hyperscalers structure their sovereign cloud offerings?

Large providers generally separate sovereignty into distinct regions, subsidiaries, partnerships, or partner-operated services. Amazon Web Services announced the AWS European Sovereign Cloud in 2023, designed as a physically and logically separate region in Europe with European resident operations and leadership. In France, S3NS, built by Thales with Google technology, and Bleu, built by Capgemini and Orange with Microsoft technology, place operation in French companies aiming at SecNumCloud qualification. Microsoft and Oracle offer European data boundaries and dedicated government regions with restricted support. Each model balances the parent technology against local legal control, and buyers must test how complete that separation proves in practice. Buyers should compare the share of the service actually inside the sovereign boundary, because a flagship region can coexist with global support and management systems.

Q: What is confidential computing and what does it protect?

Confidential computing protects data while it is in use, closing a gap left by encryption at rest and in transit. Hardware-based trusted execution environments isolate a workload inside an enclave or a confidential virtual machine, encrypt memory against the host operator, and support remote attestation so a customer can verify the code and configuration before releasing keys. The Confidential Computing Consortium, founded in 2019, promotes shared definitions and open projects in the field. The technology limits what a cloud administrator, hypervisor, or compromised host can observe. It does not remove legal duties, application flaws, or risks at the endpoints where data enters and leaves. Shared standards and processor designs from Intel, AMD, and Arm give buyers a common vocabulary for comparing otherwise different hardware implementations across providers.

Q: Does a sovereign cloud cost more than a standard cloud?

A sovereign cloud generally carries higher prices than a comparable standard service. Separate infrastructure, smaller scale, local staffing with security clearances, duplicated control planes, and repeated audits all raise unit costs, and providers pass those costs to customers through premiums or dedicated fees. Published comparisons vary widely by workload, region, and commitment length, so a single percentage rarely holds. An organization also pays in narrower service catalogs, slower access to new features, and added engineering for external key management. The comparison therefore belongs against the cost of regulatory penalties, forced migration, or lost eligibility for public contracts, rather than against headline compute prices alone. A rigorous comparison separates the premium for sovereignty itself from ordinary differences in discounts, reserved capacity, egress charges, and support tiers between the two offers.

Q: What happens to sovereignty when a provider sends telemetry abroad?

Telemetry can undermine sovereignty even when customer content never leaves the territory. Diagnostic data, usage logs, IP addresses, account identifiers, performance traces, and error reports may qualify as personal data under the GDPR, Regulation 2016/679, and their transfer abroad can expose operations to foreign law and reveal sensitive patterns about a workload. A sovereign service should enumerate every telemetry flow, state its destination and retention, minimize the fields collected, and keep processing inside the boundary where a claim depends on it. Buyers should test packet flows and support tooling during evaluation, because undocumented diagnostic channels have repeatedly surfaced after contracts were signed. Contracts should grant audit rights over sub-processors handling telemetry, since a single support platform abroad can move logs outside the promised boundary.

Q: How can an organisation verify a sovereignty claim before signing?

An organization can verify a claim by demanding evidence at four levels. Legal review should map the provider, parents, subsidiaries, and support entities against the laws that can compel each one. Technical review should inspect data flows, control plane location, key custody, telemetry destinations, and administrator access paths. Independent assurance such as SecNumCloud qualification in France or a BSI C5 report in Germany gives audited material to test, although scope and date decide its value. Contract terms should then convert verified facts into duties covering disclosure challenges, subcontractor changes, audit access, and exit. A claim that survives only in sales material deserves no reliance. Evidence should be dated, scoped to the exact service under contract, and refreshed after mergers, new sub-processors, or changes in support location.

Q: What is data localisation and how does it differ from sovereignty?

Data localization is a legal rule requiring specified data to be stored, and sometimes processed, within a named territory. Sovereignty is a broader outcome covering location plus legal reach, operational control, personnel, key custody, supply chains, and the ability to resist or challenge foreign demands. A localization law can be satisfied by a data center operated by a foreign provider whose home courts can still order disclosure, which leaves sovereignty incomplete. Conversely, a sovereign arrangement may permit encrypted backups abroad where local key holders prevent access. Localization is therefore one instrument among several, useful for enforcement and latency, but insufficient as a measure of control. Policy debates often blur the terms, and precise drafting matters because compliance with one concept does not establish compliance with the other.

Q: Which countries require government data to stay on sovereign infrastructure?

Requirements differ in form and strictness. France directs public bodies toward SecNumCloud qualified services for sensitive data under its cloud doctrine, and Germany favors certified sovereign arrangements assessed against BSI C5 for federal workloads. India, Saudi Arabia, and Indonesia impose localization or in-country hosting duties for defined categories of public and regulated data. China requires critical information infrastructure operators to store personal information and important data collected in China inside the country. Australia restricts hosting of certain government data to certified providers and facilities. Few states mandate a fully sovereign cloud for every workload, but sector rules steadily expand the categories covered. Enforcement ranges from procurement preference to firm statutory duty, so the exact obligation depends on the data class, the sector, and the agency involved.

Q: What are the limits of a sovereign cloud against a determined state?

A sovereign cloud raises cost and visibility, but no architecture places data beyond every state power. The host state itself retains police, court, and intelligence authority, and can legislate new access duties. A foreign state can pursue endpoints, insiders, supply chains, vulnerabilities, and parent companies in other markets, and can apply economic pressure that law alone cannot answer. Encryption with locally held keys and confidential computing narrow exposure, yet metadata, traffic volume, and access patterns often remain visible. Honest assessment treats sovereignty as risk reduction and legal clarity, shifting which government can act and under what process, rather than as immunity from state action. Design choices still matter within those limits, because they decide whether access requires a public legal process or can proceed quietly through a single supplier.

Q: How does a sovereign cloud handle backups and disaster recovery?

A sovereign cloud keeps backups, replicas, and recovery operations inside the same legal and operational boundary as the primary service, or inside an approved jurisdiction with equivalent protections. Replication to a cheaper foreign region would defeat the model, so providers build multiple sites within the territory and encrypt backups under keys held by the customer or a local trustee. Recovery plans must also cover personnel, control plane access, and support during a failure, since emergency help from abroad can break the claim at the moment of greatest dependence. Testing should prove restoration succeeds without exporting data, keys, or logs beyond the boundary. Retention periods, deletion duties, and restoration targets belong in the same review, since a backup retained abroad after deletion would breach the promised boundary.