Data Sovereignty vs Digital Sovereignty Explained

Data sovereignty asks which law governs a dataset, while digital sovereignty asks who can actually operate, change, switch off or be compelled to open the technology that holds it, and many programmes answer the first question and assume they have answered the second. A database pinned to a Frankfurt region can still be administered by staff in another jurisdiction, decrypted with keys the provider holds, and reached only through an identity provider whose control plane sits elsewhere. This guide separates residency, jurisdiction and operational control, explains where the identity plane and key custody decide the outcome, and gives a decision method for architects, privacy officers and CISOs choosing between ordinary regions, sovereign cloud offerings and fully European stacks. It goes deeper on the comparison than the Data Sovereignty and Residency Guide, which covers residency controls, and does not repeat the provider-by-provider review in the EU Sovereign Cloud Options Compared Guide.

Key takeaways

Three layers, not two terms. Residency is where bytes sit, data sovereignty is which law reaches them, and digital sovereignty is who controls the stack that processes them: operations, supply chain, software and identity.
Location does not defeat foreign compulsion. The US CLOUD Act reaches data in a provider's "possession, custody, or control" wherever it is stored, so residency alone does not settle jurisdiction.
Keys and clear text decide the transfer question. The EDPB accepts encryption as an effective safeguard only where keys stay under the exporter's control; where a provider needs data in the clear it could not identify an effective technical measure.
The identity plane is the quiet sovereignty gap. Whoever runs your directory, token service and privileged access path can grant themselves access to everything else, so its location, operators and failure mode belong in the assessment.
Sovereignty is now measurable. The European Commission's Cloud Sovereignty Framework scores providers on eight objectives and five assurance levels, SEAL-0 to SEAL-4, which gives buyers a shared vocabulary for "how sovereign is enough".

The short answer

Data sovereignty is a legal property of data: the principle that information is subject to the laws of the jurisdiction where it is collected or stored, and that other states should not be able to reach it without going through that jurisdiction's processes. Digital sovereignty is a property of capability: the ability of an organisation, sector or state to run, secure, evolve and if necessary replace its technology without depending on actors outside its control. Data sovereignty is one component of digital sovereignty, not a synonym for it.

Under a data sovereignty lens, a foreign production order is a legal conflict to be managed through contract clauses, transparency reports and challenge procedures. Under a digital sovereignty lens, the same order is a dependency to be engineered away: if the provider cannot technically read the data, or the operating entity is not subject to the foreign law, the conflict does not arise. A supplier withdrawing service, a sanctions regime or a licence change is mostly invisible to a data sovereignty assessment and central to a digital sovereignty one.

Residency, jurisdiction and operational control compared

The table separates the layers that residency is often assumed to deliver.

Layer	Question it answers	Typical evidence	What it does not prove
Data residency	In which country or region are data at rest and in processing?	Region selection, provider data location commitments, residency policy guardrails, backup and log location	Who can access the data, under which law, or whether support staff elsewhere can reach it
Data sovereignty (jurisdiction)	Which legal systems can compel access to, or transfer of, the data?	Contracting entity and its parent, transfer impact assessment, government access transparency reports, challenge procedures	Whether the provider can technically comply with an order, or whether operations survive a cut-off
Operational sovereignty	Who runs, supports and changes the service day to day?	Operator residency and nationality commitments, support access workflows, change approval, local staffing	Whether the software and hardware can be replaced, or who controls updates
Technological and supply chain sovereignty	Can the stack be audited, maintained and replaced without a single foreign supplier?	Open standards and formats, source availability, component origin, exit tests	Legal exposure of the operator
Identity and key sovereignty	Who issues credentials, approves privileged access and holds the decryption keys?	IdP and token service location and operator, key custody model, break-glass design, admin access logs	Physical location of the workload data

The Commission's framework, version 1.2.1 of October 2025, makes the same point formally. Its eight sovereignty objectives are SOV-1 Strategic, SOV-2 Legal and Jurisdictional, SOV-3 Data and AI, SOV-4 Operational, SOV-5 Supply Chain, SOV-6 Technology, SOV-7 Security and Compliance, and SOV-8 Environmental Sustainability. Data location is one part of SOV-3; it is one of eight.

Why location does not settle jurisdiction

Two legal mechanisms explain why a European region is not automatically a European legal space.

Extraterritorial production orders: 18 U.S.C. section 2713, added by the CLOUD Act in March 2018, requires a provider to preserve or disclose data within its "possession, custody, or control" regardless of whether it is located inside or outside the United States. A provider can move to quash or modify an order for a non-US customer's content where disclosure would create a material risk of violating the laws of a "qualifying foreign government", but that status requires an executive agreement in force. The US Department of Justice lists agreements with the United Kingdom (signed October 2019) and Australia (signed December 2021), and EU negotiations resumed in March 2023. See the CLOUD Act Guide.
EU blocking provisions: GDPR Article 48 states that third-country judgments and administrative decisions requiring transfer of personal data are recognised or enforceable only if based on an international agreement such as a mutual legal assistance treaty. For non-personal data, Article 32 of the EU Data Act (Regulation (EU) 2023/2854, applicable from 12 September 2025) requires data processing service providers to take adequate technical, organisational and legal measures, including contracts, to prevent third-country governmental access that would conflict with EU or Member State law, and sets conditions under which a provider may comply with a foreign order where no agreement exists. See the EU Data Act Guide.

The result is a conflict of laws that the customer cannot resolve by choosing a region. It can only be reduced by changing who the provider is (a legal entity not subject to the foreign law), what the provider can see (data it cannot decrypt), or both.

What the EDPB says about technical measures

The EDPB's Recommendations 01/2020 on supplementary measures (version 2.0, adopted 18 June 2021) set a six-step method: know your transfers, identify the transfer tool, assess its effectiveness, adopt supplementary measures, take procedural steps, and re-evaluate at intervals. Two of its use cases frame the sovereignty decision precisely:

Use Case 1, storage without clear-text access: encryption is an effective measure when it is strong, state of the art, correctly implemented, applied before transmission, and the keys are reliably managed and kept solely under the exporter's control or with an entity in the EEA or an equivalent jurisdiction.
Use Cases 6 and 7, processing in the clear and remote access: where the importer needs unencrypted data, and the third country's authorities have powers beyond what is necessary and proportionate, the EDPB could not envisage an effective technical measure. Encryption in transit and at rest does not help if the importer holds the keys.

That is the hinge between the two concepts. If your workload only stores data, data sovereignty can be largely engineered with customer-held keys. If the provider must compute on clear text, you need the legal and operational layers of digital sovereignty, or confidential computing that removes operator access. See the BYOK, HYOK and External Key Management Guide and the Confidential Computing Guide.

Threat model for each lens

Each lens implies a different threat model.

Threat	Data sovereignty response	Digital sovereignty response
Foreign government production order	Transfer impact assessment, contract commitments to challenge and notify, transparency reporting	Operating entity outside the foreign jurisdiction; keys the provider cannot use; no clear-text processing by the provider
Provider administrator or support engineer reaching data	Contractual access limits, data location commitments	Approval workflows the customer controls, operators resident in the jurisdiction, just-in-time support access logged to the customer
Service withdrawal, sanctions or licence change	Largely out of scope	Exit plan, portable formats, tested restore to an alternative stack, switching rights under the Data Act
Control plane outage or cut-off outside the region	Out of scope if data stays put	Region or partition able to run disconnected, identity and key services resident with the workload
Telemetry and logs leaving the region	Residency of logs and backups	Customer control of which telemetry is collected and where support diagnostics are processed

Where the identity plane decides the outcome

The identity plane here means the directory, the token and federation service, the MFA and risk engines, the privileged access path, and the workload identity issuer for non-human identities. Whoever operates these can mint a token that unlocks the data plane, so a sovereignty assessment that stops at storage misses the real control point.

Five questions expose the gap:

Where is directory and authentication data stored, component by component? Identity providers publish data residency pages; read them per component. Core directory data may sit in the tenant geography while MFA logs, risk telemetry, global certificate stores for managed identities or backup snapshots are stored elsewhere.
Who operates the token service and can issue an administrative credential? If provider staff outside the jurisdiction can reset a global administrator or sign tokens, operational sovereignty is limited regardless of data location.
Does the sovereign environment have its own identity system? Some sovereign cloud offerings run a separate partition with its own IAM, accounts and root credentials, which means federation, provisioning and workload identity have to be rebuilt rather than inherited.
What happens to sign-in if the link to the global control plane fails? A region designed to run disconnected is only useful if the IdP that its users and workloads depend on also keeps issuing tokens.
Where do machine identities come from? Workload identity federation from a CI system or SaaS hosted in another jurisdiction gives that issuer the power to impersonate workloads inside your sovereign estate. See the Cloud Workload Identity Guide and the Federation and Trust Relationships Guide.

Break-glass design is part of the same question. Emergency accounts that depend on a foreign-operated IdP, or whose credentials are escrowed with a provider team outside the jurisdiction, undermine the operational claim. See the Break-Glass Account Guide.

Measuring "how sovereign": the SEAL scale

The Commission used its Cloud Sovereignty Framework to assess providers in its Sovereign Cloud procurement, awarded in April 2026 for up to EUR 180 million over six years. The framework's assurance levels give buyers a way to state requirements without naming suppliers.

Level	Framework definition (summarised)	Rough equivalent in buyer terms
SEAL-0 No Sovereignty	Exclusive control by non-EU third parties under non-EU jurisdiction	Global service with no residency or jurisdiction commitments
SEAL-1 Jurisdictional Sovereignty	EU law formally applies but with limited practical enforceability; control remains with non-EU parties	EU region of a provider subject to foreign law, standard contract terms
SEAL-2 Data Sovereignty	EU law applies and is enforceable; material non-EU dependencies remain with indirect non-EU control	Residency plus enforceable EU-law commitments; the Commission set this as the minimum for eligibility in its tender
SEAL-3 Digital Resilience	EU law applies and is enforceable; EU actors hold meaningful but not full influence; marginal non-EU control	EU-operated entity and staff, independent operation, limited remaining supply chain dependency
SEAL-4 Full Digital Sovereignty	Complete EU control, subject only to EU law, no critical non-EU dependencies	European stack from hardware to software

The naming is useful in itself: the framework calls SEAL-2 "Data Sovereignty" and reserves "Digital Resilience" and "Full Digital Sovereignty" for the levels above it. National schemes such as France's SecNumCloud and the EU cybersecurity certification work on cloud services address overlapping requirements; see the France SecNumCloud Guide and the EU Cybersecurity Act and EUCS Guide.

When to require each

Residency only: data with a contractual or statutory location requirement but no special exposure to foreign access. Controls: region guardrails, log and backup location, customer-managed keys.
Data sovereignty: personal data subject to GDPR Chapter V analysis, or non-personal data in scope of Data Act Article 32 concerns, where processing in the clear by the provider is limited. Controls: transfer impact assessment, keys held outside the provider (external key management or HSM under your control), contractual challenge commitments, provider entity review.
Digital sovereignty: public sector, defence, critical infrastructure, health or financial workloads where continuity under geopolitical stress matters, or where the provider must process data in the clear. Controls: operating entity and staff within the jurisdiction, identity and key services resident and independently operable, tested exit, supply chain transparency. NIS2 and DORA third-party and concentration requirements often push regulated entities here; see the NIS2 Directive Guide and the DORA Guide.

Small organisations: start with residency, customer-held keys for the most sensitive stores, and a written exit plan; most do not need a separate sovereign partition. Large and regulated organisations: set a SEAL target per data class, and expect to run two identity planes (global and sovereign) with deliberate, minimal federation between them.

Trade-offs to plan for

Feature lag: sovereign partitions and European providers typically launch with a subset of services. Check that the managed services your architecture depends on, including key management, logging and identity, are available before committing.
Duplicated identity: a separate IAM system means separate accounts, roles, automation and audit pipelines. Without governance this creates orphaned identities and drift between the two estates.
Key custody burden: holding your own keys moves availability risk to you. Losing an external key manager can make data unrecoverable, so HSM resilience and key backup become sovereignty controls. See the Cloud Customer-Managed Keys and BYOK/HYOK Decision Guide.
Exit realism: digital sovereignty claims rest on being able to leave. Under Data Act Article 29, switching charges are prohibited from 12 January 2027, which lowers the commercial barrier but does nothing for proprietary formats or rebuilt identity. See the Cloud Concentration Risk and Exit Strategy Guide.

Worked scenario: a payments analytics platform

A European payment processor runs fraud analytics on transaction data in an EU region of a global cloud. Residency is satisfied. The DPO's transfer assessment asks three questions. First, can the provider be compelled to disclose? The contracting entity's parent is subject to a foreign production order regime, so yes in principle. Second, can it technically comply? The analytics engine processes data in the clear and keys sit in the provider's own key service, which matches the EDPB's Use Case 6, where no effective technical measure exists. Third, who can reach it operationally? Support engineers can request access through a provider workflow, and the identity provider's MFA telemetry is stored outside the EU.

The team splits the estate. Archived transactions move to storage encrypted with keys in an HSM the processor controls (Use Case 1 conditions). Live analytics move to a sovereign offering operated by an EU entity with EU-resident staff and its own IAM, assessed at SEAL-3. Workload identities for the analytics pipeline are reissued inside the sovereign partition, and the global CI system's federation trust is replaced by a runner hosted inside it. A disconnected-operation test confirms sign-in and key access continue for four hours without the global control plane.

How to implement

Classify data and workloads: tag each system with a residency, data sovereignty or digital sovereignty requirement and the reason (law, contract, continuity).
Map all three layers per system: data location, contracting entity and parent, operator and support access path, IdP and key custody, external identity issuers and telemetry flows.
Run transfer impact assessments using the EDPB six steps for personal data, and an Article 32 style review for sensitive non-personal data.
Fix the cheap gaps first: region guardrails, log and backup location, customer-managed or external keys for stores that do not need clear-text processing.
Pilot one digital sovereignty workload: build the identity plane, key service and logging inside the sovereign environment, with explicit federation rules, then run a disconnected-operation test.
Write and test the exit and rollback path: keep the original environment warm until restore and identity cutover are proven; roll back by repointing DNS and federation if the pilot fails acceptance.
Re-evaluate: repeat assessments when laws, provider ownership, executive agreements or adequacy decisions change.

Detection and measurement

Monitor the things that would silently break a sovereignty claim:

Provider administrative and support access events (customer-approved access requests, operator sign-ins), routed to your own SIEM inside the jurisdiction.
Key usage logs from the external key manager, especially decrypt calls from unexpected principals or regions.
New federation trusts and workload identity issuers added to the sovereign estate.

Metrics that show the programme is working:

Percentage of classified systems with all three layers mapped and reviewed in the last 12 months.
Percentage of high-sensitivity stores whose keys are held outside the provider.
Number of external identity issuers trusted by sovereign workloads, trending down.
Provider access events without a matching customer approval (target zero).
Last successful disconnected-operation and exit test date per digital sovereignty workload.

Common failure patterns

Region equals sovereignty: choosing an EU region and recording the jurisdiction question as closed, without reviewing the contracting entity or key custody.
Keys in the same hands: customer-managed keys that the provider's own key service can still use on the provider's behalf, which the EDPB treats as the importer holding the keys.
Forgotten identity plane: sovereign workloads that authenticate through a global IdP, or trust a CI system abroad to issue workload tokens.
Telemetry leakage: logs, crash dumps, AI abuse monitoring or support diagnostics processed outside the jurisdiction while the data store stays put.
Untested independence: claims of disconnected operation or exit that have never been exercised, discovered to fail only during an actual cut-off.
Two estates, no governance: duplicated identities in sovereign and global environments with no joiner, mover, leaver link, leaving orphaned administrative accounts.

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	GV.OC-03	Legal, regulatory and contractual requirements, including privacy obligations, are understood and managed
NIST CSF 2.0	GV.SC-05	Supply chain requirements written into supplier contracts (operator, location, access commitments)
NIST CSF 2.0	PR.AA-01	Identities and credentials managed by the organisation, the basis of identity plane control
NIST SP 800-53 Rev 5	SA-9(5)	Processing, storage and service location restrictions for external services
NIST SP 800-53 Rev 5	SC-12	Cryptographic key establishment and management (key custody)
NIST SP 800-53 Rev 5	SR-3, CP-2	Supply chain controls and contingency planning for provider loss
ISO/IEC 27001:2022 Annex A	5.23, 5.31, 5.34	Security for cloud services; legal, statutory, regulatory and contractual requirements; privacy and protection of PII

Practitioner checklist

Record residency, jurisdiction and operational control separately for every sensitive system.
Hold keys outside the provider for any store that does not need clear-text processing.
Read the IdP's data residency documentation component by component and record exceptions.
Inventory every external identity issuer trusted by sovereign workloads and remove those outside the jurisdiction where possible.
Route provider access and key usage logs to a SIEM you operate inside the jurisdiction.
Set a SEAL target per data class and use it in procurement requirements.
Test disconnected operation and exit at least annually, including identity and key services.

Data Sovereignty vs Digital Sovereignty: From Data Location to Control of the Stack