UK Data Residency Claims: The Procurement Questions That Actually Get Answers
Photo: Humphrey Bolton , CC BY-SA 2.0, via Wikimedia Commons
UK data residency has become a procurement badge. It appears in sales decks, security pages and tender responses, usually next to a Union Jack and a line about data being 'hosted in the UK'. For a UK buyer, that sounds reassuring. It is also where a lot of careful questions stop.
The problem is that data residency is not a single fact. It is a property of a system. Your data may sit in a UK primary data centre and still be accessed by support staff in another country, backed up to another region, analysed by a sub-processor, or copied into a ticket system. The badge often describes the front door, not the whole building.
The claim and the gap
A vendor can legitimately say it has UK data residency because the primary database is in London. That does not tell you where backups live, where disaster recovery runs, where logs are stored, or where the engineer who answers your support ticket is sitting. Under UK GDPR, remote access from outside the UK is a restricted transfer. It needs a transfer mechanism, such as the UK International Data Transfer Agreement, the UK Addendum to the EU Standard Contractual Clauses, or an adequacy regulation. 'We are UK GDPR compliant' is not the same as naming the mechanism.
This is not a legal theory article. It is a procurement problem. You do not need to become a data protection lawyer to ask better questions. You need to make the vendor show the map.
Four questions that get past the brochure
Start with the sub-processor list. Ask for the full list, not the headline hosting provider. It should include the service each sub-processor provides, the countries where it operates and the categories of data it can access. Ask how often the list is updated, how you are notified of changes, and whether you can object. A list that has not changed in three years is either suspiciously stable or out of date.
Next, ask for the transfer mechanism for every location outside the UK. Not a policy statement. The actual mechanism: UK IDTA, UK Addendum, adequacy regulations, or a documented exception. If the vendor cannot name it, that is useful information.
Then ask about support access. Where do the engineers sit? Is access just-in-time, approved and logged? Can you restrict access to UK-based staff, or is follow-the-sun support a euphemism for overnight access from another continent? Ask about escalation paths too. The first-line agent may be in one country and the engineer with database access in another.
Finally, ask for deletion evidence. What happens at exit? Is data deleted from the primary system, backups, logs, analytics and sub-processors? On what timeline? What evidence do you get: a certificate, an audit log, a ticket? Backups are the usual gap. A vendor may delete your live data promptly and keep encrypted backups for months.
A red-flag table for procurement
| What you hear | What it can hide | What to ask for |
|---|---|---|
| 'UK data residency' | Primary data centre only; backups or support elsewhere | Data flow map showing storage, backup, disaster recovery and support locations |
| 'We use UK sub-processors' | Overseas subcontractors or group companies | Full sub-processor list with countries and roles |
| 'Follow-the-sun support' | Access from the US, Asia or a shared service centre | Support access policy, engineer locations and transfer mechanism |
| 'We delete on termination' | Backups retained for 90 days; logs kept longer | Deletion schedule, backup handling and a deletion certificate |
| 'We are UK GDPR compliant' | No named transfer mechanism | IDTA or UK Addendum reference and signatory |
| 'Data never leaves the UK' | Analytics, error monitoring or email support tools | List of every processor, including internal tools |
The table is deliberately blunt. Use it in a procurement meeting and watch which rows the vendor can answer without a follow-up call.
What good looks like
A good vendor will not claim zero risk. It will show you the system. That means a data map, a current sub-processor list, a named transfer mechanism, access controls with logs, and a deletion process that covers backups. It will also tell you what it cannot control, such as a parent company's global support model.
Ask for the security annex or the relevant schedule of the data processing agreement. Check that the sub-processor list is incorporated by reference and that changes trigger notice. If the vendor uses a UK data centre but a US parent for support, the transfer mechanism should be in the contract, not in a sales email.
Don't ask for zero risk; ask for evidence
The UK data residency badge is not a seal of approval. It is a starting point. For small UK teams without a legal department, the practical move is a one-page questionnaire: where data is stored, who can access it, which sub-processors are involved, what transfer mechanism applies and how deletion is proved. If a vendor cannot answer those questions, that is the answer.
Procurement is not about finding a perfect vendor. It is about knowing where the gaps are and deciding whether you can live with them. A data residency claim that stops at the primary data centre is not a lie, but it is not the whole story either.
