Data Sovereignty Is Not Data Location: Measuring Real Control Over Digital Infrastructure

There is no single universal use of data sovereignty that has the same legal meaning across all EU instruments.

These concepts overlap, but they are not synonyms. GDPR compliance is not proof of technological independence. EU-based storage is not proof that a workload can be recovered independently of its provider.

The Commission’s Joint Research Centre similarly frames EU digital sovereignty as strategic independence in the digital domain while remaining open and connected to global networks.12 That is a useful corrective to the idea that sovereignty necessarily means isolation.

The argument that residency is insufficient should not be turned into the opposite claim that geography is irrelevant.

Location can materially affect international personal-data transfers, sector requirements, procurement, governmental-access analysis, disaster-recovery design, performance and particular national-security obligations.

Residency therefore belongs in the assessment.

The European Commission’s 2026 Cloud Sovereignty Framework makes the limitation of a location-only model visible. Developed for the Commission’s sovereign-cloud procurement, it assesses sovereignty across eight objectives: strategic; legal and jurisdictional; data and AI; operational; supply chain; technological; security and compliance; and environmental sustainability.34

A country field in a cloud console cannot represent all of those dimensions.

The primary database is the most visible part of a service. It is not necessarily where the most consequential control resides.

Identity

An organisation can formally own its data while being unable to administer the service without an external identity plane.

The assessment should establish who can create or recover a privileged administrator, what happens if the primary identity service is unavailable, whether a controlled emergency-access path exists, how provider support access is granted and where evidence of that access is retained.

If those processes are opaque, an EU data region does not remove the administrative dependency.

Cryptographic keys

Customer-managed keys can materially improve control, but the architecture still matters.

Where are keys generated and held? Who can change key policy? How do rotation and recovery work? How are backups protected? Can the provider access plaintext in the service’s actual runtime design? What happens to key dependencies during provider exit?

Key control is useful evidence. A customer-managed label is not a substitute for understanding the surrounding service.

The control plane

Cloud conversations often focus on object stores, databases and virtual disks.

Operational power frequently sits in the control plane: the systems that create or delete resources, alter network and access policy, activate support paths, create backups, move workloads and initiate recovery.

A sovereignty map therefore needs both the data plane and the control plane. Otherwise an organisation may know precisely where its data is stored without knowing who can materially change the service state.

Security logs can contain identifiers, IP addresses and investigation evidence. Observability platforms may receive request metadata or content. Support systems can hold diagnostic exports and screenshots. Backups may use a different region or provider path from the production service.

A useful inventory should therefore cover primary data, replicas, backups, logs, telemetry, support data, exports and deletion copies.

The same principle applies to suppliers.

The company named in the contract may depend on another hyperscaler, CDN, identity platform, DNS service, observability system, software vendor or specialist subcontractor.

For essential and important entities within its scope, NIS2 already treats supply-chain security and relationships with direct suppliers and service providers as part of cybersecurity risk management.5 NIS2 is not a general data-sovereignty regime, but it reinforces a relevant engineering point: a critical external dependency remains part of the service risk even when another organisation owns it.

Many providers offer data export. That is not the same as moving a service.

A credible migration may require data and schemas, role mappings, service configuration, infrastructure definitions, certificate and key-transition procedures, integration inventories, queued state, audit evidence, operating documentation and enough transition time to build and validate the destination.

The EU Data Act is important here. Chapter VI requires providers of data processing services, within its defined scope, to remove contractual, commercial, technical and organisational obstacles to effective switching and establishes contractual and technical obligations around portability and switching.6

Those rights matter. They do not make a complex SaaS or PaaS workload operationally portable by themselves.

An exit test is stronger evidence than an exit paragraph

A policy can say, “If necessary, we will move to another provider.”

A test establishes whether a representative dataset can be exported, whether the format is usable, whether identity and access can be reconstructed, whether audit evidence survives, how long the transition takes and which steps unexpectedly require the incumbent provider.

The financial sector provides a useful regulatory example. Under DORA, financial entities using ICT services to support critical or important functions must develop exit strategies, and exit plans must be sufficiently tested and periodically reviewed.7

That is a sector-specific obligation. The underlying assurance logic is broader: a migration claim becomes more credible after someone has tried to execute it.

Recovery is an even harder test

Suppose the provider becomes unavailable. The organisation has an export and a backup. Can it restore an authoritative service?

A backup that can be reached only through the failed provider’s control plane may not solve the problem. Data without identity, keys, configuration, licences, executable software or operational knowledge may not be enough either.

This is why my 2026 Commission consultation response proposed including recoverability in a practical sovereignty model: the ability to retrieve authoritative data, preserve integrity and audit evidence, recover or rotate credentials and keys, and maintain a defined minimum service during provider or connectivity disruption.2

The sovereignty question is concrete: can the organisation recover without depending entirely on the same path whose failure it is supposed to survive?

“Third-country access” should not be discussed as though all data were governed by one rule.

For personal data, GDPR Chapter V regulates transfers to third countries and international organisations. Article 48 separately addresses third-country court or administrative decisions requiring a controller or processor to transfer or disclose personal data.8

For non-personal data, Article 32 of the Data Act requires providers of data processing services to take appropriate technical, organisational and legal measures against international or third-country governmental access and transfer of non-personal data held in the Union where that would conflict with Union or applicable Member State law.9

Those mechanisms are not interchangeable. A serious assessment identifies the data class, applicable law, controlling party and actual access path before drawing conclusions about jurisdictional exposure.

Two shortcuts are particularly attractive.

The first is:

EU provider = sovereign non-EU provider = not sovereign

Provider ownership, jurisdiction and third-country dependency can be highly material. But the Commission’s own 2026 sovereign-cloud procurement used the multi-dimensional Cloud Sovereignty Framework and assurance levels rather than a single nationality test. The Commission also stated that non-European technology, under a sufficiently strict operating framework, can meet the minimum sovereignty level required for that procurement.10

The second shortcut is:

open source = sovereign

Open source can improve auditability, independent maintenance and portability. It can still depend on one managed service, one identity platform, one proprietary data layer or one specialist team.

Multi-cloud has the same trap. Two clouds are not independent if both rely on the same identity provider, DNS control, key hierarchy, deployment pipeline or small group of people.

The useful question is which dependencies the organisation can actually replace, recover or operate without.

The Commission’s Cloud Sovereignty Framework was used in an actual procurement and contains 48 criteria grouped across eight sovereignty objectives, alongside Sovereignty Effectiveness Assurance Levels (SEAL).34

In June 2026, the Commission also proposed the Cloud and AI Development Act (CADA). The Commission’s public description sets out a proposed single EU-wide cloud and AI sovereignty framework with four assurance levels. The first begins with Union-based data processing and storage; progressively higher levels add stronger requirements around third-country independence, supply-chain transparency, EU ownership/control and technological autonomy.11

The legal status matters: CADA is a Commission legislative proposal at the time of writing, not an adopted regulation.

The structure is nevertheless instructive. Location is the first layer, not the entire concept.

An organisation does not need to begin with an ideological debate about “sovereign cloud”.

It can begin with ten questions that can be answered with evidence.

The table is only useful if the evidence is real. A provider questionnaire marked yes and a successful restore exercise are not equivalent assurance.

A public brochure site, an internal collaboration platform, a clinical-data environment and a nationally critical service are not equivalent risk objects.

A low-impact workload may need little more than residency visibility, contractual transparency and basic portability. A more sensitive service may require explicit control over identity, keys, logs, backups and material subcontractors. A critical workload may justify a tested restore or exit, an independent recovery path, deeper supply-chain analysis and evidence of control over privileged administration.

These are not statutory EU tiers. They are a practical risk-based model for avoiding two poor extremes: a meaningless EU-hosted checkbox and blanket localisation for every workload.

The Commission’s 2026 targeted consultation on safeguarding EU data sovereignty asked specifically about international data flows, third-country access risks and wider data-related dependencies.1

FINULIO’s response made four related points.2

First, sovereignty should be assessed as demonstrable control rather than location alone.

Second, material dependencies should be mapped across the data plane, identity, key management, administrative/control planes, logs, backups and subprocessors.

Third, portability and exit should be testable capabilities rather than contractual claims.

Fourth, the model should remain risk-based. Trusted international data flows can coexist with sovereignty where control, transparency, safeguards and recovery can be demonstrated.

That last point is consistent with the consultation’s own framing: the Commission describes data sovereignty as compatible with openness to trusted partners and cross-border data exchange.1

There is a useful balance here. Overly simple localisation can create expensive isolation. A “sovereign” label without testable control is difficult to distinguish from marketing.

“Where is our data?” is a necessary question.

The next questions concern identity, keys, administrative power, logs, backups, supplier chains, portability and recovery. They establish whether the organisation can continue, restore or leave without losing control of the data and evidence that make the service authoritative.

Data sovereignty becomes practically useful when those answers can be demonstrated.

EU legal and policy sources were checked on 25 September 2026. The ten-question control model in this article is the author’s analytical framework, not an EU statutory sovereignty classification. The European Commission’s 2026 Cloud and AI Development Act is a legislative proposal and is not presented here as an adopted regulation.

This article analyses technical, organisational and regulatory practice. It is not individual legal advice.