Data Residency vs Data Sovereignty

The short answer

Data residency answers "where are the servers?" Data sovereignty answers "whose laws control this data, and who can force the provider to hand it over?"

The two can point to different countries. A vendor can store your data in Frankfurt and still be a company that answers to the laws of the country where it is based.

Data residency

• What it is: a commitment, or a setting, that keeps certain data in a chosen region.
• Who it binds: the vendor, through its contract, DPA or product settings.
• Typical content: a list of regions, a list of data that is covered, and a list of data that is not.

The scope is often narrower than buyers expect. Atlassian's data residency page, for example, lets admins pin in-scope data such as Jira and Confluence content to regions including the EU, the UK and the USA. It also lists data that cannot be pinned, such as user account information, audit log events, app analytics and data in transit.

Data sovereignty

• What it is: the idea that data is subject to the laws of a country, and that a country's authorities can make demands on data that falls under its law.
• Who it binds: it depends on the law. A privacy law can reach data because of the people it is about or the company handling it, not just the server location.
• Example from GDPR: under Article 3(2), GDPR applies to companies outside the EU that offer goods or services to people in the EU or monitor their behavior there. Where the data sits does not change that.
• Moving data across borders: GDPR Article 44 allows transfers outside the EU only when its conditions are met, including for onward transfers.

Government demands are part of sovereignty. The Atlassian DPA (section 5.3) is one example of how a vendor handles this: it says Atlassian "will promptly notify Customer of any valid, enforceable legal process," unless the law prohibits that. See government data requests.

Which one applies to you

Ask both questions about any vendor that holds sensitive data.

1. Where is the data stored? Ask for the exact regions and whether you can choose them.
2. Which data is covered? Backups, logs, support tickets and analytics may sit outside the residency promise.
3. Who can access it from where? Support staff and subprocessors in other countries may still reach the data. Check the subprocessor list for locations.
4. Which laws apply to the vendor? Look at where the vendor and its parent company are based, and at its DPA clause on government requests.
5. What is the transfer route? If data leaves the EU, look for SCCs or the Data Privacy Framework in the DPA. See SCCs vs DPF.

Residency helps with sovereignty, but it does not settle it. If a customer asks you to keep their data in the EU, read your vendors' residency scope before you promise it, and put any limits in writing.

Example

Venpo flagged a change where Stripe added Microsoft Azure and Snowflake as cloud subprocessors. New cloud subprocessors are a moment to ask both questions: in which regions will they hold data, and which companies and laws now stand between you and that data.

For example, imagine your support platform offers EU data residency. Its subprocessor list shows a US-based AI provider that reads ticket text to draft replies. The tickets are stored in the EU, but the AI feature may send their content elsewhere, so you would ask where that processing happens and under what transfer route.

How Venpo helps

Venpo monitors your vendors' subprocessor lists, DPAs and privacy policies, and emails a plain-English alert when a new subprocessor, location or transfer clause appears. Each vendor's change history shows what its residency and transfer wording said before.