Data sovereignty

What is data sovereignty?

Data sovereignty is the question of which laws, authorities, and jurisdictions can affect your data. In practical terms: which government can request access, under which rules, and what protections apply?

For a business using cloud services, this is not abstract. Customer data in a warehouse, invoice backups, chatbot logs, support tickets, and AI prompts may all fall under legal regimes. The answer depends on where the data is stored, where the provider is established, what contracts say, and who can access the data.

Physical location matters, but it is not the whole story.

Sovereignty, residency, and localisation

Data residency
Where is the data physically stored or processed? A cloud region or datacenter location answers that.

Data sovereignty
Which laws and authorities can reach the data? Provider jurisdiction, contracts, encryption, and access controls can all matter.

Data localisation
Does a law require the data to stay inside a country or region? Localisation is a legal obligation, not just a preference.

A company can have European data residency and still have a sovereignty discussion if the cloud provider is subject to non-European law.

GDPR and the CLOUD Act

The most common example is the tension between European data-protection rules and the US CLOUD Act.

GDPR restricts transfers of personal data outside the European Economic Area unless the right safeguards are in place. The US CLOUD Act, enacted in 2018, clarifies that US providers can be required through lawful process to produce data under their possession, custody, or control, even when the data is stored outside the United States.

That does not mean every foreign government can freely browse your data. Requests require legal process, providers may challenge certain demands, and treaties or executive agreements can matter. But it does mean that a simple statement such as our data is in Europe is not a complete sovereignty assessment when the provider is subject to another jurisdiction.

What can you do?

Choose the right region
Residency still matters. Choose cloud regions that match your contractual and regulatory requirements.

Use provider boundary commitments carefully
Microsoft's EU Data Boundary and sovereign-cloud offerings can help reduce transfer and access risk for in-scope services. Read the service scope and configuration details.

Manage encryption keys
Customer-managed keys, and in stricter cases hold-your-own-key designs, can reduce the practical value of data to a provider or third party. They do not remove every legal question, but they change the access model.

Limit and log access
Zero-trust controls, just-in-time access, approval workflows, and audit logs matter as much as region choice.

Classify data
Not every dataset needs the same controls. Personal data, health data, government data, financial records, trade secrets, and ordinary public content need different treatment.

An SME example

A Belgian software company stores customer support tickets in a European cloud region. The tickets include names, contact details, and sometimes screenshots with personal data.

Residency is European. Sovereignty still needs more questions: who is the provider, which subcontractors support the service, which administrators can access the environment, how are keys managed, and what happens if a lawful access request arrives?

The answer does not have to be panic or cloud avoidance. It has to be a documented risk decision with controls that match the sensitivity of the data.

What to watch out for

Resident in Europe is not the same as sovereign
Physical storage location and legal reach are related but separate.

Global services and subprocessors
Identity, logging, support, routing, and monitoring services may have their own data paths.

Encryption without ownership
Encryption helps most when key ownership and access policies match the sovereignty requirement.

Shadow copies
Exports, backups, support bundles, and copied datasets often escape the controls applied to the primary system.

Sector rules
Government, healthcare, financial services, and critical-infrastructure work may have stricter requirements than general GDPR practice.