In SaaS marketing, “EU data residency” and “EU sovereignty” are used as if they’re synonyms. They aren’t. The first is about where the bytes sit. The second is about which company touches them and which legal jurisdiction governs that company. The first can be configured; the second is structural.
If your procurement team asks one question to evaluate a vendor’s sovereignty posture, ask which one of these two things they actually deliver.
EU data residency, defined
EU data residency means: customer data is physically stored on servers located within the geographical boundaries of the European Union.
This is what AWS-EU, Azure-EU, GCP-EU, Slack-EU, Microsoft 365-EU, and Salesforce-EU offer. You configure a region. The bytes go to Frankfurt or Dublin or Stockholm. The vendor can attest, technically and contractually, that the bytes are in Europe.
This is real and operationally useful. It means:
- Your data isn’t traversing transatlantic cables for routine operations.
- Latency for European users is local.
- Some local data-protection-authority requirements about cross-border transfers are met.
- The bytes are physically beyond the most direct US legal-process reach.
It is also incomplete as a sovereignty position. The vendor controlling the bytes is still subject to its own corporate jurisdiction, and that jurisdiction can compel disclosure of the bytes regardless of where they physically sit.
EU sovereignty, defined
EU sovereignty means: the legal entity that processes and controls customer data is incorporated in an EU member state, owned by EU-resident or EU-corporate shareholders, governed under EU law, and not structurally controlled by a non-EU parent or non-EU revenue base.
This is a property of the company, not of the infrastructure. A company is or isn’t EU-sovereign by virtue of how it’s incorporated, owned, and operated. You can’t configure sovereignty; you either built the company that way or you didn’t.
A vendor that delivers EU sovereignty by definition also delivers EU data residency (because they wouldn’t be sovereign if they hosted data in non-EU jurisdictions). The reverse isn’t true.
The concrete difference
Consider two scenarios.
Scenario A: A US-incorporated company offers EU data residency. Salesforce-EU stores your data in Frankfurt. Your data is in Frankfurt. Salesforce, Inc. (Delaware corporation) is the data controller. The US Department of Justice issues a CLOUD Act subpoena to Salesforce, Inc., for the data. Salesforce, Inc. is legally compelled to comply. The data is provided to US law enforcement. The fact that it’s in Frankfurt is not legal protection — Salesforce, Inc. is a US company subject to US law, and the data is under its custody.
Scenario B: An EU-incorporated company offers the same product. Hypothetical Sovereign Chat GmbH (a German company) stores your data in Frankfurt. Sovereign Chat GmbH is the data controller. The US Department of Justice cannot issue a CLOUD Act subpoena to Sovereign Chat GmbH, because Sovereign Chat GmbH isn’t a US company. If US law enforcement wants the data, they have to go through a Mutual Legal Assistance Treaty (MLAT) request, which routes through German courts and is subject to German legal protections, including European fundamental-rights protections.
The data is in the same physical location in both scenarios. The legal exposure is fundamentally different.
Why marketing conflates them
There are two reasons SaaS vendors talk about “data residency” as if it were sovereignty.
First, residency is configurable. A US company can offer “EU data residency” tomorrow by adding a region toggle. The cost is engineering. The marketing benefit is that the vendor can claim “we serve European customers with EU data residency.” The customer hears something close to “EU sovereignty” without anyone having said the word.
Second, true sovereignty is structural and irreversible. A US company can’t offer EU sovereignty without restructuring the company itself — re-incorporating in the EU, divesting US ownership, changing the revenue mix. None of these are configuration toggles. They’re corporate-level decisions that take years and cost real money. So they don’t appear on the feature list.
The result: the vendors that can deliver sovereignty (a small set of EU-incorporated companies) are competing against vendors that say sovereignty by saying “data residency.” The customer who doesn’t read carefully thinks they’re getting the same thing.
What to ask
If you’re evaluating a vendor and sovereignty matters in your contract, the questions that distinguish residency from sovereignty are:
- In what country is the entity that processes our data incorporated? Should be an EU member state.
- Who owns that entity? Should be EU-resident individuals or EU-corporate parents.
- Are any sub-processors non-EU-incorporated? If yes, sovereignty has a hole at every such sub-processor.
- What’s the contractual commitment to remain so? Should be in the DPA. Acquisition by a non-EU parent should trigger customer right of termination.
- Where does the company derive its revenue? A company that’s EU-incorporated but draws 80% of revenue from US customers is structurally responsive to US-government priorities.
These are not gotcha questions. They’re the questions that distinguish the marketing posture from the operational reality.
Where this lands for us
Our position is that we deliver sovereignty, not residency, and we say so contractually rather than configurationally. The EU Pledge binds us to remain EU-incorporated, EU-owned, and EU-revenue-concentrated. Our sub-processor list is EU-only by mandate. Acquisition by a non-EU parent triggers customer right of termination at no penalty. None of this is negotiable in our contracts.
That’s the choice the company made. The data is in Frankfurt the same way Salesforce-EU’s data is in Frankfurt. The difference is the company. That difference is the thing the procurement question is actually asking about.