Data residency vs. data sovereignty: What enterprises need to know before standardizing on a cloud suite

Where does your data live? You likely have a confident answer to that question—or at least a general idea. But whose laws govern your data? For many enterprises, that answer isn’t quite so clear. 

That confusion is exactly where trouble starts to creep in. Data residency and data sovereignty are often used like synonyms, but they’re talking about two different things. One is about geography, while the other is about jurisdiction. 

When you’re standardizing on a single cloud suite across your entire enterprise, mixing them up could mean that you’re less protected than you think. Before you pick a cloud suite, it’s worth understanding exactly what you’re agreeing to—and what questions you should ask to find out.

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

The terms get conflated constantly, but they’re actually two distinct concepts.

Data residency is about location. It refers to the physical place where your data is stored—which country, region, and data center. If your company chooses to store data in Frankfurt, that’s a residency decision. Many enterprises operate under a residency requirement, meaning a regulation, contract, or internal policy that dictates that data must remain within a specific country or region.

Data sovereignty is about authority. It refers to whose laws govern that data, regardless of where it physically lives. This is where things get tricky: Storing data in a particular country doesn’t automatically mean that country’s laws are the only ones that apply.

Let’s break this down with a real-world example. In 2024, the Dutch Data Protection Authority fined Uber over $300 million for improperly transferring European drivers’ personal data to the United States. 

There was no dramatic breach of government investigation. It was just Uber doing what most global companies do: routing driver data to systems based in the US. Uber had gone more than two years without the right transfer mechanism in place, based on an incorrect read of how far GDPR’s scope actually extended. 

It’s an alarming example, but it’s the same kind of thing that trips other enterprises up—an everyday mismatch between where your data sits, who can actually get to it, and what the rules say should happen. And that mismatch can go unnoticed for years until an audit or a complaint brings it to light.

Plus, this type of scenario is surprisingly common. Syncing customer data into a CRM or giving a remote support team access from another country can both count as data transfers under GDPR. But this isn’t just a European problem. As of 2026, over 140 countries have enacted data privacy legislation.

So, put simply, you can check the residency box and still carry sovereignty risk you never even realized. That’s why it’s such an important thing for enterprises to pay attention to—especially before standardizing on a platform that will house data across departments, regions, and use cases.

Why this matters even more once you standardize on a single cloud suite

It’s a scary risk—and one that gets even scarier when you pick one suite for everything. You’re no longer making a residency or sovereignty call once. You’re making it for every department and every piece of data that touches that platform, all at the same time.
When you use a mix of different tools, a sovereignty problem with one vendor stays pretty well contained to whatever that specific platform touches. But once HR, sales, finance, and support all run through the same suite, that vendor’s legal footprint becomes your legal footprint—everywhere, and all at once.
That’s exactly why regulators are starting to pay closer attention to this kind of setup. In banking, as just one example, the EU’s Digital Operational Resilience Act (DORA) now requires companies to actively track how dependent they are on any single provider. They also need to have a backup plan ready, because relying too heavily on one vendor can leave the whole business exposed if something goes wrong. That could look like:

• An outage that takes down every connected department all at once.
• A legal dispute that suddenly affects every department’s data.
• A change in how the vendor handles, stores, or shares data, with no easy way to change course.
  
  And if you’re in a regulated industry (like finance, healthcare, or the public sector), the stakes are even higher. These sectors often face stricter, sector-specific residency and access rules on top of general data protection law. That means a single vendor’s footprint can create compliance exposure across multiple regulatory frameworks all at once.
  None of this means that standardizing on one cloud suite is a bad idea. There are plenty of upsides—like fewer integration headaches, more consistent security practices, and a single source of truth (instead of dozens of scattered ones). But those upsides only hold up if you’ve actually checked your vendor’s footprint first.

What to look for before you commit to a cloud suite

It’s easy to get hung up on features and pricing when you’re picking a cloud suite.
But this is also a decision about whose laws will govern your data, and that’s worth a closer look before you sign anything. Here’s what you should determine before making your final decision.
Where the vendor is legally headquartered (not just where its data centers are): A vendor can offer EU-based servers while still being owned by a US parent company that’s subject to US law. Both AWS and Microsoft, for example, are owned by US parent companies—despite having data centers all over the world.
Whether the vendor can guarantee your data stays put: Don’t just take “we store data in your region” at face value. Ask directly whether the vendor can guarantee that data won’t be accessed or disclosed under other country’s laws. 
Who else touches your data: Most platforms rely on subprocessors for things like infrastructure, monitoring, or support. Each one adds another link in the chain (and potentially more risk). Ask for a current list of subprocessors and where each one operates.
What happens during backups, recoveries, and support access: Data residency commitments often cover primary storage but skip over backups, disaster recovery copies, or remote support sessions. Ask specifically about each one.
Whether the contract includes real transfer mechanisms: If data moves across borders, there should be a documented legal mechanism behind it (like the EU-US Data Privacy Framework), not just an assumption that it’s fine. That’s the exact assumption Uber was fined for.
What your exit plan looks like: If you ever need to switch vendors or pull data back in-house, how hard will it be to do? Standardizing on one suite shouldn’t mean getting locked into it.
None of this requires becoming a privacy lawyer. It just means asking specific, direct questions instead of assuming “we’re GDPR compliant” covers everything.
Keep in mind that you may not always get a clean answer to your questions. Even major vendors can’t always make airtight guarantees. When Microsoft’s own legal director for France was asked under oath whether he could guarantee French citizens’ data would never be transmitted to US authorities without the French government’s consent, he couldn’t make that promise. The most he could offer was that it hadn’t happened yet. Basically, just because it hasn’t happened doesn’t mean
it can’t happen.
So, you won’t get ironclad guarantees—but that’s not a reason to skip the questions. Think of it as a process for evaluating risk, not a search for a perfect, risk-free vendor (because that doesn’t exist).

What to ask before you sign

So, what specific, direct questions should you ask to get a handle on your risk? Vendors are used to fielding broad compliance questions, and they’ve got polished, general answers ready to go. 
The goal here is to skip past those and ask things that are harder to deflect. You want to focus on questions that force a specific answer (rather than a default to marketing scripts). Here’s where to start:

• “Can you guarantee that our data stays in [region], including backups and disaster recovery copies?”
• “Are you legally required to disclose our data to any government, regardless of where it’s stored?”
• “Who are your subprocessors, and where is each one located?”
• “What transfer mechanism applies if our data moves across borders?”
• “If we leave, how long would it take to fully extract our data, and in what format?”
• “Has a regulator or auditor ever flagged a data residency or sovereignty issue with your platform, and how was it resolved?”
  If a vendor offers a hesitant or vague answer to any of these questions, consider it a red flag. A vendor that’s done the work should be able to provide a clear, specific answer—not just point you to a general compliance page.

Ask the hard questions, get the clear answers

Picking a cloud suite is a big decision, and data residency and sovereignty deserve the same scrutiny you apply to pricing, features, and uptime guarantees. Fortunately, you don’t need a law degree to get there. You just need to ask the right questions before you sign. 
Keep in mind that this isn’t a one-time check. Laws shift, vendors get acquired, and
subprocessors change. The agreement you sign today is a snapshot instead of a permanent guarantee. Set aside time to revisit these questions down the line, and treat sovereignty as something that you need to manage actively.
Remember, ask clearly. If the response is murky, that’s your answer.