"UK hosted" is not the same answer as "UK resident." The two phrases sound interchangeable in a vendor's sales deck, and most buyers treat them as such. They are not the same commitment, and the gap between them has a name: the US CLOUD Act.
A vendor can run a UK data centre and still be reachable by US law enforcement under the CLOUD Act, if the company itself is US-owned. The obligation follows the company, not the server rack. For any organisation evaluating a compliance SaaS vendor — and especially for public sector buyers handling citizen data — this distinction is the difference between a reassuring sentence and a contractual commitment that actually holds.
What the CLOUD Act actually does
The Clarifying Lawful Overseas Use of Data Act, passed by the US in 2018, allows US law enforcement to compel a company under US jurisdiction to produce data it controls, regardless of where that data is physically stored. The Act was written specifically to close a gap that existed before it: previously, a US company could argue that data stored on a server outside the US was beyond the reach of a US warrant. The CLOUD Act removed that argument.
What this means in practice: if a vendor's parent company is incorporated in the United States, or the vendor itself is a US entity, the location of its servers does not change its legal obligation to comply with a US data request. A UK data centre operated by a US-owned company is still, in the relevant legal sense, US-controlled data.
This is not a hypothetical, and it is not new. It is established US law that any organisation handling sensitive data through a vendor with US ownership should already have factored into procurement decisions.
Why "UK hosted" survives as a sales phrase
Most vendors are not being deliberately misleading when they say "UK hosted" — the phrase is technically true and it answers a question buyers commonly ask. But it answers the wrong question, or rather, an incomplete one. "Where are your servers" and "who can legally compel access to my data" are different questions with different answers, and a vendor can give a fully honest answer to the first while leaving the second unaddressed entirely.
The asymmetry favours the vendor, not because of bad faith but because of how procurement conversations are usually structured. Buyers ask about hosting location because it is the question they know to ask. Vendors answer it because it is the question they were asked. Neither party necessarily realises that the answer given does not cover the risk the buyer actually cares about.
The structural point. Data sovereignty is a function of corporate jurisdiction and ownership, not physical server location. A buyer who only confirms hosting location has confirmed one input into the picture, not the picture itself.
The four questions worth asking any vendor
These are not exotic or unusually demanding questions. They are the standard due diligence a careful buyer should apply to any vendor handling regulated or sensitive data, and a vendor with a genuinely strong data residency posture should be able to answer all four specifically, in writing.
Primary data storage is only one part of the picture. Backups, disaster recovery replication, and any remote access used by the vendor's own support staff can all involve data leaving the primary jurisdiction, even when the production database itself never does. A vendor should be able to confirm the location of all of these, not just the primary hosting environment.
This covers the vendor's own staff with production access, any subcontractors or subprocessors involved in delivering the service, and the jurisdictions those parties operate in. UK GDPR requires data processors to disclose subprocessors to controllers — a vendor who cannot produce this list promptly has not organised their own data governance clearly enough to be confident about it themselves.
Data residency commitments are often described for the normal operating state and left unaddressed for the failure state. If the primary UK region goes down, does failover route to another UK region, or does it route to whatever region is next available — potentially outside the UK or outside any jurisdiction the contract specifically covers? This is the scenario where a residency commitment is most likely to quietly lapse, and the one buyers are least likely to ask about in advance.
An access log that only exists inside the vendor's own system, viewable only through their own interface, is not independently verifiable. A buyer evaluating a vendor's data governance should be able to export audit logs in a standard format and review them outside the vendor's own tooling — particularly relevant for any organisation that may need to produce that evidence to a regulator or auditor of their own.
What a credible answer looks like versus what does not hold up
The distinction that matters is whether the vendor's answer is documentable. "We take data security seriously" is not an answer to any of the four questions above — it is a sentence that sounds responsive without committing to anything specific. A credible vendor answer names the specific region, names the specific subprocessors and their jurisdictions, states explicitly what happens during failover, and confirms audit log export in writing, ideally as a schedule to the contract rather than a verbal assurance during a sales call.
The test is simple: could this answer be put into a contract clause as written, or does it need to be translated into something more specific before it would hold up? If a vendor's answer would need substantial rewording to become a binding commitment, it was reassurance, not commitment.
This applies to us too
Tiri.Tese is a UK-incorporated company (Company No. 16602529), registered at 85 Great Portland Street, London. We are not raising this distinction to position against a specific competitor — we are raising it because it is a real gap in how most vendor evaluations are conducted, and because it is a fair question for any buyer to put to us directly.
Any organisation evaluating us as a supplier is welcome to ask all four questions above and expect a specific, documentable answer for each one. That is the standard this article describes, and it is the standard we hold ourselves to.