Cloud sovereignty: separate the location promise from the control you need

Google Cloud Storage’s location documentation makes a useful distinction for a UK buyer: object data placed in its EU multi-region is not stored in London or Zürich. “European”, “EU” and “UK” are not interchangeable purchasing requirements, even before the discussion reaches sovereignty.

For a cloud platform lead, the practical task is to turn those labels into requirements that an architecture, contract and operating team can meet. Data residency describes location. Sovereignty discussions also raise questions about applicable authority, access and dependence on the supplier. Operational control concerns what your organisation can actually permit, prevent and sustain. Put those questions alongside one another rather than asking a regional setting to answer them all.

Location needs an object and a boundary

The Google Cloud Storage commitment concerns the object data in the specified bucket location. It is useful evidence for that component. It does not, by itself, describe every dataset and service in an application that uses the bucket.

Separate the main records from backups, exported files, audit logs, support attachments and any derived datasets. For each, establish the storage and processing arrangement that matters to the requirement. Ask whether a location choice is a contractual commitment, a configuration option or simply the deployment’s present state.

This changes the review of a seemingly straightforward proposal. In a hypothetical customer portal, the records may sit in an approved region while a support workflow copies diagnostic files into a different service. The architecture can satisfy the database-location requirement and still leave the support-data question unanswered.

Make the requirement narrow enough to verify and broad enough to cover the business concern. “Customer records and their recovery copies remain in the agreed locations” can be tested against a data flow and service terms. “Everything is sovereign” gives the project no clear completion condition.

For UK personal data, examine the receiving organisation

The ICO’s restricted-transfer guidance uses a three-step test: whether the processing is subject to UK GDPR, whether the organisation initiates a transfer to an organisation outside the UK, and whether the receiver is a separate legal entity. The guidance includes making UK-held personal information remotely accessible to a separate overseas organisation.

Its cloud guidance therefore asks buyers to identify the specific contracting entity and examine the provider’s transfers to other processors. Server geography alone does not settle that assessment. Nor does every access from abroad have the same status: the ICO distinguishes activity within the same legal entity from transfers to a separate organisation.

Give the privacy and legal reviewers the actual entities, contractual relationships and access paths. Ask them to determine which transfer requirements apply and how they are met. This is a UK personal-data question; it does not resolve every sector-specific requirement or every jurisdiction’s rules. Keeping that scope explicit produces a useful decision instead of a sweeping claim that local storage makes an arrangement lawful or unlawful.

Control is a feature with conditions

A supplier may offer a mechanism for approving administrative access. Examine the supported services, the access it covers and the exceptions. Otherwise the organisation can mistake a valuable control for an unconditional veto.

Google Cloud Access Approval lets customers authorise covered Google-personnel access to Customer Data in enrolled, supported services. It also inherits Access Transparency exclusions. Google documents automatic approval for some time-sensitive outages, while stating that this is disabled for workloads using EU Data Boundary with Access Justifications or Sovereign Controls by Partners.

Those differences belong in the service decision. Google also warns that support response time increases while its team waits for approval. A tighter access arrangement therefore needs an available approver and a workable incident procedure, as well as a setting in a console.

Apply the same scrutiny to key-control claims. Which data does the key protect? Who can change its policy, approve its use or recover it? What becomes unavailable if the key service cannot be reached? Request evidence for the proposed implementation. The phrase “customer-managed key” is a starting point for these questions, not a complete description of who can exercise control.

Choose the dependency you can sustain

Operational independence needs a separate discussion with the service owner. Can the team investigate an incident, restore essential data and change administrators if the normal support route is unavailable? Which identity, key-management and management-plane services must keep working for those actions?

Compare the extra control with its cost in staffing, recovery complexity and available features. A configuration that relies on round-the-clock customer approvals may suit an organisation with that capability. It may leave another waiting for an unreachable decision-maker during an outage. The requirement must fit the operating model that will exist after procurement.

Bring the findings back to three purchasing decisions: the required locations and data scope; the legal and contractual arrangement; and the controls the team will operate. Ask the supplier to answer each with service-specific evidence and identify what changes if a feature, region or support model changes.

For AI workloads, continue that examination at the individual feature’s data handling and control boundary. An assurance about the provider is most useful when it can be traced to the exact service your organisation will use.