"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 or US-controlled. 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 provider subject to US jurisdiction to produce data in its possession, custody or control, regardless of where that data is physically stored. The Act was written 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, data that company controls.
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 an incomplete question. "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 strong data residency position 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. Under UK GDPR Article 28, a processor cannot engage a subprocessor without the controller's written authorisation, and must tell the controller about any intended changes. A vendor who cannot produce its subprocessor list promptly has not organised its own data governance clearly enough to be confident about it.
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 to whatever region is next available, potentially outside the UK or outside any jurisdiction the contract 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. This matters particularly for any organisation that may need to produce that evidence to a regulator or auditor of its 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). UK incorporation answers one part of the picture, not all of it. Like almost every software supplier, we rely on infrastructure and service providers, and where each of those is incorporated is exactly the kind of thing this article says you should ask about.
So ask us. Any organisation evaluating us as a supplier can put all four questions above to us, along with the country of incorporation of every subprocessor we use, and we will answer in writing. You can then judge the exposure yourself rather than relying on a phrase from us. The same applies when we deploy a third-party platform for you: we will tell you who that vendor is, where it is incorporated, and where your data will sit.