Does constraints/gcp.resourceLocations Guarantee Healthcare Data Residency?

No. Setting constraints/gcp.resourceLocations does not, by itself, guarantee that every part of a healthcare workload satisfies a chosen data residency boundary. Google documents the constraint as a control over where new supported resources with selectable locations may be created. It is not retroactive, does not govern every resource type, and is not a contractual data-storage commitment.

The policy is still useful. It can prevent a new supported resource from being created in a denied location. A defensible residency design, however, must also inspect existing resources, service-specific storage behavior, global resources, API endpoints, backups, logs, keys, exports, and support access. The policy supplies one control, not the final conclusion.

What does the resource location constraint control?

The Organization Policy Service lets an administrator define allowed or denied Google Cloud locations. For supported resources, the platform checks the policy when a new resource with a selectable location is created. A request for a denied location fails instead of silently selecting that location.

This is a preventive creation control. It can keep teams and automation from adding supported resources outside an approved set of regions, zones, or multi-regions. The hierarchy also matters because an organization policy can apply through organization, folder, and project levels.

The location value needs careful review. A value group can contain several related locations, and Google states that it can expand those groups as new locations become available. If the approved boundary names one exact region, a broad value group may permit more locations than the policy owner intended.

Why is the policy not retroactive?

Google says the limitation applies only to newly created resources. Resources created before the constraint continue to exist and perform their functions. Applying a policy today therefore cannot prove that an older project contains no resources in denied locations.

The same problem appears after an acquisition, project move, or policy correction. The organization policy may show an approved configuration while legacy databases, buckets, queues, or exports remain elsewhere. The policy prevents certain new violations but does not discover or remediate old ones.

Inventory existing resources separately. The review of Cloud SQL backup locations illustrates the risk: changing a future backup location does not move earlier backups. A current policy screenshot cannot account for copies created under an earlier configuration.

Which resources can fall outside the constraint?

The documented limitation covers resources for which a location can be selected and services that support the constraint. Global resources and resources without a selectable location are not controlled by it. Google also documents service-specific behavior and says the policy is not enforced on certain subresource creation paths.

This means a project-level policy is not a complete service map. Each product can interpret location differently. Some resources use a region, some use a multi-region, and others are global. Child resources may inherit location behavior from a parent or follow a documented exception.

Check the support table for every service and resource type in scope. The article on Pub/Sub message storage policies explains another product-specific boundary: the permitted message-storage regions must be reviewed through the service’s own control rather than inferred from a general project label.

Does resource location always equal data location?

No. Google’s restriction guide says that, for some data-containing resources, the resource location also reflects where data is stored. It then warns that some services may not store or process data in the same location where the resource was created.

The guide also states that organization policies containing this constraint are not data-storage commitments. Contractual commitments come from the applicable Google Cloud terms and service-specific terms. An architecture review should keep the technical control, product behavior, and contractual promise as separate evidence.

Logs are a common source of mistaken conclusions. A regional workload does not automatically establish the location of every log bucket. The analysis of Google Cloud Logging location for a regional workload shows why the logging destination needs its own configuration and lifecycle review.

What changes when API traffic uses regional endpoints?

The resource location constraint focuses on supported resources and data at rest. Google documents regional and multi-regional API endpoints for a different concern: keeping the request path, processing, and TLS termination within a specified region or jurisdiction for supported services.

Configuring a regional endpoint does not automatically block global endpoints. Google says global endpoints remain accessible unless the organization also uses the Restrict Endpoint Usage constraint to deny them. A client library, command, integration, or operator can otherwise keep calling a global endpoint.

Regional endpoints are available for a limited set of services. They can also restrict operations on resources outside the endpoint’s location. The team must confirm support and test the exact API calls used by the application rather than assuming that a regional hostname exists for every dependency.

Operational inference: if a workload requires both regional storage and regional API handling, pair supported resource-location controls with supported regional endpoints and endpoint enforcement. Then test the actual clients. This is an architecture inference from the documented scopes of the two controls, not a Google Cloud compliance certification.

How should a team audit an existing project?

Start with an approved boundary written in concrete terms. “Regional” is too vague if the requirement is one country, one EU jurisdiction, or one named region. Record whether the boundary applies to stored data, data in transit, administrative access, recovery copies, and temporary processing.

1. Record the effective organization policy at organization, folder, and project levels.
2. List existing resources with resource type, creation date, and reported location.
3. Check each resource type against Google’s supported-services documentation.
4. Map databases, objects, messages, logs, keys, backups, exports, and restore destinations.
5. Identify global resources and services without selectable locations.
6. Record the API endpoints used by applications, automation, consoles, and support tools.
7. Test denied creation and denied global-endpoint access with synthetic data.
8. Preserve policy, request, result, inventory date, and unresolved exceptions as evidence.

Audit logging also needs its own configuration. Google Cloud Data Access audit logs are generally not enabled by default for most services. A denied-resource test without the needed evidence can leave the team unable to show which control was evaluated and what happened.

What should a residency claim say?

A useful claim names the observed scope. For example: the project policy denied creation of a tested supported resource outside the listed regions on a stated date. That sentence does not claim that every existing resource was moved, every global service was constrained, or every request stayed regional.

If the inventory also confirms service-specific storage, backup location, log location, key location, and enforced endpoint use, state those results separately. Keep exceptions visible. Evidence loses value when several controls are compressed into a broad phrase such as “the project is EU-only” or “the project is HIPAA compliant.”

Provider eligibility, a contract, a region, encryption, and an organization policy can each support part of a control set. None establishes universal compliance alone. Legal, privacy, security, and cloud owners should approve the final claim for the exact workload and jurisdiction.

Frequently asked questions

Does the constraint move existing resources into an allowed region?

No. Google says the policy is not retroactive. Existing resources continue operating and need separate inventory and remediation.

Does an allowed resource location prove where all service data is processed?

No. Google warns that some services may store or process data somewhere other than the resource’s creation location. Review the service documentation and applicable terms.

Do regional endpoints become mandatory after the location policy is enabled?

No. Global endpoints remain accessible unless endpoint usage is restricted. Regional endpoint support also varies by service.

Can the policy prove HIPAA or GDPR compliance?

No. It can demonstrate one location control for supported new resources. Compliance depends on the full processing activity, legal roles, contracts, safeguards, evidence, and applicable law.

References

• Google Cloud, “Restrict resource locations,” retrieved August 16, 2026, https://docs.cloud.google.com/organization-policy/restrict-locations
• Google Cloud, “Regional and multi-regional API endpoints overview,” retrieved August 16, 2026, https://docs.cloud.google.com/docs/security/compliance/about-regional-endpoints