Data residency: why where your SaaS keeps data still matters

"Our data is stored in the EU" is the most common half-answer in software sales. It is usually true, usually offered in good faith, and usually the answer to only one of the three questions a buyer is actually asking.

Three things people mean by residency

1. Where the data sits at rest. Which region the primary database and the backups live in. This is the question vendors answer.
2. Who can reach it, and from where. Support engineers, on-call staff, sub-processors, an offshore development team debugging a ticket with production access. A record stored in Frankfurt and read from outside the EEA has been transferred, whatever the marketing page says.
3. Which legal system can compel disclosure. Determined by the corporate ownership and where the entity is established, not by the location of the disk. A US-owned provider storing data in Ireland is still a US-owned provider.

A vendor can be entirely honest about the first and still leave you exposed on the second and third. The point is not that this is scandalous — it is that you should know which of the three you have bought.

It is not only a legal question

• Customer contracts flow downhill. If you sell to a bank, a hospital or a public body, their requirements arrive in your contract, and you then have to meet them with your own suppliers.
• Tenders make it binary. Public-sector procurement in Poland and elsewhere routinely states EU storage as a hard requirement. A "mostly EU" answer loses the bid.
• Regulated sectors have their own rules. Financial services have specific expectations around cloud outsourcing that sit on top of the GDPR, and NIS2 has widened the set of companies with formal supply-chain obligations.
• Latency is real, if the tool is used interactively all day by people in one region.

Five questions worth asking

1. Which region is my tenant in, and can I choose it at signup or only on an enterprise plan?
2. Where are backups and disaster-recovery copies held? These often live in a different region from the primary.
3. From which countries can staff access production data, and under what controls? Ask for the answer in writing.
4. Which sub-processors touch the data, and where are they? Cross-check the published list against the answer to question three.
5. If data does leave the EEA, what is the transfer mechanism and is there a transfer impact assessment I can rely on?

The seven-question version of this conversation, covering the data processing agreement and deletion, is in our GDPR questions for SaaS vendors.

What the answers look like in practice

We record data residency as a structured field on every product, so a shortlist can be filtered on it before anyone opens a sales conversation. The patterns fall into four shapes.

EU-stored platforms

Brevo and GetResponse are both recorded in our catalogue with EU data storage, which makes the first question easy and moves the conversation straight to access and sub-processors.

US-stored platforms

Mailchimp and ClickUp are listed with US residency. That is not a disqualification and for a lot of workloads it is entirely reasonable. It does mean the transfer basis has to be documented rather than assumed, and it means the answer to a tender question is "no", not "it depends".

Self-hosted

Metabase can be run on your own infrastructure, which moves the residency question rather than answering it: now you own the region, the backups, the patching and the access controls. That is a real answer if you have someone to own it, and a worse answer if you do not.

Tenant-scoped

With the large platform vendors, the region is often a property of your tenant rather than of the product. Power BI sits inside that model, so the useful question is not "where does this vendor store data" but "which region is our tenant in, and can it be moved". Ask your own administrator before you ask the vendor.

When US hosting is fine

Often. A marketing newsletter list, a task tracker with no personal data beyond staff names, a screen-recording tool used internally — for these the risk of a transfer is low and the mechanism is well trodden. The failure mode is not choosing a US-hosted tool. It is discovering, during a customer security review, that you did not know you had.

Residency is not a virtue. It is a constraint you either have or do not, and the expensive mistake is not knowing which.

What to write down

• The region, per tool, in the same place you keep your processing records.
• The transfer mechanism where one applies, with the date you checked it.
• Who can access production, from where.
• What you would have to answer if a customer asked tomorrow.

For the underlying guidance, the European Data Protection Board is the source supervisory authorities apply; in Poland, UODO publishes its own material for controllers.