Compliance Controls with Assured Workloads

Enforcing organizational policies and access governance is the use of centralized preventive guardrails to control resource configuration and privileged access across the cloud hierarchy. Organization Policies (opens in a new tab) define what configurations are allowed, while Google Identity and Access Management (IAM) defines who can act and audit logging records what was done. Together these controls support data residency, regulated workloads, and governance of privileged access.

1.1Organization Policies Across the Hierarchy

Organization Policies are centralized constraints that control allowed resource behavior at the organization, folder, or project level. A policy set at the organization node flows down to each child folder and then to each project in that folder, unless a lower-level policy overrides it with a more specific rule. This inheritance allows a global baseline to be defined once with selective exceptions only where justified. Security Command Center (opens in a new tab) checks organization, folder, and project resources to detect missing guardrails.

1.2Restricting Resource Configurations With Constraints

Resource configuration restriction is preventive enforcement that blocks risky configurations before resources are created or changed. Organization Policies act as the control plane that evaluates each creation or update request against a named constraint, so a noncompliant request is denied even if the requester has IAM permission to make it. The dependency is explicit: IAM determines who can act, while the organization policy determines what configuration is allowed.

Common preventive constraints include:

• constraints/compute.disableNestedVirtualization to turn off hardware-accelerated nested virtualization for Compute Engine virtual machines (VMs).
• constraints/gcp.restrictTLSVersion to deny access from older Transport Layer Security (TLS) versions such as TLS 1.0 or TLS 1.1.
• constraints/gcp.restrictNonCmekServices to block services from creating resources without customer-managed encryption keys (CMEK).
• constraints/iam.disableServiceAccountKeyCreation to reduce or eliminate downloadable service account keys in favor of more secure authentication.
• constraints/ainotebooks.accessMode to define allowed access modes for Vertex AI Workbench notebooks and instances.
• Location-based constraints to restrict where resources can be created and where data can be replicated.

Different compliance goals map to specific controls:

1.3Controlling Data Residency and Regionalization

Data residency control is the restriction of where data is stored at rest and how it moves between regions. Resource location policies are the organization policy mechanism for this goal: they limit the locations where resources can be created and limit replication between regions. The location property of each resource identifies where the service is deployed and who maintains it, which lets auditors verify that regulated data stays in approved geographies. Effective control starts with understanding data type and location, determining which laws apply, and then enforcing the allowed locations through policy.

1.4Enforcing Least Privilege and Separation of Duties

Least privilege and separation of duties is the practice of dividing access so no single identity holds excessive or combinable privileges. Google Identity and Access Management (IAM) enforces least privilege by granting only granular predefined or custom roles to groups and avoiding legacy primitive roles such as Owner, Editor, and Viewer on user-created service accounts. Separation of duties further divides privileges so no single identity can abuse authorized access without collusion, with regular analysis and adjustment through policy analysis tools. For Google Kubernetes Engine (GKE), this means using custom least-privilege service accounts for node pools and limiting OAuth scopes to only devstorage.read_only, logging.write, and monitoring when the default account is used.

1.5Logging Privileged Activity and Restricting Audit Access

Privileged-activity governance is comprehensive audit logging combined with strict control over who can read those logs. Monitoring of privileged functions requires enabling ADMIN_READ, DATA_READ, and DATA_WRITE audit logs for the iam.googleapis.com, iamcredentials.googleapis.com, and sts.googleapis.com application programming interfaces (APIs), so token creation and role use are traceable. Audit lifecycle management then moves Admin Activity and System Event logs, retained 400 days by default, and Data Access logs, retained 30 days by default, into long-term storage with metrics, alerting policies, and notification channels. Access to audit management information itself is restricted to privileged users through IAM allow policies, which preserves the integrity of evidence used for compliance reviews and approval workflows.

Assured Workloads (opens in a new tab) is an enablement workflow in Google Cloud that creates and monitors control packages for regulated and sovereign workloads. A control package bundles organization policies, access controls, and service configurations that enforce a specific compliance regime for the lifetime of the folders and projects inside it. Choose Assured Workloads when the enterprise requires dedicated regional support, certified programs such as FedRAMP or International Traffic in Arms Regulations (ITAR), Department of Defense Impact Levels such as IL2 and IL4, or sovereign programs such as Sovereign Controls for the European Union (EU).

2.1Compliance Regimes and Control Packages

Assured Workloads compliance regimes are preset frameworks that map regulatory requirements to enforced cloud controls. Each framework defines which regions, services, and security settings are permitted, and Assured Workloads applies those settings as guardrails that persist while resources remain in the Assured Workloads environment. Supported directions include United States (US) data residency restricted to US regions, United Kingdom (UK) data residency restricted to UK regions, IL2 controls for meeting IL2 requirements, and IL4 controls for meeting IL4 requirements. The US Data Boundary, IL2, and IL4 frameworks are described as Preview features subject to Pre-General Availability (Pre-GA) terms, which means the controls are available as-is with potentially limited support and behavior or service coverage can change before general availability.

2.2Data Residency and Service Restrictions

Data residency in Assured Workloads is enforcement that prevents resources, data, and support operations from leaving the approved boundary. Resource Manager organization policies apply to the Assured Workloads folder, and child projects inherit those policies so new resources cannot violate residency. The boundary controls work together to keep customer data, operational metadata, and support access inside the permitted regions.

Core boundary controls enforced by the frameworks include:

• Restrict Resource Locations to allow resource creation only in permitted regions, such as US regions for the US Data Boundary or UK regions for UK residency.
• Restrict Service Usage to deny services that are not validated for the regime, so only in-scope services can be enabled.
• Define Locations for Cloud Logging Buckets to force log buckets that may contain customer data to reside in permitted regions.
• Define Locations for Technical Support Services to restrict where support data can be stored or processed during troubleshooting.
• Disable Global Cloud Armor Policies to prevent global policies whose configuration and enforcement span regions outside the boundary.
• Disable Creation of Global Load Balancers to block global front ends that would distribute traffic outside the boundary in IL2-type environments.
• Disable Pub/Sub Topic and Subscription Message Transforms to block transforms that could execute or move message data outside approved regions.
• Disable the Creation and Update of Kafka Connect Clusters to block a distributed integration path that could replicate data across boundaries.

Service-specific settings extend the same residency principle to managed platforms. The frameworks include BigQuery compliance settings, Dataplex and Dataproc data-boundary configuration, Google Agent Platform data-boundary configuration, Spanner data-boundary configuration for IL2, Cloud Databases Context Store regulatory settings, Cloud Domain Name System (DNS) regulatory settings, Cloud Deploy regulatory settings, Cloud Identity rulesets, Cloud Monitoring and Cloud Logging compliance with FedRAMP or DoD Impact Levels, Looker (Google Cloud core) compliance, Apigee regulatory settings, permitted versions for Cloud Run functions, and restrictions on the BigQuery Data Transfer Service API. Traffic flows from the producer service to its storage, logging, and analytics dependencies only when each dependency is also pinned to a permitted location and permitted service version.

2.3Control Over Google Administrative Access

Control over Google administrative access separates visibility into Google support activity from the ability to block that activity. Access Transparency (opens in a new tab) logs administrative access by authorized Google personnel when they support the organization or maintain service availability. The log flows from Google internal access systems to the customer organization, so the customer retains an audit trail on its side of the trust boundary even though the administrator sits on Google's side.

Access Approval adds an approval gate in front of eligible support access for highly sensitive or restricted data. An access request flows from the authorized Google administrator to the customer for explicit approval, and only after customer approval must the request still pass Google internal privilege checks before access is permitted. Approved access is logged with Access Transparency logs that are linked to the approval request, so the approval record and the access record share a common trace.

2.4Encryption, Confidentiality, and Continuous Monitoring

Encryption and transport controls in Assured Workloads keep data protected and keys separated from the data they protect. Require CMEK Protection mandates customer-managed encryption keys so Google default encryption alone does not satisfy the regime. Cloud Key Management Service (Cloud KMS) with Cloud External Key Manager (Cloud EKM) lets teams encrypt data with keys that are stored and managed in a third-party key management system deployed outside Google's infrastructure. That architecture maintains separation between data at rest in Google Cloud and encryption keys outside Google Cloud, while data can still flow from storage to compute and analytics services for processing. Confidential Computing extends protection to data in use by encrypting memory contents during processing, and Restrict TLS Versions enforces minimum transport security for data in transit. Continuous monitoring maintains posture after creation: Assured Workloads monitors the lifespan of the control package, Access Transparency provides ongoing visibility into Google administrative access, and Cloud Logging, Cloud Monitoring, and Looker compliance settings ensure operational telemetry and analytics meet FedRAMP or DoD Impact Level handling.

Configuring data regionalization and service localization is the practice of controlling where Google Cloud data is stored at rest, where it is processed in use, and which regions services are allowed to run in. Resource Locations organization policy constraints enforce allowed locations, Assured Workloads packages preset those locations for regulated mandates, and VPC Service Controls (opens in a new tab) with Access Context Manager enforce the boundary against movement and access from outside.

3.1Resource Locations and Region Selection

Resource Locations is the organization policy constraint that restricts the location of new in-scope resources at the organization, folder, or project level of the resource hierarchy. When the policy is set, users creating resources inside its scope can only select allowed regions, which supports geographic mandates such as US-only or EU-only residency. The constraint applies only to new resources for services that support location restriction, so some resources are out of scope and unrestrictable and must be checked against the supported-services list. During Assured Workloads setup, an Assured Workloads folder applies this control automatically based on the selected control package, so later resource creation inside that folder is limited to the regions permitted by that package, such as US-only regions for healthcare, Internal Revenue Service (IRS) Publication 1075, and ITAR-related packages.

3.2Assured Workloads Control Packages for Residency

Assured Workloads (opens in a new tab) is the folder-level framework that bundles data-location controls with supporting security requirements for a specific regulatory mandate. Each in-scope service in a US data-boundary package must meet all of the following requirements:

• Listed on Google Cloud's Health Insurance Portability and Accountability Act (HIPAA) Business Associate Agreement (BAA) page
• Listed on Google Cloud's Health Information Trust Alliance (HITRUST) Common Security Framework (CSF) page
• Supports Cloud Key Management Service (Cloud KMS) customer-managed encryption keys (CMEK)
• Supports VPC Service Controls
• Supports Access Transparency logs and Access Approval requests
• Supports at-rest data residency restricted to US locations

Support-access controls are also localized by package, such as restricting support cases to US Persons located in the US or to background-checked staff with escorted sessions for IRS Publication 1075. These packages therefore combine where data rests with who can support it and how that support is logged and approved.

3.3VPC Service Controls and Access Context Manager Data Boundaries

VPC Service Controls is the managed perimeter control that creates a security boundary around Google-managed services such as Cloud Storage (opens in a new tab) and BigQuery to control movement of data across the perimeter. Resources inside the perimeter can communicate with necessary IAM and network permissions, while requests from outside are blocked even when IAM permissions are permissive or misconfigured. Access Context Manager defines the exception path through access levels based on contextual attributes such as identity, Internet Protocol (IP) address, and device.

Access to data inside the perimeter follows an ordered decision:

1. Default deny at the boundary: VPC Service Controls blocks data access and copy or transfer operations from outside the perimeter.
2. Contextual allow: Designated IAM principals that satisfy an Access Context Manager access-level template are granted access inside the perimeter.
3. Deny all others: Anyone not specified in the access-level template remains denied, preserving least privilege.

Perimeter architecture affects both protection and operations. A single large common unified perimeter provides the most effective protection against exfiltration and the lowest management overhead because teams manage mainly north-south access from the internet to inside. Multiple smaller perimeters add east-west management between perimeters, so they are reserved for cases such as separating high-trust regulated data from de-identified shareable data, isolating Payment Card Industry Data Security Standard (PCI DSS) scope, or separating independent tenants where tenant-to-tenant movement counts as exfiltration.

Enable all protected services in a perimeter and avoid complex designs with multiple bridges, demilitarized zone (DMZ) perimeters, or complex access levels, since any unprotected API creates an additional exfiltration vector.

3.4Customer Data, Service Data, and Processing Location

Customer Data and Service Data are two distinct categories with different residency commitments. Data-residency commitments apply to Customer Data at rest for services that can be configured for data location, and Customer Data does not include resource identifiers, attributes, or other data labels. Google processes Customer Data in use by the configured service, not including any user interface, 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 EU, processing in use stays within the EU but not necessarily in the same country. Service Data, also called metadata, is the personal data Google collects or generates during administration of the services, such as billing data. Service Data is stored separately under internal-services geography rules and does not follow the same Customer Data residency commitment.

Key Facts

• Organization Policies flow from the organization node to child folders and then to projects, and they deny noncompliant configurations even when the requester has IAM permission to create the resource.
• Access Transparency logs Google administrative access after it occurs, while Access Approval requires customer approval before eligible access and approved access must still pass Google internal privilege checks.
• Assured Workloads control packages bundle organization policies, access controls, and service configurations that persist for the lifetime of folders and projects inside the environment.
• VPC Service Controls blocks data access from outside the perimeter even when IAM allows it, with Access Context Manager access levels defining the contextual exception path.
• Resource Locations organization policy constraints limit only new in-scope resources to allowed regions and do not by themselves block cross-perimeter data movement.