Keeping data in a chosen country does not, on its own, keep it under that country's law: storage location, operator nationality, key custody and identity metadata each decide who can compel access. Data residency, data localisation and data sovereignty are often treated as synonyms in procurement, and EU data sovereignty debates blur them further, yet each is met by different controls. This guide separates the three, maps the legal drivers (localisation laws, the US CLOUD Act, Schrems II and the EU Data Act), compares sovereign cloud models and the certifications behind them, and explains where encryption key custody and identity data decide the outcome. It is written for security architects, cloud and identity teams, and privacy and procurement leads who must turn a sovereignty requirement into something they can evidence. For the country-by-country transfer and localisation rules see the Global Privacy Regulatory Map.
Key takeaways
- Residency is about location, sovereignty is about control. A residency commitment says where data sits; sovereignty asks which jurisdictions can compel the operator, who holds the keys and who can administer the service.
- The CLOUD Act follows the provider, not the data centre. 18 U.S.C. 2713 applies to data in a provider's "possession, custody, or control, regardless of whether" it is "located within or outside of the United States".
- Metadata, logs and identity data leak first. Support cases, telemetry, MFA logs and directory replicas often sit outside the residency boundary even when customer content does not.
- Hold your own key is the strongest technical lever, with real cost. Keys held outside the provider stop provider-side decryption, but they also break search, eDiscovery, AI features and malware scanning on that data.
- Match the model to the data class. Most data needs residency plus contracts; only a small, classified subset justifies a separately operated sovereign cloud or HYOK.
Residency, localisation and sovereignty: what each term means
Requirements fail when a buyer asks for "sovereignty" and accepts a "residency" answer. Decide which you need before evaluating any service.
| Term | Question it answers | Typical driver | What evidences it |
|---|---|---|---|
| Data residency | Where is data stored and processed at rest? | Customer contracts, sector guidance, latency | Region selection, provider residency commitments, data location reports |
| Data localisation (data localization) | Is a copy, or all, of the data legally required to stay in-country? | Localisation laws such as PIPL Art. 40 or the RBI payment data rule | In-country primary store, controlled export process, regulator filings |
| Data sovereignty | Which jurisdictions' laws apply, and can a foreign authority compel access? | Foreign access laws, national security, public sector policy | Operator legal structure, staff location, key custody, contract governing law |
| Digital sovereignty | Can the organisation (or state) keep operating and choose suppliers without foreign dependency? | Industrial policy, resilience, lock-in | Exit plans, portability, open standards |
| Identity sovereignty | Who controls the identity plane: directories, keys, tokens, admin roles and their logs? | Sovereign cloud identity governance, CIAM residency | Tenant location, local identity provider, admin and support access controls |
The NCSC cloud security principles frame the test well: know "where your data is, and who can access your data", including the countries where data is stored, processed and managed and "the legal circumstances under which your data could be accessed without your consent". Jurisdiction depends on the provider's legal base, where the service is operated from, who owns the data centre and the contract's governing law.
Legal drivers: localisation laws and foreign access
Two families of law create data sovereignty risk: data localisation laws pull data in, foreign access laws reach out to it. A multinational usually faces both.
| Instrument | Type | What it requires or allows | Practical effect |
|---|---|---|---|
| US CLOUD Act (enacted March 2018), 18 U.S.C. 2713 | Foreign access | US providers must preserve or disclose data in their possession, custody or control wherever it is stored; authorises bilateral executive agreements (UK agreement signed 3 October 2019, Australia 15 December 2021) | An EU region of a US-headquartered provider does not by itself remove US legal reach |
| Schrems II, CJEU C-311/18 (16 July 2020) | Transfer rules | Invalidated the EU-US Privacy Shield; standard contractual clauses stayed valid but need a case-by-case assessment and, where necessary, supplementary measures | Transfer impact assessments became routine; encryption with exporter-held keys became the main technical supplement |
| EU-US Data Privacy Framework (Commission decision 2023/1795, 10 July 2023) | Adequacy | Adequacy for certified US companies, based on US safeguards limiting signals intelligence to what is "necessary and proportionate" with an independent redress mechanism | The Commission states the US safeguards apply "regardless of the transfer mechanisms used", which also supports SCC assessments |
| GDPR Art. 48 | Blocking provision | A third-country court or authority order to disclose personal data is enforceable only if based on an international agreement such as a mutual legal assistance treaty | Creates a conflict of laws for providers subject to both regimes |
| EU Data Act (Regulation (EU) 2023/2854, applicable from 12 September 2025) | Foreign access and switching | Cloud providers must take measures against unlawful third-country governmental access to non-personal data (Art. 32); switching charges are abolished three years after entry into force | Extends sovereignty concerns beyond personal data and makes exit more realistic |
| China PIPL Arts. 40 and 41 | Localisation and blocking | Critical information infrastructure operators and handlers above set volumes must store personal information domestically and pass a security assessment to export it; no provision to foreign courts or police without PRC approval | Separate in-country stack and identity domain for Chinese operations |
| Reserve Bank of India circular of 6 April 2018 | Sectoral localisation | "The entire payment data shall be stored in systems located only in India"; data processed abroad must return within one business day or 24 hours | Payment platforms need in-country primary storage and deletion of foreign copies |
A contractual data residency requirement is usually easier to meet than a statutory localisation rule, because contracts can accept encrypted replicas or approved sub-processors. Read the wording: "stored in" is not "processed in", and neither covers remote administration. For GDPR transfer mechanics see the GDPR Compliance Guide for Security Teams.
Sovereign cloud models compared
"Sovereign cloud" covers very different products. Classify each option by who operates it, under which law, and what leaves the boundary.
| Model | Example | What it addresses | Residual sovereignty risk |
|---|---|---|---|
| Hyperscaler region with residency commitments | Microsoft EU Data Boundary for Azure, Microsoft 365, Dynamics 365 and Power Platform | Customer data, pseudonymised personal data in system logs and (since February 2025) technical support data stored and processed in the EU and EFTA | Same corporate parent; Microsoft states "limited circumstances" where data still leaves, including global security response |
| Separately operated sovereign cloud from a global provider | AWS European Sovereign Cloud, generally available January 2026, first Region in Brandenburg, Germany | Physically and logically separate from other AWS Regions, operated exclusively by EU residents, metadata including IAM roles, permissions, billing and usage metering kept in the EU, run by EU-based legal entities | Ultimate parent remains outside the EU; assurance rests on the provider's sovereignty framework and its independent validation |
| Partner-operated or locally owned trusted cloud | Offers qualified under ANSSI SecNumCloud | Technical, operational and legal requirements designed to resist extraterritorial laws | Smaller catalogue, slower features, higher cost |
| Private or national infrastructure | On-premises or government cloud | Full control of location, operators and keys | You own resilience, patching and scale; harder to use modern managed and AI services |
| Overlay controls on any cloud | Hold your own key, confidential computing, client-side encryption | Prevents provider-side decryption of selected data | Breaks provider features; key service availability becomes your problem |
Choosing between them
- Residency only (contract or customer preference): a standard region plus a residency commitment, sub-processor list and data location reporting is usually enough.
- Foreign access concern for personal data: residency, a documented transfer impact assessment and customer-held keys for the most sensitive datasets.
- Public sector, defence or critical national data: a separately operated sovereign cloud or a qualified trusted cloud, with local identity and admin control.
- Small organisations: rarely justify a sovereign stack; use a provider residency programme, encrypt the few crown-jewel datasets client-side and record the decision.
- Large or multinational organisations: use selective data residency: place each data class in the cheapest model that satisfies it. For cross border data residency, run one regional instance per jurisdiction with its own keys and logs rather than one global store with exceptions.
Sovereign cloud compliance: SecNumCloud, C5, EUCS and Gaia-X
Certifications show what was assessed, not that a service fits your requirement; read each report's scope.
| Scheme | Owner | What it is | Sovereignty relevance |
|---|---|---|---|
| SecNumCloud | ANSSI (France) | A qualification for IaaS, PaaS and SaaS covering technical, operational and legal requirements; qualified offers receive an ANSSI security visa | Explicitly targets protection against cybercrime and "l'application de lois extraterritoriales"; ANSSI notes qualification does not secure the customer's own workloads |
| BSI C5 (Cloud Computing Compliance Criteria Catalogue) | BSI (Germany) | "minimum requirements for secure cloud computing", attested by an independent auditor's report; C5:2020 is being succeeded by C5:2026 after a full 2025/26 revision | Transparency disclosures on data location and jurisdiction support a customer risk assessment; BSI does not select auditors or check reports, so read the report yourself each year |
| EUCS (EU Cloud Certification Scheme) | ENISA candidate scheme under the EU Cybersecurity Act | A proposed EU-wide cloud certification with assurance levels | Drafts that would have required EU headquarters for the highest level were removed in 2024 amid disagreement between member states; confirm current status before relying on it |
| Gaia-X | Gaia-X European Association for Data and Cloud AISBL | A federation and trust framework (sometimes written Gaia X) with machine-readable labels (Standard Compliance and Label Levels 1 to 3); "Our outcome will not be a cloud" | Useful for data spaces and verifiable claims about providers; not a substitute for a security certification |
Encryption and key custody: BYOK, HYOK and double key
Where the provider can decrypt, a lawful order to the provider can produce plaintext. Key custody is therefore the main technical control that changes sovereignty, not just residency.
| Pattern | Where keys live | Can the provider decrypt? | Trade-off |
|---|---|---|---|
| Provider-managed keys | Provider key service | Yes | No sovereignty benefit beyond residency |
| Bring your own key (BYOK) or customer-managed keys | Customer generates, provider key service holds and uses | Yes, while the key is in its service | Revocation and audit control; does not stop compelled access |
| Hold your own key (HYOK), external key manager | Customer-operated HSM or key manager outside the provider, called per operation | Only when your key manager approves each request | Latency and availability dependency; for Google Cloud, Key Access Justifications attaches a reason code to each key access so policy can approve or deny it |
| Double Key Encryption (Microsoft Purview) | One key held by the customer, one in Azure; both required | No, data is not accessible at rest to Microsoft 365 services | Microsoft scopes it to the most sensitive data (around 5%); eDiscovery, content search, mail flow rule scanning, web co-authoring and Copilot do not work on it |
| Client-side or application-layer encryption | Application or endpoint | No | Highest engineering cost; you build search, rotation and recovery yourself |
Two rules make HYOK real. The key manager must sit outside the provider's operational and legal control, otherwise it is BYOK with extra steps. And its administrators, backups and identity are in scope: a key manager whose admins federate to the same foreign-operated directory has moved the problem, not solved it. Encrypted data stored next to its key gives no protection, as the GoTo breach showed when stolen backups were taken together with their encryption key. See the Cryptographic Key Management Guide.
Identity data residency and identity sovereignty
Identity is where residency boundaries leak most often, because directories, authentication logs and admin access are global by design. Microsoft documents this precisely for Entra ID, a useful worked example.
- Tenant location is fixed: the country chosen at tenant creation maps to a geo-location and scale unit, and "Tenant location can't be changed after it's set". Choose it deliberately, and treat a wrong choice as a migration project.
- Component exceptions: MFA data is stored in "North America and/or in geo location" and logs the user principal name, phone numbers and SMS challenges; certificates for managed identities are written to a store in the East US region; B2B collaboration copies user data into other tenants.
- Authentication routing: sign-ins are served from the nearest data centre in the tenant's logical region, and authentication logs are written where the service instance runs.
- Customer identity (data sovereignty in CIAM): customer directories hold names, contact details and consent records for millions of people. Entra External ID offers a Go-Local add-on for storage at rest in Australia or Japan. Check where login logs, fraud signals and email or SMS delivery are processed, not only the profile store. See the Customer IAM (CIAM) Guide.
- Non-human identities: workload identities, service principals, API keys and their audit trails are identity data too. A sovereign workload that authenticates through a token issuer outside the boundary depends on that issuer's availability and jurisdiction. See the Cloud Workload Identity Guide.
Sovereign cloud identity governance
- Local identity plane: run the sovereign environment's directory, privileged roles and break-glass accounts inside the boundary, rather than federating every admin from a global tenant.
- Provider operator access: require just-in-time, customer-approved access for provider support staff, with logs you can export and review.
- Admin location and nationality: where the requirement covers operators, enforce it with conditional access by location and named admin groups, and review membership quarterly.
- Logs inside the boundary: route sign-in, audit and key access logs to a log store in the same jurisdiction; see the Log Management and Retention Guide.
Sovereign AI
Sovereign AI applies the same questions to models: where training data, prompts, outputs and fine-tuning sets are stored and processed, which jurisdiction governs the model host, and whether provider staff can see inference traffic. Prompts often contain personal and confidential data. Before enabling an AI assistant on resident data, check whether inference runs inside the boundary, whether prompts are retained or used for training, and whether the feature works on HYOK or double-key data at all (Copilot cannot read DKE content). See the AI and Privacy Guide.
Implementing a residency and sovereignty programme
- Write the requirement precisely. For each obligation record the source (statute, regulator, contract, policy), the data in scope, and whether it requires storage, processing, operation, key custody or all four in-country.
- Classify and map data. Tag datasets with a residency class (for example: no constraint, region preferred, region required, sovereign) in the data inventory, including logs, backups, support uploads and identity data. See the Data Classification Guide.
- Define the data residency boundary and map flows across it. State which regions, legal entities and operators are inside the boundary, then use provider data location documentation, sub-processor lists and egress logs to find telemetry, support, CDN, email, MFA and AI flows that cross it.
- Choose the model per class. Apply the decision guidance above; document a transfer impact assessment where personal data can be accessed from outside the EU or UK.
- Enforce with policy, not intent. Restrict allowed regions with cloud organisation policies (for example allowed-locations policies in Azure Policy or Google Cloud organisation policy, and service control policies in AWS Organizations), deny resource creation elsewhere, and block cross-region replication for resident classes.
- Pilot with one workload. Run the policy in audit mode for two to four weeks, fix violations, then switch to deny, with a documented exception path.
- Introduce key custody for the top tier. Pilot HYOK or double key on a small dataset, test key manager outage and recovery, and confirm which features stop working before wider rollout.
- Plan rollback and exit. Keep a tested export of resident data and keys. Rolling back a region policy is a policy change; rolling back key custody needs a re-encryption plan agreed in advance.
Detection and measurement
- Monitor: policy compliance events for allowed regions, provider operator access approvals, external key manager logs including denied requests, and new sub-processor notices.
- Alert on: storage or database created in a disallowed region, cross-region replication enabled on a resident dataset, a key access with an unexpected justification, and admin sign-ins to the sovereign tenant from outside approved locations.
| Metric | Definition | Target direction |
|---|---|---|
| Residency policy compliance | Resources in resident classes that are in allowed regions, as a percentage of all such resources | 100%, with time-bound exceptions |
| Classified data coverage | Datasets with a residency class recorded in the inventory | Rising to 100% of in-scope systems |
| Unmapped outbound flows | Flows of resident data out of the boundary not covered by a documented transfer basis | Zero |
| Provider operator access events | Provider access requests approved, denied and unexplained per quarter | Zero unexplained |
| Key custody coverage | Top-tier datasets protected by customer-held keys | 100% of the sovereign tier |
Framework mapping
| Control objective | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 |
|---|---|---|---|
| Know and meet legal and contractual location requirements | SA-9(5) Processing, storage and service location | A.5.31 Legal, statutory, regulatory and contractual requirements; A.5.34 Privacy and protection of PII | 3.2 Establish and maintain a data inventory |
| Govern cloud and supplier use | SA-9 External system services | A.5.23 Information security for use of cloud services; A.5.19 Information security in supplier relationships | 15.1 Establish and maintain an inventory of service providers |
| Customer-controlled keys | SA-9(6) Organisation-controlled cryptographic keys; SC-12 Cryptographic key establishment and management | A.8.24 Use of cryptography | 3.11 Encrypt sensitive data at rest |
In NIST CSF 2.0 the requirement analysis sits in GV.OC-03 (legal, regulatory and contractual requirements are understood and managed) and supplier controls in the GV.SC category.
Common failure patterns
- Accepting residency as sovereignty: an EU region from a provider under foreign jurisdiction meets a residency clause but not a requirement about foreign compelled access.
- Forgetting the side channels: support uploads, diagnostic logs, MFA records and AI prompts leave the boundary while the primary store complies.
- Keys inside the same trust domain: customer-managed keys in the provider's own key service, or an external key manager administered through the provider's identity plane.
- Global admin from a global tenant: the sovereign environment is administered by accounts and devices outside the boundary, so its control plane is only as sovereign as the global tenant.
- Sovereign everything: moving all workloads to a sovereign offering adds cost and removes features for data that never needed it.
- No exit plan: no tested export or re-keying procedure, so a change in law or provider status cannot be acted on in time.
Practitioner checklist
- Record each residency, localisation and sovereignty obligation with its source and the exact scope (storage, processing, operation, keys).
- Assign a residency class to every in-scope dataset, including logs, backups and identity data.
- Enforce allowed regions with organisation-level policy in deny mode after an audit-mode pilot.
- Complete transfer impact assessments where personal data can be accessed from outside the EU or UK.
- Protect the sovereign tier with customer-held keys and test key manager outage and recovery.
- Run the sovereign environment's privileged identities, break-glass accounts and logs inside the boundary.
- Require approval and logging for provider operator access, and review it quarterly.
- Test the export and re-encryption plan annually.
Standards and references
- Legal Information Institute: 18 U.S. Code 2713, Required preservation and disclosure of communications and records
- US Department of Justice: CLOUD Act Resources
- European Commission: EU-US data transfers
- NCSC: Cloud Security Principle 2, Asset protection and resilience
- ANSSI: SecNumCloud pour les fournisseurs de services cloud
- BSI: Cloud Computing Compliance Criteria Catalogue (C5)
- Microsoft Learn: Microsoft Entra ID and data residency
- Microsoft Learn: Double Key Encryption
Related NHI Mgmt Group resources: Global Privacy Regulatory Map · Encryption Guide · Cloud Security Guide · Data Security Guide · Identity Data Privacy and Consent Guide. This guide summarises data residency and sovereignty rules as of October 2026 and is not legal advice.