# SOC 2 Access Controls on GCP (CC6): What Google Covers and What to Configure

Source: https://truvocyber.com/blog/soc-2-cc6-gcp
Published: 2026-11-08
Topic cluster: SOC 2

> SOC 2 CC6 on GCP: what Google covers, what the customer configures, the Org Policy baseline, and the gcloud evidence auditors accept for CC6.1 to CC6.8.

SOC 2 CC6 responsibility on Google Cloud depends on the service model. Google's SOC 2 report covers physical access (CC6.4) and storage media destruction (part of CC6.5) for every service, and on managed services such as Cloud SQL and GKE Autopilot, Google also patches and hardens the operating system. On Cloud Run, Google patches the container base image only when automatic base image updates are turned on. Identity, access grants, network exposure and data protection stay with the customer on every service.

At a glance

- **Inherited from Google on every service**: CC6.4 physical access and media sanitization within CC6.5. Evidence is Google Cloud's SOC 2 Type II report, issued quarterly and downloadable from Compliance Reports Manager.
- **Depends on the service model**: OS and runtime patching and hardening (CC6.1, CC6.8). Google handles them on Cloud SQL and GKE Autopilot, and on Cloud Run when automatic base image updates are on. The customer handles them on Compute Engine VMs.
- **Configured by the customer on every service**: CC6.2, CC6.3, CC6.6, CC6.7, identity and encryption choices in CC6.1, and data and key disposal in CC6.5.
- **Defaults that already help**: AES-256 encryption at rest, TLS to the Google Front End, and security baseline constraints on organizations created on or after May 3, 2024.
- **Defaults to change**: load balancers with no SSL policy accept TLS 1.0, Cloud SQL accepts unencrypted connections by default, and older organizations allow service account key creation.
- **Evidence tooling**: Security Command Center Compliance Manager (SOC 2 framework on the Premium tier), Wiz, Cloud Asset Inventory exports, and Google SecOps for detection.

## What does the Google Cloud shared responsibility model mean for SOC 2?

The Google Cloud shared responsibility model sets the boundary of a SOC 2 audit: everything on Google's side is evidenced by Google's SOC 2 report, and everything on the customer's side needs a control the company operates and evidences. In Google's model, Google is always responsible for the underlying infrastructure and network, the customer is always responsible for access policies and data, and the middle (operating systems, runtimes, platform configuration) changes with the service type: IaaS, PaaS, SaaS or serverless.
Part of the stackOwner in the Google Cloud modelSOC 2 evidence sourceData centers, hardware, physical networkGoogle, on every serviceGoogle Cloud SOC 2 Type II reportHypervisor and host infrastructureGoogle, on every serviceGoogle Cloud SOC 2 Type II reportGuest OS, runtime, database engineDepends on the service (see the service model table below)Google's report for managed services, customer controls for VMsPlatform configuration: network exposure, encryption settings, loggingCustomerCustomer controls and configuration exportsIdentities, IAM grants, access policiesCustomer, on every serviceCustomer controls, tickets and access reviewsData: classification, retention, deletionCustomer, on every serviceCustomer controls and policies

Google also publishes per-product statements of shared responsibility (Cloud Build has one, for example) and describes its approach as **shared responsibilities and shared fate**. Shared fate is Google's term for the help Google provides on the customer's side: secure landing zone blueprints, secure defaults such as the security baseline constraints, and Architecture Framework guidance. For SOC 2, shared fate makes customer controls easier to build without changing who owns them. A baseline constraint Google turned on is still a customer control that the company has to evidence.

SOC 2 has its own vocabulary for the same boundary. Google Cloud appears in the company's system description as a **subservice organization**, typically presented with the carve-out method. Google's report lists **complementary user entity controls**, the customer's half of the model. The company's report then lists **complementary subservice organization controls**, the controls the company relies on Google to operate. The [CSOCs and inclusive method guide](/blog/soc-2-csocs-inclusive-method) explains both reporting methods.

## Which SOC 2 CC6 criteria does Google Cloud cover, and which does the customer own?

Google Cloud covers the physical side of CC6 on every service and the platform side on managed services. The customer owns identity, access grants, network exposure and data configuration everywhere. The table below maps each CC6 criterion to the owner and the main GCP features involved.
SOC 2 criterionWhat the criterion asks (paraphrased)Owner on GCPMain GCP featuresCC6.1 Logical access securityAccess is designed and technically enforced: identity, authentication, segmentation, encryption, asset inventory, hardened configurationsCustomer, with OS hardening shared by service modelCloud Identity or Workforce Identity Federation, Organization Policy, resource hierarchy, Cloud KMS, Cloud Asset InventoryCC6.2 Registration and authorizationUsers and systems are approved before they receive credentials, and credentials are removed when no longer neededCustomerIdP-driven groups, Workload Identity Federation, service account key constraintsCC6.3 Role-based access and least privilegeAccess is granted by role, kept to the minimum, and changed or removed on timeCustomerPredefined and custom roles, role recommendations, Privileged Access Manager, IAM Conditions, deny policiesCC6.4 Physical accessPhysical access to facilities and hardware is restrictedGoogle (inherited)Google Cloud SOC 2 Type II reportCC6.5 Asset disposalData and media are disposed of so the data cannot be recoveredSharedGoogle media sanitization (inherited), Cloud KMS key destruction, retention and lifecycle rulesCC6.6 Boundary protectionThreats from outside the system boundary are blocked or restrictedCustomerFirewall policies, IAP TCP forwarding, Cloud Armor, VPC Service Controls, external IP constraintsCC6.7 Data transmission and movementData in transit and data movement are restricted to authorized parties and protectedCustomerSSL policies, TLS version constraint, Cloud SQL SSL mode, VPC Service Controls, resource location constraintCC6.8 Malicious and unauthorized softwareUnauthorized or malicious software is prevented or detectedShared by service model: customer owns application code and images everywhere, and the guest OS on VMsBinary Authorization, Artifact Analysis, Shielded VM, Security Command Center threat detection

The criterion text is AICPA copyrighted material, so the descriptions above are paraphrased. The [SOC 2 Trust Services Criteria guide](/blog/soc-2-trust-services-criteria-guide) covers the full set.

## How does the GCP service model change shared responsibilities for SOC 2 CC6?

When a workload changes from virtual machines to managed services, more of the patching and hardening evidence comes from Google's SOC 2 report and less from the customer's own controls. Identity, IAM grants and data settings stay with the customer in every row.
GCP serviceGoogle patches and hardensCustomer owns for SOC 2 CC6Compute Engine VMsHypervisor and physical hostsGuest OS patching and hardening, OS-level access, endpoint protection, firewall rules, IAMGKE StandardControl plane, node images (node upgrades depend on the cluster's upgrade settings)Node pool upgrade settings, workload images, Kubernetes RBAC, network policies, IAMGKE AutopilotControl plane and nodes, including node upgradesWorkload images, Kubernetes RBAC, network policies, IAMCloud RunInfrastructure and sandbox. The base image OS and language runtime too, when automatic base image updates are on (Google buildpacks base images only, patched weekly)Container image contents and dependencies, base image patching when automatic updates are off, rebuilds for compiled languages, ingress settings, service identity, IAMCloud SQLOS and database engine patching, within the maintenance window the customer setsDatabase users and grants, `sslMode`, public IP settings, backups and retention, IAMCloud Storage, BigQueryThe whole serviceAccess grants, public access settings, encryption keys, retention, IAM

For SOC 2 evidence, a managed service changes the question an auditor asks. On Compute Engine, the auditor samples OS patch records. On Cloud Run or Cloud SQL, the auditor confirms that Google's SOC 2 report covers the platform, then tests the customer's own settings: automatic base image updates, image scanning, the maintenance window and database access.

## Which GCP Organization Policy constraints support SOC 2 CC6?

Organization Policy is the most efficient CC6 control on Google Cloud because one setting at the organization node applies to every current and future project. An auditor can verify the whole baseline with one export instead of sampling projects.
Org Policy constraintTypeSOC 2 criterionWhat the constraint enforces`iam.allowedPolicyMemberDomains`ListCC6.1, CC6.2IAM grants only to identities from approved Cloud Identity or Workspace customer IDs`iam.disableServiceAccountKeyCreation`BooleanCC6.1, CC6.2No downloadable service account keys`iam.automaticIamGrantsForDefaultServiceAccounts`BooleanCC6.3Default service accounts no longer receive the Editor role automatically`storage.uniformBucketLevelAccess`BooleanCC6.1, CC6.3Bucket access controlled by IAM only, without per-object ACLs`storage.publicAccessPrevention`BooleanCC6.1, CC6.6Cloud Storage data cannot be made public`compute.vmExternalIpAccess`ListCC6.6Only listed VMs may have external IP addresses`compute.requireOsLogin`BooleanCC6.1, CC6.2SSH access to VMs tied to IAM identities instead of project-wide SSH keys`sql.restrictPublicIp`BooleanCC6.6Cloud SQL instances cannot have public IPs`gcp.restrictTLSVersion`ListCC6.7Denies TLS 1.0 and 1.1 (`TLS_VERSION_1`, `TLS_VERSION_1_1`) on supported services`gcp.resourceLocations`ListCC6.7Resources created only in approved regions`cloudkms.minimumDestroyScheduledDuration`ListCC6.5Minimum waiting period before a key version is destroyed

Organizations created on or after May 3, 2024 receive Google's **security baseline constraints** automatically. The set includes the service account key constraints, `iam.allowedPolicyMemberDomains`, `iam.automaticIamGrantsForDefaultServiceAccounts` and `storage.uniformBucketLevelAccess`. Since November 2025, Google applies the newer managed versions (for example `iam.managed.disableServiceAccountKeyCreation`) where they exist. Organizations created before May 2024 receive none of these automatically and need the baseline applied by hand.

Evidence for the auditor is one command per organization, exported at the start of the observation period and again at the end:

```
gcloud org-policies list --organization=ORG_ID --format=yaml
```

## How do you meet SOC 2 CC6.1 logical access security on Google Cloud?

SOC 2 CC6.1 on Google Cloud is met by a single identity source with enforced MFA, a resource hierarchy that separates production, an asset inventory, and customer-managed encryption keys for sensitive data.

Key insight

**Example CC6.1 control on GCP.**

All human access to Google Cloud authenticates through the corporate identity provider with phishing-resistant MFA. Production resources sit in a dedicated folder with Organization Policy constraints enforced at the organization node.
GCP feature for CC6.1Default stateSetting to applyIdentity source: Cloud Identity, Workspace, or Workforce Identity FederationNo federationFederate to the corporate IdP (Okta, Microsoft Entra ID or any SAML 2.0 or OIDC provider). Workforce Identity Federation stores no user accounts in Google Cloud. Keep a small set of break-glass admins in Cloud Identity.MFAGoogle's 2-step verification requirement is phased by account type. Federated users have no announced date.Enforce MFA at the IdP for all users with Google Cloud access. Google's own requirement covers Cloud Identity accounts without SSO from October 20, 2026 for organizations created before August 3, 2026.Resource hierarchyProjects under the organizationA production folder separate from development, with production-only groups and policiesAsset inventoryCloud Asset Inventory is available by defaultScheduled export to BigQuery or Cloud Storage as the CC6.1 inventory recordData classificationOffSensitive Data Protection discovery for BigQuery and Cloud Storage to locate sensitive dataEncryption at restAES-256 with Google-managed keysCustomer-managed encryption keys (CMEK) in Cloud KMS for datasets the risk assessment marks as sensitive

Evidence for SOC 2 CC6.1 on GCP:

- IdP MFA policy export and the federation configuration screenshot
- `gcloud resource-manager folders list --organization=ORG_ID`
- `gcloud asset search-all-resources --scope=organizations/ORG_ID` (or the scheduled export)
- `gcloud kms keys list --keyring=KEYRING --location=LOCATION` for CMEK-protected datasets

The generic requirements and points of focus are covered in [SOC 2 CC6.1: logical access security](/blog/soc-2-cc6-1-logical-access-security).

## How do you meet SOC 2 CC6.2 user and workload registration on Google Cloud?

SOC 2 CC6.2 on Google Cloud requires every person and every workload to be approved before receiving credentials. Grant IAM roles to groups, never to individual users, so the approval record lives in one place: group membership in the IdP, tied to an HR or ticket event.

Key insight

**Example CC6.2 control on GCP.**

Access to Google Cloud is granted only through IdP groups mapped to IAM roles. Group membership changes require an approved ticket. Workloads authenticate with Workload Identity Federation, and service account key creation is disabled.
GCP feature for CC6.2Setting to applyGroup-based IAMIAM bindings reference Google groups or Workforce Identity pool attributes. Direct `user:` bindings are treated as exceptions.CI/CD and external workloadsWorkload Identity Federation for GitHub Actions, GitLab and other CI systems. No exported keys.Service account keys`iam.disableServiceAccountKeyCreation` enforced. Existing keys inventoried and removed.DeprovisioningIdP suspension removes federated access on the next token exchange. Cloud Identity accounts are suspended in the same offboarding ticket.

Evidence for SOC 2 CC6.2 on GCP: a sample of onboarding tickets matched to group membership changes, plus a search for direct user grants that should not exist:

```
gcloud asset search-all-iam-policies --scope=organizations/ORG_ID --query="memberTypes:user"
```

The [CC6.2 user access provisioning guide](/blog/soc-2-cc6-2-user-access-provisioning) and the [onboarding and access review playbook](/blog/soc2-personnel-onboarding-access-reviews-saas-cto) cover the process side.

## How do you meet SOC 2 CC6.3 least privilege on Google Cloud?

SOC 2 CC6.3 on Google Cloud is met by replacing basic roles (Owner, Editor, Viewer) with predefined or custom roles, removing unused permissions, and making privileged access temporary.

Key insight

**Example CC6.3 control on GCP.**

Basic roles are prohibited in production. Production administrative roles are granted only through Privileged Access Manager for a maximum of eight hours with approval. Access is reviewed quarterly, and unused permissions flagged by IAM role recommendations are removed.
GCP feature for CC6.3What the feature doesPredefined and custom rolesScope permissions to the job instead of Owner or EditorIAM role recommendationsFlags permissions unused over a 90-day observation window (30 or 60 days configurable for project-level recommendations)Privileged Access Manager (GA)Just-in-time, time-bound role grants with optional multi-party approval, revoked automatically when the window endsIAM ConditionsTime-bound grants using `request.time` on allow bindingsIAM deny policiesGuardrails evaluated before allow policies, for example denying service account key creation to everyone outside a security group. Deny policies do not support time-based conditions.

Privileged Access Manager produces the strongest CC6.3 evidence on Google Cloud: each elevation has a requester, a justification, an approver and an expiry, all logged. A quarterly access review becomes a review of standing access plus a sample of PAM grants.

Evidence for SOC 2 CC6.3 on GCP:

- Quarterly IAM export (`gcloud asset search-all-iam-policies`) with reviewer sign-off
- Role recommendation history: `gcloud recommender recommendations list --recommender=google.iam.policy.Recommender --project=PROJECT_ID --location=global`
- PAM entitlement configuration and a sample of grant records

The generic least-privilege requirements are in [SOC 2 CC6.3: least privilege and RBAC](/blog/soc-2-cc6-3-least-privilege-rbac).

## Who covers SOC 2 CC6.4 physical access on Google Cloud?

SOC 2 CC6.4 for systems hosted on Google Cloud is inherited: Google operates the data centers, and Google Cloud's SOC 2 Type II report covers physical access to them. Google issues the report quarterly, each covering a rolling 12-month period, with bridge letters in between.

The customer's work for CC6.4 on GCP is documentary:

1. Download the current report from Compliance Reports Manager at the start of the audit.
2. List Google Cloud as a subservice organization in the system description.
3. Review the complementary user entity controls in the report and map each one to a control the company operates.
4. Cover any physical locations still in scope (offices with network equipment, for example) with company controls.

The [complementary user entity controls guide](/blog/soc-2-complementary-user-entity-controls) explains the mapping, and the [CC6.4 physical access guide](/blog/soc-2-cc6-4-physical-access) covers the criterion in general.

## How do you meet SOC 2 CC6.5 asset disposal on Google Cloud?

SOC 2 CC6.5 on Google Cloud is shared. Google sanitizes and destroys failed drives under the controls in Google Cloud's SOC 2 report. The customer owns scheduled deletion of company data, retention where legal or contractual obligations apply, and key destruction when data must become unrecoverable.
GCP feature for CC6.5What the feature doesCloud KMS key destructionDestroying a CMEK key version makes data encrypted with that key unrecoverable. Destruction is scheduled, with a 30-day default waiting period. The period is set when the key is created (24 hours to 120 days) and cannot be changed later.`cloudkms.minimumDestroyScheduledDuration` and `cloudkms.disableBeforeDestroy`Organization-wide guardrails against hasty or accidental key destructionCloud Storage lifecycle rulesAutomatic deletion of objects past the retention scheduleBucket Lock and Object Retention LockRetention that cannot be shortened once locked, for data with legal or contractual hold periods

Evidence for SOC 2 CC6.5 on GCP: the data retention policy, lifecycle rule configurations (`gcloud storage buckets describe gs://BUCKET`), and KMS key version state history for any crypto-shredding events. Laptop and endpoint disposal is outside Google Cloud and needs a separate control. The [CC6.5 asset disposal guide](/blog/soc-2-cc6-5-asset-disposal) covers both.

## How do you meet SOC 2 CC6.6 boundary protection on Google Cloud?

SOC 2 CC6.6 on Google Cloud is met by keeping workloads off the public internet, routing administrative access through Identity-Aware Proxy, and filtering inbound traffic at the load balancer.

Key insight

**Example CC6.6 control on GCP.**

Production VMs and databases have no external IP addresses. Administrative SSH and RDP go through Identity-Aware Proxy. Public applications are exposed only through an external load balancer with a Cloud Armor security policy.
GCP feature for CC6.6Setting to applyExternal IP constraints`compute.vmExternalIpAccess` with an empty or minimal allow list, and `sql.restrictPublicIp`IAP TCP forwardingSSH and RDP to VMs without public IPs. Allow ingress from `35.235.240.0/20` and grant `roles/iap.tunnelResourceAccessor` to an admin group. IAP does not record sessions, so add session logging separately if the audit expects privileged session records.Hierarchical firewall policiesOrganization or folder-level deny rules that project owners cannot overrideCloud ArmorWAF rules and DDoS protection on external Application Load BalancersVPC Service ControlsService perimeters around sensitive projects that block access to Google APIs from outside the perimeter. Perimeters do not block traffic to third-party internet services, so egress firewall rules still apply. Dry-run mode allows testing before enforcement.

Evidence for SOC 2 CC6.6 on GCP:

- `gcloud compute instances list --format='table(name,networkInterfaces[].accessConfigs[].natIP)'` showing no external IPs in production
- `gcloud compute firewall-policies list --organization=ORG_ID`
- `gcloud access-context-manager perimeters list --policy=POLICY_ID`
- Cloud Armor security policy configuration

The general boundary requirements are in [SOC 2 CC6.6: boundary protection](/blog/soc-2-cc6-6-boundary-protection).

## How do you meet SOC 2 CC6.7 data transmission controls on Google Cloud?

SOC 2 CC6.7 on Google Cloud starts with good defaults and two settings that need changing. Google encrypts traffic between users and the Google Front End with TLS and traffic between Google services with ALTS. Two defaults fall short of a typical CC6.7 control: load balancers without an SSL policy accept TLS 1.0, and Cloud SQL accepts unencrypted connections.

Watch out

**Do not rely on Google Cloud load balancer defaults for SOC 2 CC6.7.**

A load balancer with no SSL policy attached uses the COMPATIBLE profile and accepts TLS 1.0, and Cloud SQL accepts unencrypted connections until `sslMode` is changed.
GCP feature for CC6.7DefaultSetting to applyLoad balancer SSL policyCOMPATIBLE profile, TLS 1.0 minimumMODERN or RESTRICTED profile with TLS 1.2 minimum. RESTRICTED is required for a TLS 1.3 minimum. A FIPS_202205 profile is available for FIPS requirements.`gcp.restrictTLSVersion`UnsetDeny `TLS_VERSION_1` and `TLS_VERSION_1_1` organization-wideCloud SQL `sslMode``ALLOW_UNENCRYPTED_AND_ENCRYPTED``ENCRYPTED_ONLY`, or `TRUSTED_CLIENT_CERTIFICATE_REQUIRED` where client certificates are managed (not available for SQL Server)VM-to-VM traffic over external IPsNot automatically encryptedKeep internal traffic on internal IPs, or encrypt at the application`gcp.resourceLocations`UnsetApproved regions only, to restrict data movementVPC Service ControlsOffPerimeter rules on egress from sensitive projects to Google APIs

Evidence for SOC 2 CC6.7 on GCP:

- `gcloud compute ssl-policies list` and `gcloud compute target-https-proxies list --format='table(name,sslPolicy)'`
- `gcloud sql instances describe INSTANCE --format='value(settings.ipConfiguration.sslMode)'`
- The Organization Policy export showing `gcp.restrictTLSVersion` and `gcp.resourceLocations`

The [CC6.7 data transmission guide](/blog/soc-2-cc6-7-data-transmission) covers the criterion beyond Google Cloud.

## How do you meet SOC 2 CC6.8 malicious software prevention on Google Cloud?

SOC 2 CC6.8 on Google Cloud is met by allowing only trusted images to deploy, scanning images for vulnerabilities, hardening VMs at boot, and detecting malicious activity at run time. The split with Google follows the service model: on GKE Autopilot the customer's part is the image contents, on Cloud Run the base image is also the customer's unless automatic base image updates are on, and on Compute Engine the guest OS patching and malware protection are the customer's as well.
GCP feature for CC6.8What the feature doesBinary AuthorizationDeploy-time policy on GKE and Cloud Run that admits only signed or attested images. Continuous validation checks running GKE pods.Artifact AnalysisScans container images on push to Artifact Registry, plus an On-Demand Scanning API for CI pipelinesShielded VMSecure Boot and integrity monitoring for Compute Engine instancesSecurity Command Center threat detectionEvent Threat Detection, Container Threat Detection and VM Threat Detection, available on the Premium tier

Evidence for SOC 2 CC6.8 on GCP: the Binary Authorization policy (`gcloud container binauthz policy export`), vulnerability scan results with remediation tickets, and threat detection findings with their triage records. Laptops need endpoint protection under the same criterion. The [CC6.8 malware prevention guide](/blog/soc-2-cc6-8-malware-prevention) covers endpoints.

## What SOC 2 CC6 evidence do Security Command Center, Wiz and Google SecOps provide?

Security Command Center, Wiz and Google SecOps each produce a different kind of CC6 evidence on Google Cloud. None of them replaces the access reviews, tickets and approvals that make up the rest of a SOC 2 program.
ToolWhat the tool evidences for SOC 2 CC6Notes for GCP teamsSecurity Command CenterMisconfiguration findings from Security Health Analytics, threat detection (Premium), and Compliance Manager posture against a built-in SOC 2 2017 frameworkCompliance Manager is GA and the SOC 2 framework requires Premium. The Enterprise tier is deprecated and shuts down on or after May 21, 2027, so Premium is the tier to plan around. Google describes the compliance mappings as best effort.WizAgentless posture and vulnerability findings mapped to a SOC 2 framework, across GCP, AWS and AzureGoogle completed the Wiz acquisition in March 2026, and Wiz keeps a multi-cloud product. Useful when the SOC 2 scope spans more than one cloud.Google SecOpsDetection on identity and access events: IAM role grants, service account key creation, firewall changesDirect ingestion sends Admin Activity and System Event audit logs by default, with Data Access logs optional. Ingestion starts when enabled and does not backfill, so enable ingestion before the observation period begins.

A posture tool proves that a setting is in place on the day of the scan. An auditor testing CC6 over a Type II window also wants proof that access was approved, reviewed and removed on time, and that evidence comes from tickets, review sign-offs and the IdP. The posture findings feed the program, and the program produces the rest. CC7, the next post in this series ([SOC 2 system operations on GCP](/blog/soc-2-cc7-gcp)), covers the monitoring and incident response side of Security Command Center and Google SecOps.

## In what order should SOC 2 CC6 controls be rolled out on Google Cloud?

The order below puts the controls with the widest coverage first, so most CC6 evidence exists before the observation period starts.

1. **Federate identity and enforce MFA at the IdP.** Covers CC6.1 and CC6.2 for every human user at once.
2. **Apply the Organization Policy baseline at the organization node.** Check which security baseline constraints already apply if the organization dates from after May 2024, and add the rest from the baseline table.
3. **Grant IAM through groups and remove basic roles in production.** Export the current IAM state first so the change is documented.
4. **Turn on Privileged Access Manager for production admin roles.** Standing admin access becomes the exception.
5. **Remove external IPs and route admin access through IAP.** Then set SSL policies and Cloud SQL `sslMode`.
6. **Enable Security Command Center Premium or Wiz, and start Google SecOps ingestion.** Posture and detection evidence then accumulates from day one of the window.
7. **Download Google's SOC 2 report and map the complementary user entity controls.** Closes CC6.4 and the inherited part of CC6.5.

### Get SOC 2 CC6 right on GCP

Truvo builds and operates the effective security program behind the GCP settings and audit evidence.[Book Your Strategy Call](/contact-us)

For the IAM side of a Google Cloud baseline beyond SOC 2, [Google Cloud IAM best practices](/blog/google-cloud-iam-best-practices) lists 10 controls to check, with CIS benchmark references and Security Command Center findings.

## Frequently asked questions about SOC 2 on Google Cloud

### Is Google Cloud SOC 2 compliant?

Google Cloud holds SOC 2 Type II reports, issued quarterly and each covering a rolling 12-month period. Google's report covers Google's controls, including data center physical security. A company running on GCP still needs a separate SOC 2 report covering the company's system, and inherits CC6.4 and part of CC6.5 from Google's report.

### Which GCP Organization Policy constraints does SOC 2 require?

SOC 2 names no specific GCP settings. The AICPA criteria are technology-neutral. A common CC6 baseline on GCP includes domain-restricted sharing, disabled service account key creation, uniform bucket-level access, public access prevention, external IP restrictions, OS Login, a TLS version restriction and approved resource locations.

### Does Security Command Center replace a SOC 2 audit or a GRC platform?

Security Command Center Compliance Manager shows posture against a SOC 2 framework, and Google describes the mappings as best effort. A SOC 2 report comes only from an independent CPA firm. A GRC platform such as Vanta or Drata tracks policies, people and evidence beyond cloud configuration, so the tools complement each other.

### Are VPC Service Controls required for SOC 2?

VPC Service Controls are a risk-based choice for SOC 2 on Google Cloud. They fit projects holding sensitive data in BigQuery or Cloud Storage, where exfiltration through Google APIs is a real risk. Perimeters block cross-perimeter API access and leave third-party internet traffic to firewall rules.

### How do I get Google Cloud's SOC 2 report?

Google Cloud's SOC 2 Type II report is available in Compliance Reports Manager to Google Cloud customers. Google posts a new report each quarter, plus bridge letters. Product-specific SOC 2 reports are issued less often and are requested through Google sales or support.

## Sources

- AICPA Trust Services Criteria (TSC section 100), 2017, revised points of focus 2022
- [Google Cloud SOC 2 report cadence](https://cloud.google.com/security/compliance/soc-2)
- [Shared responsibilities and shared fate](https://docs.cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate)
- [Shared fate](https://cloud.google.com/security/shared-fate)
- [GKE shared responsibility](https://docs.cloud.google.com/kubernetes-engine/docs/concepts/shared-responsibility)
- [Cloud Run automatic base image updates](https://docs.cloud.google.com/run/docs/configuring/services/automatic-base-image-updates)
- [Organization Policy constraints](https://docs.cloud.google.com/organization-policy/reference/org-policy-constraints)
- [Security baseline constraints](https://docs.cloud.google.com/resource-manager/docs/manage-baseline-constraints)
- [2-step verification requirement](https://docs.cloud.google.com/docs/authentication/mfa-requirement)
- [Workforce Identity Federation](https://docs.cloud.google.com/iam/docs/workforce-identity-federation)
- [Privileged Access Manager](https://docs.cloud.google.com/iam/docs/pam-overview)
- [IAM deny policies](https://docs.cloud.google.com/iam/docs/deny-overview)
- [Role recommendations](https://docs.cloud.google.com/policy-intelligence/docs/role-recommendations-overview)
- [Cloud KMS key destruction](https://docs.cloud.google.com/kms/docs/destroy-restore)
- [Bucket Lock / Object Retention Lock](https://docs.cloud.google.com/storage/docs/bucket-lock)
- [Default encryption at rest / in transit](https://cloud.google.com/docs/security/encryption/default-encryption)
- [SSL policies](https://docs.cloud.google.com/load-balancing/docs/ssl-policies-concepts)
- [Cloud SQL SSL modes](https://docs.cloud.google.com/sql/docs/mysql/configure-ssl-instance)
- [IAP TCP forwarding](https://docs.cloud.google.com/iap/docs/tcp-forwarding-overview)
- [VPC Service Controls](https://docs.cloud.google.com/vpc-service-controls/docs/overview)
- [Binary Authorization](https://docs.cloud.google.com/binary-authorization/docs/overview)
- [Artifact Analysis](https://docs.cloud.google.com/artifact-registry/docs/analysis)
- [SCC service tiers and deprecations](https://docs.cloud.google.com/security-command-center/docs/service-tiers)
- [SCC Compliance Manager frameworks](https://docs.cloud.google.com/security-command-center/docs/compliance-manager-frameworks)
- [Google SecOps Google Cloud ingestion](https://docs.cloud.google.com/chronicle/docs/ingestion/default-parsers/ingest-gcp-logs)
- [Sensitive Data Protection discovery](https://docs.cloud.google.com/sensitive-data-protection/docs/data-profiles)
- [Wiz compliance](https://www.wiz.io/solutions/compliance)

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Is Google Cloud SOC 2 compliant?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Google Cloud holds SOC 2 Type II reports, issued quarterly and each covering a rolling 12-month period. Google's report covers Google's controls, including data center physical security. A company running on GCP still needs a separate SOC 2 report covering the company's system, and inherits CC6.4 and part of CC6.5 from Google's report."
      }
    },
    {
      "@type": "Question",
      "name": "Which GCP Organization Policy constraints does SOC 2 require?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "SOC 2 names no specific GCP settings. The AICPA criteria are technology-neutral. A common CC6 baseline on GCP includes domain-restricted sharing, disabled service account key creation, uniform bucket-level access, public access prevention, external IP restrictions, OS Login, a TLS version restriction and approved resource locations."
      }
    },
    {
      "@type": "Question",
      "name": "Does Security Command Center replace a SOC 2 audit or a GRC platform?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Security Command Center Compliance Manager shows posture against a SOC 2 framework, and Google describes the mappings as best effort. A SOC 2 report comes only from an independent CPA firm. A GRC platform such as Vanta or Drata tracks policies, people and evidence beyond cloud configuration, so the tools complement each other."
      }
    },
    {
      "@type": "Question",
      "name": "Are VPC Service Controls required for SOC 2?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "VPC Service Controls are a risk-based choice for SOC 2 on Google Cloud. They fit projects holding sensitive data in BigQuery or Cloud Storage, where exfiltration through Google APIs is a real risk. Perimeters block cross-perimeter API access and leave third-party internet traffic to firewall rules."
      }
    },
    {
      "@type": "Question",
      "name": "How do I get Google Cloud's SOC 2 report?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Google Cloud's SOC 2 Type II report is available in Compliance Reports Manager to Google Cloud customers. Google posts a new report each quarter, plus bridge letters. Product-specific SOC 2 reports are issued less often and are requested through Google sales or support."
      }
    }
  ]
}