Sovereign Cloud Checklist: Hardware, Software, Legal Reach, Keys and Administrator Access

Most sovereign cloud pitches prove one thing: data residency, meaning the data stays in the country. This sovereign cloud checklist covers five more questions to put to the provider, with the document to request for each question:

A verbal assurance from sales doesn't count as evidence.

We've seen government-linked customers elsewhere in the market fail required government checks on their cloud setup. The five written answers show the weak points before a government review.

These five questions cover control of the system itself. A later section covers exit terms and the supply chain.

Data Residency, Data Sovereignty and Sovereign Cloud

These three terms describe different things:

1. Data residency: the country of storage.
2. Data sovereignty: the law that governs the data.
3. Sovereign cloud: who controls the hardware, software and staff underneath the data.

The sovereignty gap is the distance between legal control of the data and control of the hardware and software beneath it. Cisco describes a sovereign cloud as one where each layer of the stack, from physical hardware to data processing, stays under one jurisdiction's control.

Sovereign cloud is one part of digital sovereignty, the wider question of who controls an organization's digital infrastructure. IBM divides digital sovereignty into operational, technology, data and AI sovereignty. This checklist tests operational sovereignty through the administrator-access question and technology sovereignty through the hardware and software questions.

Weak Points in Each Type of Sovereign Cloud

Cisco groups sovereign cloud into three deployment models, and each model carries a different weak point:

1. National cloud infrastructure: local infrastructure run by domestic providers. The equipment can still belong to a foreign lessor or lender (question 1).
2. Sovereign regions of a global provider: separate regions inside a global provider's network. A US parent company stays within reach of US court orders (question 3).
3. Hybrid sovereign models: public cloud combined with private or government-run infrastructure. The public cloud side faces the same five questions.

Who Owns the Sovereign Cloud Hardware?

Leased or financed equipment can belong to a company in another country.

Check the ownership documents for three points:

1. The owner, its parent company and their countries of incorporation.
2. The lessor's or lender's rights to repossess or reassign the equipment.
3. Coverage of network and storage equipment as well as GPU servers.

Location statements don't name the owner.

Technology Sovereignty: Who Runs the Management Software?

The management software sets up, monitors and updates the system, so the company running it controls the environment. Ask which company runs it and from which country. An air-gapped deployment stays physically isolated from the public internet, which blocks remote management through that route.

Oracle describes its EU Sovereign Cloud as infrastructure separate from its commercial EU regions, with its backbone network disconnected from Oracle's other regions. Ask for a statement this specific, in writing.

Get a written operations statement that names:

1. The company that runs the provisioning, monitoring and update tools, and the country of its staff and servers.
2. The source of firmware and hypervisor updates, and the company with approval rights over those updates.
3. Remote support tools with access from another country.

Which Courts Can Order a Handover Under the CLOUD Act?

The **US CLOUD Act** lets US courts order a provider under US jurisdiction to hand over data in its possession, custody or control, including data stored in the EU. A US-incorporated provider can receive that order for a workload in an EU data center.

Map the provider's corporate chain:

1. Each company in the chain: the contracting company, its parent and subcontractors with access to the data.
2. The country of incorporation of each company, and the courts with power over each one.
3. A contract clause that commits the provider to tell you about foreign orders and to challenge them within the law.

General promises about local law don't answer this question.

Who Holds the Encryption Keys?

Customer-held keys stop the provider from producing readable copies of encrypted data, as long as the provider cannot reach the keys. The CLOUD Act can still reach data outside that encryption, such as metadata, logs and billing records.

The terms should answer three questions:

1. The location of the key store or hardware security module.
2. A provider copy, escrow arrangement or recovery path for the keys.
3. The data the provider can still produce under a court order, such as logs, backups and support tickets.

Operational Sovereignty: Whose Staff Have Administrator Access?

Ask which countries' citizens or residents hold administrator rights, including the emergency ("break-glass") credentials. Emergency credentials held abroad keep the system dependent on another country.

Ask the provider for a dated plan that moves these rights to a named local company. Zettabyte's BOTT delivery model follows four stages:

1. Build: construct the infrastructure.
2. Operate: run and stabilize the system.
3. Train: train local staff in operations.
4. Transfer: hand control to the local company, with knowledge transfer, documentation and support onboarding.

Check two more points in the transfer plan:

1. The citizenship and country of residence of each administrator account holder.
2. The storage location of break-glass credentials, and the person who reviews their use.

Exit and Supply-Chain Checks for a Sovereign Cloud Contract

Two more checks cover what happens when the contract ends or a supplier is based abroad:

1. Exit terms: how the data, keys and configurations come back to you at the end of the contract.
2. Supply chain: which outside companies can reach the system through the provider.

Exit clauses should cover three points:

1. The export formats for data and configurations, and the notice period for an exit.
2. The location of the data during export, so data residency holds during the move.
3. Your right to take over the hardware or the operations, and the cost of that handover.

Open standards make an exit easier, because another operator can run the same tools.

Ask for the provider's list of subcontractors and key suppliers. That list needs three details:

1. The country of each support desk, monitoring service and firmware supplier with access to the system.
2. The storage and processing location of logs, telemetry and support tickets.
3. The provider's duty to tell you before it adds or replaces a supplier with access.

Suppliers abroad can still reach the system after the operator moves to local staff.

EU Penalties for an Unverified Sovereign Cloud Claim

Three EU laws carry penalties tied to these questions:

1. GDPR: Article 83 sets a fine ceiling at the greater of €20 million or 4% of global annual turnover. That top tier covers unlawful transfers of personal data outside the EU.
2. NIS2: the directive requires covered companies to manage supply-chain security, including their service providers. The European Commission took Ireland, Spain, France and the Netherlands to the Court of Justice of the EU on 8 July 2026. The four countries had missed the October 2024 deadline to write the directive into national law.
3. DORA: the regulation has applied since 17 January 2025 and covers EU financial firms' ICT third-party risk, including their cloud providers.

What the Answers Mean for a Sovereign Cloud Decision

Five documents back up a sovereign claim, one for each question. A missing document shows where the provider still depends on another country. The next step applies these questions to named sovereign cloud providers.

Zettabyte uses BOTT in its sovereign AI data center service to move administrator control to local staff.