Where Your Data Actually Sleeps: Stress-Testing a ‘UK Hosted’ Claim

Most hosting conversations follow the same script. Someone points at a badge on a slide, says “UK data centre”, and the room moves on to pricing. Then, a few months after go-live, an engineer spots that the analytics SDK is calling a US endpoint and the support console sits in Frankfurt — and suddenly the paperwork everyone skipped becomes the only thing anyone wants to talk about.

That’s not an unusual story in 2026. It’s the predictable result of a vague promise meeting a complicated stack.

A badge is not a location

Data residency isn’t one fact. It’s a chain: where the primary database sits, where the read replicas live, who can reach the data and from where, where the backups land, and which third-party services touch it on the way through. “Hosted in the UK” usually describes exactly one link in that chain — the primary compute — and quietly ignores everything else.

That isn’t necessarily dishonest. Plenty of suppliers mean it sincerely and genuinely don’t know about the leaky bits, because those bits arrived as a feature rather than a decision. But sincerity isn’t evidence, and your obligations under UK GDPR don’t care about good intentions.

Four places residency quietly leaks

Subprocessors

Ask for the list in writing, with processing locations, not just company names. Any vendor processing on your behalf has its own vendors — payments, email delivery, logging, monitoring, the AI feature someone bolted on last quarter. Each of those is a subprocessor. You need to know who they are, where they process, and what your objection rights look like. “We update our website” is not an objection right.

Support and admin access

A UK data centre staffed by a support team in Manila is still a UK data centre — but it’s also an overseas access route. Remote access to production data counts as processing. Ask who can see what, from where, whether access is just-in-time and logged, and whether staff work from managed devices. This is the leak buyers miss most often, and the one a serious auditor asks about first.

Backups and disaster recovery

Primary region in the UK, backup region in Ireland: technically EU, technically covered by UK adequacy, but not what the badge says. Worse is a “global” bucket that nobody can pin to a country. Ask for backup locations, retention windows, key management, and whether a restore has ever actually been tested. An untested backup is a rumour with a retention policy.

Analytics, SDKs and the long tail

Every SDK in the app is a small outbound pipe. Crash reporting, attribution, push, A/B testing — each carries its own hosting posture, and each has its own privacy notice you’ve probably never read. Ask for a data-flow diagram of the app itself, not just the backend. If the diagram doesn’t exist, that absence is itself the answer.

The paperwork worth asking for

Before anyone signs, request:

• A current subprocessor list with processing locations and roles.
• A data-flow or architecture diagram covering the app, backend, backups and support tooling.
• The relevant security certification — ISO 27001 or Cyber Essentials Plus — plus the scope statement, not just the certificate PDF.
• A transfer risk assessment if anything leaves the UK, and the mechanism used (IDTA or the Addendum).
• A summary of their incident notification process and a recent penetration test summary.
• A named data protection contact who actually replies.

None of this is exotic. A supplier who can’t produce it within a week is telling you something genuinely useful, and you should listen.

Clauses that turn a promise into an obligation

Put residency in the contract as an outcome, not a feature. Sensible wording covers named storage locations, a change-control process for subprocessors with notice periods and a real objection right, a commitment to notify you before any new region is used, breach notification timelines that fit your own obligations, and audit or evidence rights — annually at minimum, and on request after an incident.

Then pin down the exit. Where does the data go at termination, in what format, within how many days, and is there a certificate of destruction? Exit clauses are where residency promises usually go to die, and they’re the part nobody reads until it matters.

A half-hour scoring routine

Get three quotes. For each supplier, score the same six things: subprocessor transparency, support access controls, backup location clarity, SDK footprint, quality of evidence, and contract language. Anything scoring “we’ll confirm later” on backups or support access is a flag, not a maybe.

Then ask one awkward question: “If our regulator asked you to prove this tomorrow, what would you show me?” The reply separates the suppliers who’ve done the work from the ones who’ve done the marketing.

Worth saying plainly: this isn’t legal advice. Your DPO or counsel should sign off the transfer position — but they can only do that with evidence in hand, and gathering it is your job, not theirs.

When the answer is ‘mostly UK’

Most stacks are partly elsewhere, and that’s usually fine. UK adequacy regulations, the IDTA and a documented transfer risk assessment exist precisely because global infrastructure is normal. What isn’t fine is a gap between the badge and the reality, because that gap is what turns into an incident report, a contract dispute, or an unpleasant surprise at renewal.

The aim isn’t a perfect UK-only stack. It’s knowing exactly where the lines are, having it in writing, and being able to explain it to someone who isn’t impressed by logos.