Five questions that separate genuine sovereignty from a region setting

Cloud location is important, but it is not sovereignty. A region marker tells you where a provider intends to process or store particular data. It does not, by itself, tell you which law can reach the provider, who can operate the service, where privileged instructions are executed, who can recover encryption keys, or whether the customer can leave on workable terms.

Sovereignty is better understood as the ability of an organisation or nation to make and enforce decisions about its data, technology and operations without an unacceptable external dependency. It is not an absolute state. It is a risk position that varies by workload, threat, classification, sector and mission consequence.

1. Which jurisdictions can reach the service?

Start with the complete legal and corporate chain, not the address of the data centre. The contracting entity, parent company, subcontractors, support organisations and technology licensors may sit under different legal regimes. A locally incorporated supplier may still depend on a foreign parent for software, updates, finance or operational authority. Conversely, an international supplier can sometimes build strong local controls. The point is to test the arrangement, not the flag on the website.

The analysis should identify applicable law, routes for lawful access, conflict-of-law scenarios, insolvency exposure, export controls and the contractual response to government demands. For higher-consequence workloads, counsel should test realistic scenarios rather than merely list statutes.

• Which entity contracts with us, and who ultimately owns or controls it?
• Which jurisdictions apply to the provider, its parent, material subcontractors and support chain?
• Can a foreign authority compel access, secrecy, service restriction or transfer? What would the provider do?
• Which functions rely on licences, updates or approvals that could be withdrawn?

2. Who controls the control plane?

The control plane is the machinery used to create, configure, monitor and administer the service. If data sits in the UK but administrators, orchestration services, telemetry, software repositories or global support systems remain outside the customer’s effective control, the service may be resident without being operationally sovereign.

Map the management path end to end: identity, privileged access, orchestration, software supply chain, monitoring, backup, recovery, billing and support. Ask what still works if international connectivity is lost or the parent service withdraws cooperation. Sovereignty becomes real when local operators have the authority, tooling, knowledge and supply chain required to sustain the agreed mission.

• Where are management services and administrative logs processed?
• Can global engineering or support staff change the platform, directly or through automation?
• Can the service be patched, recovered and safely operated during isolation from global dependencies?
• Who can suspend tenants, revoke accounts, alter policy or push software?

3. Who are the people behind privileged access?

A sovereign operating model needs more than local help-desk coverage. It needs explicit control over who can exercise privilege, from where, under whose employment and vetting, using which devices and approval paths. Follow-the-sun support can be valuable, but it should not be presented as sovereign if sensitive actions can move outside the defined personnel boundary.

The strongest patterns combine named roles, least privilege, just-in-time elevation, separation of duties, approved access locations, session recording and locally accountable decision-makers. They also address the harder question: whether local personnel possess enough engineering depth to operate and recover the service without an undeclared dependency on overseas experts.

• Are all privileged roles identified, including vendor engineers and automated service identities?
• What nationality, residency, clearance, employment and location constraints apply?
• Can any support route bypass local approval, recording or monitoring?
• Is critical knowledge genuinely held in-country, or merely fronted by an in-country team?

4. Who controls the keys - and the ability to use them?

Customer-managed encryption keys are valuable, but the phrase can conceal important details. A provider may host the key service, retain recovery material, control the code that requests decryption or hold privileged access to the plaintext after decryption. Key ownership is meaningful only when key generation, storage, use, backup, rotation, revocation and destruction form a coherent control boundary.

For the most sensitive use cases, consider whether keys are held in customer-controlled hardware security modules; whether quorum or split knowledge is required; whether the provider can alter the workload or policy to obtain plaintext; and how keys are recovered without creating a universal override. The desired result is cryptographic control tied to operational governance, not simply a checkbox labelled “bring your own key”.

• Who generates, stores, backs up, rotates, revokes and destroys each class of key?
• Can the provider or a subcontractor decrypt data, change the code around it, or compel the key service to act?
• What happens to availability if the external key service, network or authority is unavailable?
• Can the customer independently prove destruction or denial of access?

5. Can we leave - in time, at known cost, with a working service?

Exit is where many sovereignty claims fail. Contractual ownership of data is not the same as practical portability. A credible exit position covers data, metadata, identities, configurations, automation, logs, security history, keys, software licences and the knowledge needed to rebuild operations elsewhere.

The exit plan should be exercised before it is needed. Measure extraction time and egress cost; test format compatibility; rebuild a representative service; validate deletion; and identify functions that cannot be moved without redesign. For critical services, include a continuity route for supplier failure, geopolitical restriction, prolonged disconnection and hostile withdrawal - not just orderly contract expiry.

• What must be extracted besides primary data?
• How long would exit take at realistic bandwidth and scale, and what would it cost?
• Which proprietary services create the greatest rebuild burden?
• When was the exit plan last tested, and what evidence was retained?

A practical sovereignty scorecard

About TIS Global

TIS Global helps organisations design, assure and deliver secure digital transformation in complex and regulated environments. We bring together strategy, enterprise architecture, cyber security, cloud and operational delivery to turn policy into services that work in the real world.

References and further reading

[1] Ministry of Defence, “Secure by Design - a new way to manage cyber risk in capabilities” (30 May 2023).

[2] Ministry of Defence, “Secure by Design: User-centred guidance on Digital MOD.UK” (10 February 2025).

[3] Ministry of Defence, “Secure by Design: Two Years of Building a More Resilient MOD” (13 August 2025).

[4] National Cyber Security Centre, “Zero Trust” collection, reviewed 16 January 2026.

[5] National Cyber Security Centre, “Secure connectivity principles for operational technology (OT)”.

[6] National Cyber Security Centre, “Cyber Assessment Framework”.

© TIS Global 2026 | These papers provide general guidance and does not replace legal, safety or system-specific assurance advice.

Download all four briefings (PDF)