Data sovereignty vs data residency: What’s the difference?

What is the difference between data residency and data sovereignty?

Data residency is about where data is physically stored or processed, while data sovereignty is about which country’s laws apply to that data and who actually has authority over it. The main difference between data residency and data sovereignty is that one is about geography and the other is about law and control. 

In the context of cloud, data residency describes where your data is physically located.. This could be a cloud region (a group of data centres in one area), a single data centre or a processing environment. It can also include copies, such as backups and replicas kept for safety or speed. This means one organisation may have several relevant data locations.

Knowing where your data lives is useful. But it’s only half the story. Data sovereignty looks at the legal side: which country has the authority to govern and regulate that data, which can depend on where it was collected as well as where it is stored. Those rules can affect what data a company may collect, where it may keep it and for how long. Where you store your data can nudge which rules apply, sure, but it doesn’t get the final say.

A real-world case makes this clearer. Say a US cloud provider stores a European customer’s data in a data centre in Croatia. The data resides in Croatia. But because the provider is American, the US CLOUD Act can require it to preserve or hand over data it controls, even when that data is sitting on the other side of the world. This doesn’t mean the US government can simply take whatever it wants. Any request has to follow a legal process, and in some cases the provider can push back.

The takeaway: knowing where your data is stored does not tell you who can reach it.

For cloud and SaaS decisions, there are really five questions worth asking yourself. Where is the data stored, backed up and processed? Who can access it, including the provider’s support staff? Which company, in which country, runs the service? Which country’s laws apply, especially when data crosses borders? And what evidence shows the controls really work? Picking a hosting region only answers the first one. Organisations in regulated fields such as healthcare or finance need all five answered.

What is data residency?

Data residency is the physical or geographic location where data is stored or processed. That could be a data centre, cloud region, server or processing environment. Think of it as the address where your data lives. It is not always just one address. The live system, its backups and its disaster recovery site (a standby setup that takes over if the main one fails) can each be in a different place.

For example, a healthcare provider might store patient records in a cloud region in Frankfurt, because its contracts set a cloud data residency requirement: the data has to stay in the EU. That answers the residency question for the main database, since the data resides in Germany. But that is only part of the answer. The provider still needs to find out where its backups, disaster recovery site and support tools are located.

This is why residency is not always one fixed point on a map. One organisation can have several residencies at once. Live patient data might sit in Frankfurt, a backup in Amsterdam and an analytics copy in Dublin. Where data is stored often influences which country’s laws apply to it, so residency and sovereignty are closely linked. 

Residency is also not the same as data localisation. A residency requirement can come from a contract, a policy or a customer promise. Localisation is stricter: it is a legal rule saying that certain types of data must stay inside a country or region.

Residency requirements drive: which cloud region to use, where the data centre should be, which provider to trust, what to ask for in procurement and what evidence to keep for audits. They also affect speed (how quickly data travels, known as latency) and whether data can be sent across borders. But residency alone does not prove compliance or sovereignty. It is one check among several.

¿Qué es la soberanía de los datos?

Data sovereignty is the idea that data is subject to the laws of the country or region where it is created, stored or processed, and that this country or region has the authority to govern it.. That sounds simple, but it raises a few big questions. Which country’s laws apply? Who can get at the data? What do the contracts with your provider say? And what happens when an authority asks for the data? Location matters,  but it does not settle the question. Sovereignty also covers what your provider is legally required to do and whether you can prove your controls actually work.

For example, a hospital group keep patient records in an EU data centre, but a support company outside the EU can log in remotely to fix problems. The storage location has not changed. Yet that access can still count as sending the data abroad, and the support company’s home country may have its own rules about it. A sovereignty assessment therefore needs to look beyond the physical server. The hospital needs to confirm a few things: which laws apply, who runs the systems, which company provides the service and what proof shows it stays in control.

Data sovereignty requirements can affect what data an organisation collects, where it stores it, how it uses it and what IT setup it needs. Cloud providers are a good example. You can choose a cloud region, but you still need to know where your data goes for storage, backups and processing, and which company is legally responsible for the service. The European Commission takes the same broad view. Its Cloud Sovereignty Framework assesses cloud services across eight objectives, including strategic, legal, operational and technological factors, not just where the data is stored. For more detail, see our full guide to data sovereignty.

Key differences between data residency and data sovereignty

Data residency and data sovereignty are related, but they are not interchangeable. Data residency helps establish where data is located. Data sovereignty goes further by considering the legal authority, access controls and responsibilities that apply. The difference between data residency and data sovereignty shows up in four areas: infrastructure, access, data handling and evidence.

Infrastructure location vs legal jurisdiction

Data residency comes down to one simple question: where does the infrastructure actually run? That means the data centres, cloud regions and servers doing the storing and processing. But it’s rarely just one location. Backups, replicas and recovery systems often live somewhere else entirely, and those count too. The UK’s National Cyber Security Centre, for instance, says a provider should give a full list of the countries where data is stored and processed, and where the service is managed and supported from.

Data sovereignty, on the other hand, is about who has legal authority over that data. Server location can be relevant, but it does not automatically decide which laws apply. The GDPR is a good example of data sovereignty: it can apply to an organisation established in the EU regardless of where the processing physically takes place. Where the provider is based, where your organisation is based and whether people in other countries can reach the data all matter too.

Security and access governance

Data residency tells you where data is located. It does not necessarily tell you who can access it or from where. Data can stay in an approved region while administrators or support teams access it remotely, sometimes from another country. Under EU data protection guidance, remote access from outside the EU by a separate organisation, such as a provider’s support team, can itself count as an international transfer.

Consider a bank that keeps its customer records in an EU region. The data is exactly where it should be, yet a support engineer based in India can still log in to fix a technical issue. Residency is satisfied. But that remote log in raises a different question: does the engineer’s own country now have any legal reach over that data,because someone there can access it? That’s the sovereignty question, and it has nothing to do with where the servers sit.

This is why sovereignty often calls for its own layer of protection, on top of residency, such as encryption, strict limits on who can act as an administrator and control over who holds the encryption keys. No single control proves sovereignty on its own. Together, they help show that the legal and contractual limits on access are actually being respected, not just written down.

Data handling and ownership

The difference between data residency and data sovereignty also appears across the data lifecycle (everything that happens to data from the moment it’s collected to the moment it’s deleted). Residency establishes the relevant locations used to store and process data. On its own, it does not explain which organisations operate those environments, who can process the data or which other parties are involved.

A sovereignty assessment looks at those wider relationships: who owns the data, who can access it and who processes it. That includes the provider’s own operations, its support staff, any subcontractors that handle data on its behalf (often called subprocessors), transfers across borders. Under the GDPR, for example, a processor needs the controller’s prior written authorisation before engaging another processor. In cloud and SaaS environments, understanding how data is handled can be as important as knowing where the primary copy is stored.

Proof of location vs proof of control

Data residency evidence should show where relevant data is stored and processed. Where applicable, it should also cover backups, replicas, logs and recovery. Contracts, service documentation, architecture information and configuration records can help establish that geographic picture.

Data sovereignty asks for more, because it is about control as well as location. Organisations may need to show who can access the data and how that access is governed, how support teams operate, how transfers and legal requests are handled, and who holds the encryption keys. In the cloud, responsibility is shared between provider and customer, so it also helps to know which controls the provider runs and which ones you are responsible for setting up yourself.

In short, data residency can support data sovereignty, but it does not prove sovereignty on its own.

Why the difference matters in cloud, SaaS and infrastructure decisions

Choosing a cloud region can help an organisation meet a data residency requirement. But location is only one part of the decision. Here’s the thing: the moment you bring in a cloud or SaaS provider, you’re not just handing over data. You’re also handing over part of the day to day operation of the environment too. Organisations need to understand who runs the environment, who can access it, which legal entities are involved and which controls remain in the customer’s hands.

This becomes especially important when an organisation has less direct control over the underlying infrastructure. Take a typical SaaS customer. It doesn’t manage the servers, and it doesn’t have full visibility into how the provider runs things behind the scenes. So it needs answers: what do the contracts actually say, are there subcontractors involved (sometimes called subprocessors), how is access arranged, and what audit evidence is even available? Sovereignty is less about where the data is stored and more about whether you know who’s allowed to touch it, run it or change it, and how that gets enforced.

That question doesn’t go away once things are running smoothly, either. Support requests, security incidents, failover (when systems automatically switch to a backup) and recovery can all change who accesses the data, which systems process it and even, for a while, which country it’s processed in. Regulated or data-sensitive organisations need to understand whether their intended legal, operational and access controls can still be maintained when something goes wrong, not just when everything is working as planned.

Consider an organisation running its production environment in an EU cloud region. That location may satisfy its residency objective. A sovereignty assessment goes further: who can administer the environment? Where can support access come from? Who controls the encryption keys? What happens during recovery? What evidence can the provider supply? Choosing a region does not answer any of these questions on its own.

This is exactly why regulated and data-sensitive organisations are starting to ask for more than a location on a map. The European Commission’s recent sovereign cloud tender, for example, scored providers on 48 criteria across eight categories. Buyers want infrastructure that is clear about both location and control. That’s the thinking behind Ilkari’s approach to sovereign cloud and data centre services: not just telling you where your data lives, but showing you who can reach it, who runs it and who can prove it.

Quick checks before choosing a cloud or infrastructure provider

Before choosing a cloud, SaaS, data centre or infrastructure provider, run through data residency and data sovereignty together, not one after the other. The review should establish where data goes, who can access it and what evidence supports those answers.

The European Commission has published a Cloud Sovereignty Framework that any organisation, public or private, can use as a starting point when comparing cloud providers.

• Where does the data originate? Identify every entry point, such as users, devices, offices, apps and any APIs or integrations feeding data in. People often stop at “our app,” but data usually sneaks in from more places than that.
• Where is it stored and processed? Check production storage, processing environments and managed services separately. Some managed services process data outside the region where it is stored.
• Where are backups, recovery copies, logs and relevant metadata kept? Confirm whether the stated residency boundary still holds outside production. It’s easy to confirm the main database and overlook the copies held elsewhere.
• Which legal entities and jurisdictions are involved? Identify the provider’s own legal entity, its parent company and any subprocessors involved. Where a company is headquartered can matter just as much as where its serversare located, because its home country’s laws may still reach the data.
• Which laws, contracts and customer commitments apply? List the privacy and sector rules, contractual obligations and customer promises that set the requirements, including any transfer restrictions, before comparing providers.
• Who can access the data, and from where? Include administrators, support organisations and subprocessors, and check where each of them works from, since remote access from another country can raise its own legal questions.
• How are encryption and keys controlled? Check who holds the encryption keys, not just whether the data is encrypted. Encryption alone does not settle the question if the provider holds both the data and the keys.
• Which technical controls enforce this, in practice? Review region restrictions, access controls and any policy that actually blocks data or workloads from moving outside approved locations. A policy on paper and a technical control are two very different things.
• What evidence supports the answers? Look for appropriate contracts, service documentation, configuration evidence, subprocessor information and audit material. If you can’t point to something concrete, you don’t really have an answer yet.
• What changes during failover, incidents, deletion or exit? Establish recovery locations, retention arrangements, restoration and portability before they’re needed, and confirm that an emergency failover couldn’t move data somewhere it isn’t allowed to go. This is the scenario most often left out of planning.

Here’s a simple way to hold all of this in your head: ask where data is stored, processed, copied, accessed, governed and evidenced. It’s the same rule Ilkari applies when assessing its own sovereign cloud and data centre environments. Then ask one final question: do any of those answers change during an incident?

Conclusión

Knowing where data resides is important, but location doesn’t explain how the data is governed. Organisations also need to understand who can access the environment, which authorities and requirements may apply and how their intended controls can be demonstrated. Those questions matter just as much when something goes wrong, such as during support requests, recovery or exit, as they do during normal operation..

A sound cloud or infrastructure decision needs both location visibility and governance evidence. Neither one on its own is enough. A local data centre doesn’t prove compliance. Neither does a sovereign-cloud label.

Ilkari treats this as a matter of infrastructure governance. Location and control aren’t boxes you tick once and forget about. They’re things an organisation has to be able to prove, whenever someone asks. For any organisation, the final question is practical: can it demonstrate that its chosen architecture provides the location and control its workload requires?