Interview. A regulator asks you to demonstrate that a specific customer payment processed on 14 March could not have been handled outside the UK. Walk me through what you would show, and what you would have had to build beforehand.

What the interviewer is testing

Whether you can distinguish a claim from evidence. Most organisations can describe a residency design; far fewer can demonstrate it for one transaction on one date. The question is deliberately specific because specificity is where architecture either produces evidence or does not.

The clarifying questions that change the answer

• What does "handled" include? Processing, storage, backups, logs, support access, a third party's fraud-scoring call, a disaster-recovery replica. The regulator's scope is usually broader than the team's assumption, and the answer must state the scope it covers.
• Is the question about location or about jurisdiction? Data in a UK region operated by a company subject to foreign legal process is a different claim from data nobody outside the UK can compel. Both may be in scope and they need different evidence.
• What date range of configuration applies? The evidence is about the system as it was on 14 March, not as it is today.

A strong answer's arc

The evidence has four layers, and the point is that each is a record rather than an assertion.

1. Deployment evidence. Infrastructure-as-code at the commit that was live on 14 March, showing region constraints, plus the deployment record proving that commit was running. A current console screenshot proves nothing about March.
2. Preventive controls that were active. Organisation-level policies denying resource creation outside permitted regions, and egress controls limiting destinations. These are stronger than detective evidence because they make the alternative impossible rather than merely unobserved.
3. Data-flow inventory for that payment's path, naming every destination including the ones people forget: the log aggregator, the error tracker, the analytics pipeline, the fraud vendor, the backup target, the support console. Each destination is a separate residency claim and the one that fails is always on this list rather than in the primary database.
4. Access evidence. Who accessed systems holding that payment, from where, with the authentication records and the approval trail for any break-glass access. This is the layer most often missing, because access is logged per system rather than mapped to a transaction.

Then the honest part: say which layer is weakest and what compensates for it. A regulator has seen perfect-sounding answers before and tends to trust the one that names its own gap.

Common weak answers

• "Our data is in the UK region." A statement about intent and configuration today, not evidence about a date.
• "We have a policy." A policy is a control objective. The regulator asks for the control and the evidence it operated.
• "We can query the audit log." Only if the log retains March and can be filtered to a transaction, which usually requires a correlation identifier propagated across every system, including the vendors.

What a strong answer adds

The staff-level layer is designing for provability rather than for compliance. Concretely: propagate a transaction correlation identifier everywhere, including into third-party calls, so access and processing can be joined to a payment rather than to a timeframe; keep configuration history as an auditable artefact; prefer preventive controls because they produce evidence by construction; and maintain the data-flow inventory as a living artefact rather than a diagram made for an audit.

The second addition is organisational: the answer takes days rather than weeks only if someone owns the evidence pipeline. If no team owns "can we prove this", the answer is always weeks, and the cost of that is not the effort but the supervisory impression it leaves.