The Residency Illusion: Why One UK Region Is Not a Resilience Strategy

The comfort of a clause

Few procurement documents feel as reassuring as a data-residency guarantee. The supplier confirms that UK data will remain in a UK region. The contract references UK data protection law. The board pack records that sovereignty has been addressed. The tick-box is full.

But residency is not resilience. A service can keep data in a UK region and still fail when that region is unavailable, when the control plane is degraded, when an identity provider is unreachable or when a single supplier's support model cannot respond. The clause describes where data sits. It does not describe whether the business continues.

For UK technology leaders, the distinction matters more than ever. Cloud estates have become concentrated, supplier landscapes have narrowed and regulators are asking harder questions about operational continuity. A residency clause is a starting point, not an assurance.

Sovereignty and resilience are different tests

Sovereignty is a legal and geopolitical question. It concerns where data is stored, who can access it, which laws apply and what control a nation or customer has over the service. Resilience is an operational question. It concerns whether a service meets its impact tolerances during disruption, how quickly it recovers and what dependencies must be available for recovery to work.

A UK region can be sovereign and still be a single point of failure. A supplier can be UK-domiciled and still depend on a control plane, identity service or support team outside the UK. A contract can promise data residency and still permit failover to a region the customer did not expect. These are not contradictions. They are different dimensions of risk, and conflating them is how gaps hide.

The dependencies contracts rarely draw

Most cloud contracts describe the primary service. Fewer describe the dependency map. A workload may store data in London while its ability to start, scale or recover depends on a control plane in another jurisdiction. Identity and access management may be centralised in one tenant. Key management may be regional but administered globally. DNS, logging, backup catalogues and software supply chains may each introduce a dependency that is invisible in the residency clause.

Supplier concentration compounds the problem. An organisation may use one hyperscaler for compute, another for identity and a third for security tooling, then discover that all three depend on the same transit provider or the same software component. Concentration is not only a matter of counting suppliers. It is a matter of mapping shared failure modes.

What UK regulators and boards are starting to ask

In financial services, the operational resilience regime has pushed firms to define important business services, set impact tolerances and evidence their ability to remain within them during severe but plausible scenarios. Critical third-party oversight has sharpened the questions asked of cloud suppliers. Outside financial services, NCSC guidance and ICO expectations continue to raise the bar on continuity, incident response and supplier assurance.

The board question is not 'is our data in the UK?' It is 'if our primary region, control plane or supplier fails, which business services stop, how long can we tolerate that and what have we tested?' That is a resilience question, and it requires evidence rather than a clause.

A pre-disruption checklist for UK leaders

• Map where data resides and where control planes, identity providers, key management and support functions operate. Residency of data at rest is not the same as operational locality.
• Test loss of the primary UK region, not just loss of a single availability zone. Confirm which services fail automatically and which require manual intervention.
• Test loss of the control plane. Can you provision, scale, recover or revoke access if the management layer is unavailable?
• Identify egress paths. If the primary network path fails, can traffic leave through an alternative provider without re-architecting the estate?
• Quantify supplier concentration. Count shared dependencies, not just contracts. Include transit providers, identity services and software components.
• Review contract terms for failover obligations, recovery objectives, exit assistance and subcontractor transparency. A residency clause should not be the only operational commitment.
• Rehearse recovery without the primary supplier's tooling. If restoration depends on a console or service that is also unavailable, the recovery plan is incomplete.
• Record the evidence. Regulators and boards will want to see test results, remediation owners and dates, not just a statement of intent.

Contract questions that expose the gap

Ask which region will host failover capacity, whether failover is automatic or manual, and what recovery time and recovery point objectives the supplier actually commits to. Ask where the control plane runs and what happens to existing workloads if it is degraded. Ask how support is delivered and whether UK-based support is guaranteed during a major incident. Ask what egress charges apply during failover and exit. Ask which subcontractors are involved and how their concentration is managed.

If the answer to any of these questions is 'it depends', treat it as an unresolved risk rather than a procurement detail. The most dangerous contract is the one that answers the residency question clearly and leaves every operational question vague.

The resilience test that matters

A useful exercise is to pick one important business service and trace every dependency required to keep it running. Then remove the primary region, the primary control plane and the primary supplier's support channel in a tabletop or live game day. The gaps that appear are the real resilience strategy. The residency clause will not close them.

Sovereignty may be a requirement. Resilience is a capability. UK leaders should pursue both, but they should not mistake one for the other. A UK region is a location, not a strategy.