Why “UK hosted” isn’t the same as UK data residency — and what your DPIA should actually check.

Procurement teams increasingly ask vendors whether their platform is “UK hosted.” The vendor says yes. Everyone moves on. But the phrase carries almost no legal weight, and the gap between a UK head office and genuinely UK-resident processing is where most data-sovereignty problems start.

The three claims that get conflated

When a vendor tells you they are “UK based,” any of three very different statements might actually be true, and each has a different data-protection consequence.

Claim 1: The company is registered in the UK. The legal entity has a Companies House number, pays UK corporation tax, and answers to UK courts. This tells you who you can sue. It tells you nothing about where customer data is processed or stored.

Claim 2: The platform is hosted in the UK. The primary production infrastructure runs in a UK cloud region — typically AWS London (eu-west-2), Azure UK South, or Google Cloud London. This means the database lives on UK soil at rest. It does not mean every processing path stays there.

Claim 3: Customer data is UK-resident end to end. Every processor that touches personal data — the application servers, the database, the AI transcription service, the logging pipeline, the analytics tool, the email delivery service, the backup target — is located in the UK region. This is genuine data residency, and it is much rarer than the phrase “UK hosted” would suggest.

Why the distinction matters for your DPIA

Under UK GDPR, a Data Protection Impact Assessment is required whenever processing is likely to result in high risk to data subjects. In practice, that includes almost every contact-centre, AI, or customer-data platform your procurement team will evaluate. A DPIA is not a one-time checkbox; it is a living document that has to describe, accurately, where personal data actually goes.

If you record in your DPIA that a platform is “UK hosted,” and then the platform silently ships transcripts to a US-based speech-to-text service, you have two problems. The first is that the processing is now an international transfer, which needs a lawful transfer mechanism — either an adequacy decision, appropriate safeguards such as the UK International Data Transfer Agreement, or a documented derogation. The second, harder problem is that your DPIA is wrong, which means your internal record of processing activities is wrong, which means the regulator can reasonably conclude you did not know what your own platform was doing.

The ICO has been explicit about this. Processors you did not know existed are still processors. The burden of mapping them sits with you as the controller, not with the vendor’s sales team.

Processors you did not know existed are still processors. The burden of mapping them sits with you as the controller.

The seven questions to ask before signing

These are the questions we would put to a prospective AI or contact-centre vendor if our own data sovereignty depended on the answers. None of them is unreasonable. If a vendor cannot answer them in writing, that itself is the answer.

• Where is the primary production database? Specify the cloud provider, the region code, and the availability zones. “Europe” is not an answer; “AWS eu-west-2” is.
• Where is the backup target? Backups are processing. If production is UK but backups replicate to a US region for disaster recovery, you have US processing.
• What is the complete sub-processor list, with region for each? This should be a specific list, not a category. “We use a speech-to-text provider” is not acceptable; “We use Deepgram deployed in London” is.
• Does support staff access production data, and from where? Remote support from a country without adequacy is a transfer, even if the data never leaves the UK server.
• What happens to the data during an AI inference call? Many AI platforms forward prompts and conversation context to a model provider. Confirm the model endpoint region, and confirm whether the provider retains the prompt for training.
• Where are logs and telemetry processed? Observability platforms like Datadog, New Relic, and Sentry have default US regions. A request header containing a phone number in a Datadog log is still personal data.
• What is the contractual commitment to UK residency? A written commitment in the Data Processing Addendum is worth far more than a paragraph on the marketing site. Ask for the DPA before you ask for a quote.

Where this most often breaks in practice

In every procurement audit we have supported, the failure point is rarely the core product. It is almost always one of three categories: AI inference, observability, or email delivery. A vendor will correctly deploy their application and database in the UK, then plug in an off-the-shelf speech-to-text, logging, or transactional email service without realising that the defaults for all three are in the US.

This is not necessarily disqualifying. UK GDPR allows international transfers with proper safeguards. But the safeguards have to be in place, documented, and reflected in the DPIA. The difference between a vendor who has done this properly and one who has not is the difference between a smooth audit and a breach notification.

What “genuinely UK-resident” looks like

A platform that passes a serious residency check will typically have the following characteristics. The application runs in a UK cloud region with no cross-region failover outside the UK. The database is deployed with single-region durability, backups in the same region, and a documented DR runbook that stays inside the UK. Every sub-processor is either UK-hosted or has been formally approved with an appropriate transfer mechanism listed in the DPA. The AI components run against a UK-deployed model endpoint, not a US inference API. Logs, errors, and metrics are ingested by an observability stack configured to a UK region.

This is an operational posture, not a marketing claim. It costs the vendor money — UK regions are generally more expensive, and UK-deployed versions of AI services are sometimes slower or less feature-complete than their US counterparts. A vendor who has made this investment will usually want to talk about it in detail. A vendor who has not will deflect.

Putting it in the DPIA

When you write the data-flow section of your DPIA, describe what actually happens, not what the vendor says happens. Name the specific processors and regions. Flag any transfer outside the UK explicitly, alongside the transfer mechanism that legitimises it. If you cannot get that information from the vendor, record that too — the absence of an answer is information, and it should change your risk assessment.

This is not legal advice; it is how procurement teams who survive audits tend to operate. If you are working through a vendor assessment right now and the answers feel evasive, trust that instinct. The good vendors are the ones who answer these questions before you ask.