Hosted Here, Handled Elsewhere: Auditing the 'UK-Hosted' Claim Before You Sign

The phrase has become almost decorative. Somewhere on the vendor's security page, usually below the certifications carousel, there is a sentence confirming that customer data is stored in the United Kingdom. For many buying teams that sentence has quietly replaced the due diligence it was meant to prompt. It survives procurement scrutiny because it looks like an answer, and because checking it properly requires access and expertise that the evaluation timetable rarely accommodates.

The result is a familiar pattern. A platform is genuinely hosted in a London or Slough facility, but its secondary region sits in Frankfurt. Backups are encrypted at rest but written to a bucket in Ireland. The vendor's support engineers work from a shared service centre outside the UK and hold standing access to production. None of these arrangements is necessarily unacceptable. What matters is whether the buyer knew, priced the risk accordingly, and recorded the position in the contract rather than in a sales deck.

Residency, sovereignty and the gap between them

Data residency is a statement about location. Data sovereignty is a statement about control: who can access the data, under which jurisdiction, subject to which legal process, and with whose permission. A vendor can satisfy the first and fail the second without any contradiction. Procurement teams that treat the two as interchangeable will keep discovering the difference at the worst possible moment.

Under UK GDPR, a transfer to a country outside the UK requires an appropriate safeguard — an adequacy regulation, the International Data Transfer Agreement, or the UK Addendum to the EU Standard Contractual Clauses — together with a transfer risk assessment. The existence of a valid transfer mechanism does not make an undisclosed transfer acceptable to a buyer who was told the data would stay put. It simply means the transfer is lawful. Lawful and expected are separate tests.

The evidence pack: what to request

Ask for documentation, not assurances. A credible vendor should be able to supply the following without a lengthy escalation, and reluctance to produce any single item is itself a finding.

• The current sub-processor list, with locations. Request it as an attachment with a version date, plus a commitment to notify changes in advance. Cross-reference every entry against its processing location, not its registered office.
• An architecture diagram covering primary region, secondary region and backup destination. Ask specifically whether the secondary region is inside the UK. Hyperscaler region pairing frequently places the UK's failover partner in another European country.
• The scope statement of the ISO 27001 certificate. Check that the certification body and the certified scope match the service you are buying, and that the certificate is current. A group-level certificate covering a different entity is a common and quiet mismatch.
• A recent SOC 2 Type II report, or equivalent. Read the exceptions section. Reports are frequently shared with the complementary user entity controls section removed, which is precisely the part that describes what the buyer is expected to do.
• Support and access model documentation. Where do the engineers sit, what tooling do they use, is access just-in-time or standing, and are sessions recorded?
• Encryption and key management detail. Whether keys are held by the vendor, by the customer, or by a third-party service, and in which jurisdiction each of those sits.

Questions that expose an overseas escape route

Documentation has a way of answering the question the vendor wished you had asked. A short verbal session, minuted, closes the gap.

Ask what happens during a declared disaster. Which region takes over, who authorises the failover, and how quickly is the customer told? Ask whether any telemetry, product analytics or AI-assisted support tooling receives customer content — and where that tooling is hosted, since assistive features are often bolted on from a different cloud. Ask whether the vendor's own parent company, or any affiliate, can access the environment for engineering purposes. Ask which third parties receive data for billing, monitoring or incident response.

One question deserves particular weight: if we requested deletion tomorrow, where would every copy be removed from, and how would you evidence it? Vendors who can answer precisely have usually thought about residency properly. Vendors who cannot have usually thought about the marketing page instead.

Contract clauses worth tightening

Residency belongs in the agreement, not in an annex that can be updated unilaterally. Four provisions do most of the work.

First, a defined storage and processing location expressed by reference to named regions or facilities, not to a country in general. Second, a notification obligation covering sub-processor changes and any change of region, with a meaningful objection window and a termination route if the objection is not resolved. Third, a support access clause specifying where remote access originates and requiring customer authorisation for anything beyond routine, logged, just-in-time sessions. Fourth, a survivable exit: data export in a usable format, deletion certification on request, and a defined period for completion.

Change-of-control language also matters here. An acquisition can relocate an engineering function without touching a single server, and the residency warranty should be drafted to survive that event.

Recording the judgement

Not every overseas dependency is a reason to walk away. A vendor with a Frankfurt failover site, documented and contractually disclosed, may be a better buy than one making an unverifiable claim to be entirely UK-contained. The procurement task is to convert a marketing phrase into a recorded position: what was claimed, what was evidenced, what was accepted, and on whose authority.

That record is what an auditor will ask for later, and it is what makes the difference between a decision and an assumption. The residency sticker on the front page is a starting point for the conversation. It has never been the conclusion.