Regulatory Compliance Controls in Google Cloud

Determining technical needs relative to compute, data, network, and storage means translating regulatory mandates into specific Google Cloud controls for isolation, encryption, location, and workload integrity. Regulated data must stay inside approved projects, networks, regions, and key boundaries, while compute must prove it runs only trusted code. The design pairs API-level perimeters with private networking, customer-controlled encryption, immutable retention, and hardened execution environments.

1.1Regulatory Network Perimeters with VPC Service Controls

Regulatory network perimeters with VPC Service Controls (opens in a new tab) are API-level boundaries that govern data movement between protected projects and restricted Google Cloud APIs. The perimeter is defined in an Access Context Manager access policy, which exists once per organization, and it lists protected projects and protected APIs such as Cloud Storage and Compute Engine. In production the design should restrict all supported services, because any unrestricted API remains a potential exfiltration path.

A new perimeter for existing production workloads should first run in dry run mode and only then move to enforced mode. Dry run mode logs what would be denied without blocking traffic, so teams can discover legitimate dependencies before enforcement breaks them. The Service Control API evaluates every request against source network, source project, and target resource project, so requests from outside are denied for restricted services even with sufficient Identity and Access Management (IAM) permissions. Requests from inside are allowed to restricted resources inside the same perimeter but denied to restricted resources outside, including public read-only buckets.

1.2Private Paths and Deny-by-Default Egress

Private paths and deny-by-default egress keep regulated traffic off the public internet and block internet exfiltration at the network layer. Private Google Access lets a subnet such as restricted-subnet reach Google APIs without external IP addresses, while Private Service Connect provides a private endpoint IP such as 10.0.1.1 bound to the vpc-sc bundle of APIs. Cloud DNS then redirects googleapis.com and *.googleapis.com queries inside the VPC to that endpoint, so API data flows from the workload to the Private Service Connect endpoint instead of to public VIPs.

Building the path follows an ordered dependency. First, create the VPC network and subnet with Private Google Access enabled. Then reserve the global address and create the forwarding rule for the Google APIs bundle. Then redirect DNS to the endpoint. Then deny broad egress with a low-priority rule such as priority 65534 to 0.0.0.0/0, and allow only the private endpoint with a higher-priority rule such as priority 1000 for tcp:443 to 10.0.1.1. Because firewall priority decides first, traffic flows from the virtual machine to 10.0.1.1 only when it matches the allow rule, and all other internet egress is denied.

1.3Data Governance with Encryption, Location, and Retention

Data governance with encryption, location, and retention proves where regulated data lives, who holds the keys, and how long records are preserved. Google encrypts stored data by default with AES-256 and protects data in transit with TLS, but regulated workloads add Customer-Managed Encryption Keys (CMEK) in Cloud Key Management Service (Cloud KMS). With CMEK, data flows from the storage or database service to Cloud KMS for wrap and unwrap operations, and access depends on the customer key remaining enabled. Cloud HSM with protection level HSM keeps key material in tamper-resistant hardware, and revoking or destroying the key makes protected data unreadable.

Location and retention complete the control set. Resource Location Constraints enforced through Organization Policy allow resource creation only in approved regions before any bucket, database, or logging bucket is provisioned. Cloud Storage retention policies preserve objects for a defined period, and a locked retention policy transitions the bucket to an irreversible locked state where objects cannot be deleted or overwritten until the period expires. Regulated data must never be placed in resource names, labels, descriptions, URIs, firewall rules, or IAM policies, because those fields sit outside the technical control boundary.

1.4Hardened and Confidential Compute for Regulated Workloads

Hardened and confidential compute for regulated workloads proves that virtual machines and containers run trusted code in isolated execution environments. For Compute Engine (opens in a new tab) teams using custom images must patch those images themselves, while Google-provided images and Container-Optimized OS are patched regularly by Google. Shielded VM adds attested boot with a Virtual Trusted Platform Module (vTPM) as hardware root of trust, so altered firmware or drivers can be detected before the workload handles regulated data.

Confidential Computing protects data in use in system memory, which is not encrypted by default. Confidential VM protects Compute Engine workloads, Confidential GKE Nodes protect container nodes and pods, and Confidential Space protects joint analysis across trust boundaries. For containers, immutability means operators do not modify a running container; they build a new image and redeploy it, with distroless images used to minimize attack surface. Google patches node operating systems and the GKE control plane, while the customer remains responsible for application code, images, RBAC and IAM policy, upgrades for Standard node pools, and logging and monitoring.

Evaluating the shared responsibility model means determining which security duties belong to Google Cloud and which remain with the customer across service models. The division shifts from customer-heavy in Infrastructure as a Service to Google-heavy in Software as a Service, but data protection remains a customer duty in every model. Inherited controls such as default encryption can support audits but do not remove the need to configure access, location, and monitoring.

2.1Ownership Shift Across IaaS, PaaS, and SaaS Delivery

Ownership shift across Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) describes how abstraction moves operational ownership to Google. Infrastructure as a Service (IaaS) provides on-demand compute, storage, and networking such as Compute Engine, Cloud Storage, Cloud VPN, Cloud Load Balancing, and Cloud DNS for lift-and-shift or custom designs. In IaaS Google secures facilities, hardware, and the hypervisor, while the customer secures guest operating systems, applications, data, and network and access configuration above virtualization.

Platform as a Service (PaaS) provides runtime environments such as App Engine, Google Kubernetes Engine (GKE), and BigQuery without managing underlying infrastructure. In PaaS Google owns more platform controls, varying by service, while the customer shares application-level controls and IAM management and retains data security and client protection. Software as a Service (SaaS) provides ready-to-use applications such as Google Workspace, where Google owns infrastructure, platform, and application layers and the customer retains only access controls and data placed in the application.

2.2Customer Operational Duties for Access and Monitoring

Customer operational duties for access and monitoring are the day-to-day controls that determine who can reach data, from where, and with what posture. The customer defines IAM allow and deny policies, controls regional placement and access context, and manages vulnerability and misconfiguration that arise as products change. In serverless models such as Cloud Run functions, small event-driven functions still leave access and stored data with the customer, similar to SaaS.

Data protection tiers increase customer responsibility from Google-default encryption to Customer-Managed Encryption Keys (CMEK) to Customer-Supplied Encryption Keys (CSEK). Location is also a customer control: an EU business may need to keep data in EU regions for GDPR, while FedRAMP High requires Assured Workloads Data Boundary for FedRAMP High. Shared responsibilities and shared fate (opens in a new tab) means Google automates patching, boot attestation, and machine integrity on homogeneous infrastructure, while the customer must configure and continuously monitor what it provisions.

2.3FedRAMP Authorization and Audit Evidence Split

FedRAMP authorization and audit evidence split separates Google-owned platform authorization from customer-owned system authorization. Google Cloud holds a FedRAMP High provisional authorization to operate (P-ATO) covering more than 150 services, which lets a customer inherit platform controls and pursue its own Authorization to Operate (ATO) with a third-party assessment organization. Under current guidance the path is an Agency ATO completed jointly by the customer, Google, and the assessor.

Documentation makes the handoff explicit for auditors. The Customer Responsibility Matrix describes customer duties for NIST SP 800-53 controls, the System Security Plan describes architecture and Google implementation, control mapping guides describe per-service customer configuration, and implementation guides identify which APIs and fields are suitable for protected data. Cloud Audit Logs records customer-visible data access for customer audit, Access Transparency records Google administrative access for customer review, and deployment integrity logs are monitored internally by Google. Together inherited platform controls plus customer logs, region choices, and service configurations form the complete audit story.

Configuring security controls within cloud environments to support compliance requirements means using centralized guardrails to enforce residency, service use, encryption, and privileged-access governance. Organization Policies block noncompliant configuration before resources are created, Assured Workloads bundles those policies for a specific regime, and VPC Service Controls blocks cross-boundary data movement. Access Transparency and Access Approval then govern visibility into Google support access.

3.1Preventive Organization Policies and IAM Governance

Preventive Organization Policies and IAM governance separate who can act from what configuration is allowed. Organization Policies are centralized constraints applied at the organization, folder, or project level, where a policy set at the organization flows down to child folders and projects unless overridden below. IAM determines who can act, while the organization policy determines what is allowed, so a noncompliant request is denied even if the requester has IAM permission.

Common constraints block risky classes of configuration, including disabling nested virtualization, restricting legacy TLS 1.0 or 1.1, requiring CMEK, disabling downloadable service account keys, and restricting resource locations. Least privilege complements prevention by granting granular predefined or custom roles to groups and avoiding primitive Owner, Editor, and Viewer roles. Privileged-activity governance requires enabling ADMIN_READ, DATA_READ, and DATA_WRITE logs for IAM-related APIs and protecting Admin Activity logs retained 400 days by default and Data Access logs retained 30 days by default with restricted IAM access.

3.2Assured Workloads Packages for Regulated Residency

Assured Workloads (opens in a new tab) packages for regulated residency are folder-level control bundles that enforce a compliance regime for the lifetime of folders and projects inside them. Each framework defines permitted regions, services, and security settings, and child projects inherit those guardrails automatically. Supported directions include US data residency in US regions, UK residency in UK regions, IL2 and IL4 controls, and sovereign controls for the EU.

Boundary controls work together to keep customer data, metadata, and support inside the permitted regions. Core controls include Restrict Resource Locations, Restrict Service Usage to validated services, Define Locations for Cloud Logging Buckets and Technical Support Services, Disable Global Cloud Armor Policies and Global Load Balancers, and block Pub/Sub message transforms and Kafka Connect paths that could move data across boundaries. Service-specific settings extend the same principle to BigQuery, Spanner, Dataproc, Cloud DNS, Cloud Deploy, Cloud Monitoring, and other managed platforms, so traffic flows from producer services to storage and analytics only when each dependency is pinned to a permitted location.

3.3Google Access Visibility and Perimeter Data Boundaries

Google access visibility and perimeter data boundaries separate logging of provider access from enforcement against data movement. Access Transparency logs administrative access by authorized Google personnel after it occurs for support or availability, with log data flowing from Google internal systems to the customer organization. Access Approval adds an approval gate where the request flows from the Google administrator to the customer, and only after customer approval must the request still pass Google internal privilege checks before access is permitted.

VPC Service Controls with Access Context Manager enforces the data boundary that Resource Locations alone cannot enforce. VPC Service Controls blocks data access and copy operations from outside the perimeter even when IAM is permissive, while Access Context Manager defines contextual exceptions based on identity, IP, and device. A single large unified perimeter gives strongest exfiltration protection with mainly north-south management, while multiple smaller perimeters are reserved for isolating PCI DSS scope, separating high-trust from shareable data, or isolating tenants. Customer Data at rest follows residency commitments for the selected region, while Service Data such as billing metadata follows separate internal geography rules.

Determining the Google Cloud environment in scope for regulatory compliance means defining the exact folders, projects, services, regions, and data types where elevated controls apply. Google secures physical infrastructure and enforces customer-configured policies, while the customer decides which data is regulated and keeps it inside the controlled boundary. Architectural isolation minimizes audit scope by applying the full compliance burden only to that enclosed set.

4.1Shared Duties and Assured Workloads Boundaries

Shared duties and Assured Workloads (opens in a new tab) boundaries divide foundational platform work from customer data governance. Google provides default encryption, infrastructure controls, Organization Policy guardrails, Policy Intelligence insights, and enforcement of customer IAM and Assured Workloads selections for storage location and personnel access. The customer must classify data with heightened needs under HIPAA, PCI DSS, FedRAMP, GDPR, and related regimes, place that data inside appropriate Assured Workloads folders and keep it there, configure least-privilege IAM, and confirm product and region compliance for every service used.

An Assured Workloads folder is a regulatory boundary where the hierarchy flows from Organization to folder to project to service resources such as Compute Engine VMs, Pub/Sub topics, Cloud Storage buckets, and Cloud VPN endpoints. Any project created under the folder inherits its guardrails, so new resources automatically fall under the same controls. Because only data inside inherits residency and personnel-access restrictions, moving regulated data outside removes those protections. For EU regimes Google adds an EU data boundary, EU-person support routing, administrative-access visibility, and Cloud KMS options.

4.2Isolation with Folders, Networks, and Identity Controls

Isolation with folders, networks, and identity controls keeps regulated workloads separated while general commercial workloads stay outside audit scope. Organizational isolation depends on placing only regulated assets such as health data, cardholder data, personal identifiers, and account data inside compliant folders and verifying that each service and region is in scope for the selected program. For FedRAMP High and DoD IL2, IL4, and IL5, data must generally remain within a US geographical boundary, enforced with resource-location policies that limit selectable regions.

Network isolation uses VPC Service Controls to block API calls from protected projects to outside services unless an explicit exception allows the pattern. Although VPC networks are global in definition, subnets must be created only in approved US regions, and only regional load balancers with regional Google Cloud Armor policies are used because global load balancers and global Armor do not meet jurisdictional requirements. Private Service Connect, Private Google Access, and Private Service Access keep traffic flows from workload subnets to Google services off the public internet. IAM then limits who can administer and read data inside the hierarchy, tightened by Access Approval, Key Access Justifications with Cloud External Key Manager, and infrastructure-as-code consistency.

4.3Preventive, Detective, and Audit Controls for In-Scope Assets

Preventive, detective, and audit controls for in-scope assets prove that resources stay on baseline and produce complete evidence. Organization Policy prevents noncompliant configuration at deployment time and inherits downward, with central constraints for resource locations, CMEK protection, TLS versions, logging-bucket locations, support locations, and blocking of global load balancing and noncompliant service use. Security Command Center (SCC) then continuously checks deployed resources against templates for ISO 27001, NIST 800-53, CIS GCP Foundations v3.0, FedRAMP, and DoD IL5, generating findings such as RESOURCE_LOCATION_NOT_ALLOWED or missing Bucket Lock retention.

Audit traceability flows from services to Cloud Logging to central sinks. Cloud Audit Logs records administrative and data-access activity for review in Logs Explorer and log-based metrics, while Access Transparency logs Google administrator access across the trust boundary. A repeatable cycle verifies alerting policies have notification channels, enables audit and transparency logs, reviews entries, creates metrics for compliance events, and exports logs to a controlled Cloud Logging bucket, Cloud Storage bucket, or BigQuery dataset in an approved region. Preservation depends on Bucket Lock for immutable retention, object versioning, and Cloud Asset Inventory, and regulated data must never leak into names, labels, URIs, firewall rules, or IAM policies that sit outside the protection boundary.

Mapping compliance requirements to Google Cloud services and security controls means linking each regulatory objective to native enforcement and monitoring. Audit logging proves who did what, network perimeters prove where data can move, and identity plus encryption controls prove who can act and read stored data. The chain works only when logs are enabled, centrally retained, and consumed by detection and compliance frameworks.

5.1Audit Logging, Central Retention, and Monitoring Tiers

Audit logging, central retention, and monitoring tiers form the end-to-end evidence system for regulated activity. Cloud Audit Logs records ADMIN_WRITE operations that write metadata or configuration in Admin Activity logs, which cannot be disabled, plus ADMIN_READ, DATA_READ, and DATA_WRITE in Data Access logs and Policy Denied events for blocked attempts. Data Access logs, except for BigQuery, are disabled by default and must be enabled by editing IAM policy objects at the folder or organization level so coverage flows down to all child projects.

Log routing moves filtered entries from Cloud Logging to controlled destinations through sinks. Aggregated sinks at the folder or organization level collect entries from all child projects into one central bucket or project, separating audit storage from workloads and preventing gaps for new projects. Platform logs are enabled per resource, such as Cloud DNS at the VPC level, VPC Flow Logs at the subnet level, and Firewall Rules Logging at the rule level. Security Command Center Premium with Compliance Manager then evaluates retained logs against frameworks such as FedRAMP Low 20x, with findings flowing to Pub/Sub, BigQuery, and response playbooks. Access to log buckets is controlled by roles such as Logs Viewer and Private Logs Viewer, with log views, sinks, and field-level controls isolating sensitive entries and PII.

5.2Network Segmentation and Private Connectivity Mapping

Network segmentation and private connectivity mapping implements perimeter defense required by PCI-DSS, FedRAMP Moderate and High, CIS Controls 12 and 13, and SOC 2. VPC Service Controls (VPC-SC) creates isolation perimeters around projects and Google-managed services where inside-to-protected-service traffic is allowed by default but cross-boundary traffic is denied unless an explicit ingress or egress rule names the source, service, and methods. The perimeter check applies even when IAM would allow the call, so stolen credentials cannot copy data to an external project.

Segmentation inside the perimeter filters flows between segments with custom VPC networks, firewall rules, GKE Network Policy for pod-to-pod and pod-to-external flows, Cloud SQL authorized networks, Compute Engine public-IP restrictions, Shielded VM and Container-Optimized OS hardening, TLS 1.2 or higher, and service-account key hygiene. Private Google Access lets VMs reach Google APIs without public IPs, so data flows from the instance over the private path, while Private GKE Clusters keep node and control-plane traffic private. Continuous monitoring depends on the Security Center Service Agent having explicit perimeter access; otherwise Security Health Analytics raises VPC_SC_RESTRICTION and Compliance Manager, Event Threat Detection, and vulnerability findings cannot flow to the security project.

5.3Identity Governance and Encryption for Regulated Data

Identity governance and encryption for regulated data aligns least-privilege access and stored-data protection with framework mandates. IAM grants only required roles at the smallest scope, preferably to functional groups, with role recommendations used to remove excessive grants. Chrome Enterprise Premium evaluates user-centric conditions such as IP or certificate-based mutual TLS on every API request for user identities only, while VPC Service Controls applies to both user and service-account identities. OS Login with 2-Step Verification protects SSH paths, and organization constraints can disable service-account key creation and upload.

Stored-data protection starts with Google default encryption and adds Customer-Managed Encryption Keys (CMEK) in Cloud KMS for selected data, with Cloud KMS Autokey provisioning consistent keys on demand. Key ownership stays with the customer while processing stays with the service, so revoking the CMEK key removes decryption without changing IAM grants on the data. Access Transparency (opens in a new tab) logs and Access Approval requests provide provider-access evidence, while Cloud Audit Logs distinguishes configuration writes from data reads and writes for compliance mapping.

Key Facts

• VPC Service Controls denies API-level data movement across its perimeter even when IAM allows it, and new production perimeters should run in dry run mode before moving to enforced mode.
• Private Service Connect and Private Google Access keep API traffic on private paths, while a higher-priority firewall allow for TCP 443 to the private endpoint combined with a low-priority deny to 0.0.0.0/0 blocks other internet egress.
• Customer-Managed Encryption Keys in Cloud KMS with Cloud HSM protection keep key material in tamper-resistant hardware, and revoking the key makes protected data unreadable without changing IAM grants.
• Organization Policies inherit from organization to folder to project and deny noncompliant configurations even when the requester has IAM permission, while Assured Workloads bundles those policies for a specific residency regime.
• Cloud Audit Logs Admin Activity for ADMIN_WRITE cannot be disabled, while Data Access ADMIN_READ, DATA_READ, and DATA_WRITE are disabled by default except for BigQuery and should be enabled at folder or organization level with aggregated sinks for central retention.