Data Sovereignty and Regional Storage Controls

Enforcing data sovereignty with Google Cloud Organization Policies means using centralized guardrails to allow data storage and processing only inside approved countries or regions. The central control is the resource location restriction (constraints/gcp.resourceLocations), which defines an allowedValues list of permitted multi-regions, regions, and zones. When the policy is attached to an organization, folder, or project, any request to create a location-based resource outside that list is denied before data can be stored there.

1.1How the Resource Location Constraint Blocks Out-of-Boundary Provisioning

The resource location restriction constraint controls where new location-based Google Cloud resources can be created for an organization. An administrator sets constraints/gcp.resourceLocations with an allowedValues list such as in:us-locations plus specific United States regions for a United States boundary, or European regions such as europe-west1 and europe-west4 for a European Union boundary. Once set, no new resources can be created in any other region, multi-region, or location outside the selection, which systematically prevents storage and processing from spilling across geopolitical boundaries.

The constraint applies only to services that support resource locations, and some resources remain out of scope and cannot be restricted. Administrators must therefore check the supported-services list and product location pages to confirm that each planned service, from BigQuery datasets to Cloud Storage (opens in a new tab) buckets to Compute Engine instances, can actually be pinned to the required region. For Apigee (opens in a new tab) provisioning, the constraint governs all location-bearing components created together:

• control plane
• consumer data
• runtime
• endpoint attachment for southbound networking
• analytics

Provisioning fails when the policy and the requested location are incompatible, so the policy acts as a hard deployment gate rather than an alert.

1.2Defining Locality Requirements Before Setting Allowed Values

Locality requirements are the business and regulatory answers that determine what the allowedValues list must contain. The policy cannot be written correctly until architects know where data must rest, whether it may be processed elsewhere, and whether multi-regional or dual-regional services are permitted. Encryption with Cloud External Key Manager and Cloud Key Management Service can in some designs mitigate locality pressure, but only when the compliance regime accepts that mitigation.

Five planning questions drive the policy design:

• Where is data at rest, which dictates eligible services and high availability and disaster recovery options for recovery time and recovery point objectives?
• Can encryption techniques mitigate the locality requirement and allow multi-regional services?
• Can data be processed outside where it rests, or must processing stay in the same region or hybrid footprint?
• Can more than one region be used, which enables multi-region resilience techniques?
• Must access to the application be restricted by identity or network location?

The answers decide whether the policy allows a single region, a set of in-country regions plus the country multi-region value, or a broader jurisdictional boundary such as United States or European Union.

1.3How Policy Inheritance Flows Through Organization, Folder, and Project

Organization Policy enforcement flows from the Organization resource at the apex of the hierarchy down through folders to projects. All resources in projects, such as Compute Engine virtual machines, Pub/Sub topics, Cloud Storage buckets, and Cloud VPN endpoints, inherit the effective policy from their parent folder and organization node. This inheritance gives central visibility and control, so one boundary definition can cover every workload underneath it without per-project configuration.

Assured Workloads (opens in a new tab) packages use this inheritance to automate sovereignty. Creating an Assured Workloads folder with a control package automatically sets the control plane location and the resource location constraint to enforce the regional boundary:

1. Create Assured Workloads folder: Google Cloud administrator creates the folder in the organization and applies a control package, which sets organization policy constraints that enforce regional data boundaries.
2. Provision organization with residency: Service administrator provisions the regionalized organization using the jurisdictional console or regional API endpoint that matches the boundary.
3. Operate inside the boundary: Users create runtime, analytics, and endpoint resources only inside permitted regions, with console region selectors filtered to prevent out-of-boundary choices.

Because folders group related projects, sensitive or regulated data with specific residency needs is placed inside the compliant folder and kept there, while general commercial workloads remain outside it.

1.4Auditing Residency Policies and Adding Defense in Depth

Residency policies require continuous auditing because relaxing them can irreversibly undermine data residency. Documentation for United States and European Union boundaries warns against changing required gcp.resourceLocations values to be less restrictive, since data created or stored outside the boundary after relaxation is difficult or impossible to reverse. Any change must be reviewed with the authorizing agency, and automated infrastructure-as-code mechanisms that manage organization policies must be updated so they do not unintentionally revert the values.

Complementary constraints provide defense in depth alongside location restriction. Examples include gcp.restrictCmekCryptoKeyProjects, which limits where customer-managed encryption keys may reside, and gcp.restrictNonCmekServices, which requires customer-managed encryption keys for listed API services. Policy Intelligence tools give insight into access to accounts and resources, helping auditors verify that identity and access management policies still restrict administration and data access to approved identities.

1.5How Location Constraints Work With Access and Data Movement Controls

Location constraints govern where resources are created, while separate controls govern who can reach them and how data moves between them. VPC Service Controls (VPC-SC) creates a context-based perimeter around projects so data flows only from approved services to approved destinations inside the boundary. Google Cloud Armor adds IP and geo-based constraints on ingress, and Identity-Aware Proxy (IAP) verifies user identity before permitting application access, with the domain-restricted sharing constraint limiting which Cloud Identity or Google Workspace domains may appear in IAM policies.

Product-specific locality settings must align with the organization policy for end-to-end sovereignty. BigQuery locality restrictions dictate where datasets are stored and backed up, Cloud Storage bucket location pins object data to specified regions, and Compute Engine load balancing across multiple zones keeps processing inside one region. Together the organization policy blocks out-of-boundary provisioning, VPC Service Controls blocks out-of-boundary data movement, and product settings pin at-rest data to the approved geography.

Storage topology in Google Cloud is the choice of where data at rest lives and how many geographically separate areas hold copies of that data. A single-region topology keeps all copies inside one region for strict data sovereignty, while dual-region and multi-region topologies store data in at least two geographically separate areas for higher availability and disaster recovery. Choosing correctly requires balancing residency law, cost, availability, and recovery objectives for Cloud Storage, BigQuery, and Cloud Spanner.

2.1Cloud Storage Bucket Location Choices and Replication Tradeoffs

Cloud Storage buckets can be created as single-region, dual-region, or multi-region to meet locality restrictions. Objects stored in dual-regions and multi-regions are stored in at least two geographically separate areas, regardless of their storage class, which protects availability even during large-scale disruptions such as natural disasters. A dual-region achieves this redundancy by using a pair of regions that you choose, while a multi-region achieves it by using any combination of data centers in the specified multi-region, which might include data centers that are not explicitly listed as available regions.

Data synchronization between the two areas in a dual-region or multi-region bucket occurs asynchronously. If you need a high degree of confidence that data has been written to an alternative region to meet recovery time objective (RTO) and recovery point objective (RPO) values, one strategy is to use two single-region buckets instead of one dual-region bucket. You can then either dual-write the object to both buckets at write time or write to one bucket and have Cloud Storage copy it to the second bucket with an object rewrite.

If requirements restrict you to a single region, you cannot implement an architecture that is redundant across geographic locations using Google Cloud alone. In that case, consider a multi-cloud or hybrid strategy that keeps a second copy in the same geographic area on another cloud or on premises, using interoperability with Amazon S3, open-source object stores such as minIO and Ceph, Managed Service for Apache Airflow with the gcloud storage utility, or Transfer service for on-premises data. If locality rules permit encryption as a control, you can also use customer-managed keys to make a dual-region or multi-region bucket acceptable because the data cannot be decrypted without keys held outside Google.

2.2BigQuery Dataset Location Immutability and Backup Rules

BigQuery stores data in datasets, and each dataset has a location that is either regional or multi-regional. For either location type, BigQuery stores copies of your data in two different zones within the selected location, and you cannot change the dataset location after you create the dataset. This immutability means the initial location choice permanently determines residency scope, so a strict sovereignty workload must start as a regional dataset in the required region.

BigQuery disaster recovery (opens in a new tab) requires a backup outside the primary location to survive a regional disaster. For BigQuery multi-regions, avoid backing up to regions within the scope of the multi-region; if you select the EU multi-region, for example, exclude Zurich and London from being part of the backup plan because they fall within that scope. Review loss-of-region guidance to design a disaster recovery solution for the unlikely event of physical regional loss, and weigh single-region control against multi-region availability.

2.3Cloud Spanner Instance Configurations for Placement and Replication

Cloud Spanner is a fully managed relational database with strong consistency and up to 99.999% availability, and placement is controlled by the instance configuration. An instance configuration defines the geographic placement and replication of the databases in a Spanner instance, and when you create an instance you configure it as either regional or multi-region. Spanner supports automatic, byte-level replication and distributes replicas across zones and regions according to that configuration.

Spanner instances that have a regional configuration maintain one read-write replica for each zone within that region, which keeps data inside one region while surviving zonal failure. Instances that have a multi-region configuration replicate data in multiple zones across multiple regions, which survives loss of entire regions and maintains availability without data loss but expands residency scope. Spanner lets you move an instance from any instance configuration to any other instance configuration without downtime or disruption to transaction guarantees, so you can evolve residency posture as regulations change.

2.4How Organization Policy Enforces Approved Storage Topologies

The Organization Policy Service provides centralized control that enforces the topologies above across the resource hierarchy of organization, folder, and project. The location-restricted resources constraint controls the set of locations where location-based resources can be created, with allowed or denied values that can specify multi-regions such as Asia and Europe, regions such as us-east1 or europe-west1, or individual zones such as europe-west1-b. When this constraint is active, users cannot create Cloud Storage buckets, BigQuery datasets, or Spanner instances outside the permitted locations, which prevents accidental residency violations while still allowing the approved single, dual, or multi-region patterns. This enforcement links data residency (opens in a new tab) planning directly to provisioning, so storage topology choices remain inside the legal boundary by default.

Governing regional processing, network egress, and cryptographic key residency means keeping data storage, data processing, and key operations inside a defined jurisdiction and blocking access from outside it. In Google Cloud this is achieved by combining regional execution controls, VPC Service Controls perimeters for egress, and localized Cloud Key Management Service (Cloud KMS) keys with transparency controls.

3.1Regional Execution Controls and What Data Residency Covers

Regional execution and data residency controls ensure Customer Data at rest and in use stays within the selected geography. Assured Workloads (opens in a new tab) creates a folder bound to a control package, such as a US-only boundary, and applies the Resource Locations organization policy constraint to restrict where new in-scope resources can be created at the organization, folder, or project level.

Data residency commitments apply to Customer Data at rest for services that can be configured for data location, but Customer Data does not include resource identifiers, attributes, or other data labels. Google processes Customer Data in use by the configured service only within the country of the selected Region, or within the country or countries of the selected Multi-Region. If the selected Region or Multi-Region is in the European Union, processing stays within the European Union but not necessarily in the same country. Service Data, also called metadata such as billing data, is stored separately under internal-services geography rules.

In-scope services for a strict boundary such as the US Data Boundary for Healthcare and Life Sciences must meet all of the following:

• Listed on Google Cloud's HIPAA Business Associate Agreement page
• Listed on Google Cloud's HITRUST Common Security Framework page
• Support Customer-Managed Encryption Keys (CMEK)
• Support VPC Service Controls
• Support Access Transparency logs and Access Approval requests
• Support at-rest data residency restricted to US locations

Support access can also be constrained by jurisdiction, for example to US Persons located in the US or to background-checked staff located in the US, regardless of whether support is provided by Google or a subprocessor.

3.2How VPC Service Controls Perimeters Block Cross-Border Egress

VPC Service Controls (VPC SC) (opens in a new tab) is a managed networking control that restricts cross-border access and data exfiltration by placing Google-managed resources inside a service perimeter. The perimeter controls movement of data across its boundary and explicitly overrides permissive Identity and Access Management (IAM) settings, so even a misconfigured public grant does not allow access from outside.

A governed data environment moves data through an ordered flow:

1. Upload: A user with appropriate IAM permissions uploads data to BigQuery or Cloud Storage configured for CMEK and Cloud KMS Autokey.
2. Encrypt: The storage service fetches a CMEK from Cloud KMS Autokey and encrypts the data.
3. Classify and de-identify: Sensitive Data Protection continually inspects, classifies, and masks sensitive data using configured templates.
4. Permit by context: Designated IAM principals are granted entry through an Access Context Manager access level template.
5. Deny by default: VPC Service Controls denies access to anyone not specified in the access level.

Place sensitive data in its own service perimeter and configure perimeters around the resources of Google-managed services to control movement across the perimeter. Combine the perimeter with IAM access controls for that data and multifactor authentication for all users who require access to sensitive data.

3.3How Localized CMEK, Cloud EKM, and Transparency Controls Protect Keys

Localized key residency keeps encryption keys and cryptographic operations in the same jurisdiction as the data and processing. Cloud KMS creates, imports, and manages keys and performs cryptographic operations in a centralized service, while Cloud External Key Manager (Cloud EKM) lets you use keys managed externally outside Google Cloud to protect data inside Google Cloud.

Services that support CMEK use envelope encryption, where the service encrypts data with a data encryption key (DEK) and then wraps that DEK with a key encryption key (KEK) from Cloud KMS. Decrypted key material cannot be exported through the API, Google personnel cannot access unencrypted customer key material, key material on a Hardware Security Module (HSM) is never accessed in decrypted state by Cloud KMS jobs, and HSMs are FIPS 140 validated. Cloud HSM hosts keys in FIPS 140 validated HSM clusters and uses Cloud KMS as its frontend for CMEK integrations.

Control over Google access to keys flows from transparency to enforcement: Access Transparency logs Google administrative access, Access Approval requires your approval for that access, and Key Access Justifications integrates with Cloud KMS and Cloud EKM to provide a detailed justification each time a key is requested for encrypt or decrypt, with a mechanism to approve or deny access using an automated policy you set. Used together, Access Approval, Access Transparency, and Key Access Justifications let you deny Google the ability to decrypt your data, making you the arbiter of access.

3.4Dataflow Regional Key Matching and Streaming State Protection

Dataflow enforces key residency by supporting only regional Cloud KMS keys that match the job region. Cloud KMS and Dataflow are both regionalized services, so create the key ring and symmetric key in the same region as the Dataflow job and do not use global or multi-regional keys. When you use a Cloud EKM key, Google has no control over external key availability, and if the key becomes unavailable during job or pipeline creation, the job or pipeline is canceled.

CMEK coverage differs between pipeline state artifacts and job metadata. For batch jobs, all data including data keys used for key-based transforms is always protected by CMEK. For streaming jobs created after March 7, 2024, all user data is encrypted with CMEK, while streaming jobs created before that date do not protect data keys used in windowing, grouping, and joining; drain or cancel and restart the job to enable protection. Job metadata is not encrypted with Cloud KMS keys, including user-supplied Job Names, Job Parameter values, and Pipeline Graph, plus system-generated Job IDs and worker IP addresses.

The following storage locations for pipeline state are protected with Cloud KMS keys:

• Persistent Disks attached to Dataflow workers used for Persistent Disk-based shuffle and streaming state storage
• Dataflow Shuffle state for batch pipelines
• Cloud Storage buckets that store temporary export or import data, using only user-set bucket default keys
• Cloud Storage buckets used to store binary files containing pipeline code, using only user-set bucket default keys
• Cloud Storage buckets used to store sampled pipeline data when data sampling is enabled
• Dataflow Streaming Engine state for streaming pipelines

Key Facts

• The constraints/gcp.resourceLocations organization policy with an allowedValues list denies creation of location-based resources outside approved multi-regions, regions, and zones.
• Cloud Storage dual-region buckets store data in two customer-chosen regions, while multi-region buckets can place data in any data centers in that multi-region, including centers not listed as regions.
• BigQuery dataset locations cannot be changed after creation, and Cloud Spanner regional configurations keep replicas in zones within one region while multi-region configurations replicate across multiple regions.
• VPC Service Controls perimeters control data movement across their boundary and override permissive Identity and Access Management (IAM) settings to block exfiltration.
• Dataflow supports only regional Cloud Key Management Service keys that match the Dataflow job region; global and multi-regional keys do not work.