SOC 2 on Google Cloud: shared responsibility and mapping native services to controls
Google Cloud carries its own SOC 2 as your infrastructure provider, but your account configuration is what an auditor actually tests. Here is how GCP's native services line up with the Trust Services Criteria.
Google Cloud carries its own SOC 2, but yours is separate
Google Cloud Platform publishes SOC 1, SOC 2, and SOC 3 reports covering its global infrastructure: physical data centers, custom hardware, the network backbone, and the base operating layer beneath managed services. For your own SOC 2, GCP is a subservice organization, meaning its report attests to the security of the cloud while your controls govern everything in the cloud. Hosting on Google Cloud gives you a strong foundation and a credible vendor to point to, but it does not satisfy a single Trust Services Criterion on your behalf. Your auditor evaluates how you configured IAM, networking, logging, and encryption inside your projects, not what Google does in its data centers.
Where the responsibility line sits on GCP
Google describes responsibility as sliding with the service model: more falls to you on Compute Engine, less on managed offerings like Cloud Run, GKE Autopilot, or BigQuery, but identity, data, and configuration always remain yours. You own the resource hierarchy of organization, folders, and projects, and the Organization Policy constraints that enforce guardrails across them. You decide whether to use Google-managed or customer-managed encryption keys, how IAM bindings are scoped, and where VPC Service Controls draw perimeters around sensitive data. Mapping each Common Criteria area to the correct side of this line before fieldwork is worthwhile, because auditors expect you to explain the division rather than assume GCP covers it.
Mapping native services to Trust Services Criteria
GCP's security primitives align closely with the Common Criteria. Cloud IAM, with least-privilege roles, conditional bindings, and avoidance of broad primitive roles like Owner, supports logical access under CC6, and enforcing MFA and SSO through Cloud Identity strengthens it. Cloud Logging, including Admin Activity and Data Access audit logs, plus Cloud Monitoring alerting, addresses the logging and detection expectations of CC7. Cloud KMS, with key rotation and separation of duties, underpins encryption at rest. Security Command Center provides posture management, vulnerability findings, and threat detection across the organization, and its Compliance Manager can evaluate resources against control frameworks. VPC Service Controls reduce data-exfiltration risk, and Backup and DR or scheduled snapshots support availability if you scope that criterion in.
The carve-out method for Google Cloud
Like virtually all cloud-hosted companies, GCP-native teams use the carve-out method: your system description identifies Google Cloud as a subservice organization and excludes Google's controls from your auditor's testing, since Google will not be tested by your auditor. The carve-out obliges you to document the controls you depend on Google to perform, the complementary subservice organization controls relevant to your system, and your own ongoing oversight of Google as a vendor. Concretely, retrieve Google Cloud's SOC 2 report through Compliance Reports Manager at least annually, review it for exceptions and confirm the reporting period covers your audit window, and keep evidence that the review happened. A bridge letter from Google may be needed to span any gap between its report period and yours.
Practical guidance for GCP-native teams
Begin by hardening the resource hierarchy: set Organization Policy constraints to block public IPs, restrict service-account key creation, and enforce uniform bucket-level access, because hierarchy-level guardrails are far easier to evidence than per-project fixes. Enable Security Command Center at the organization level and route audit logs to a dedicated, access-controlled log bucket with retention that meets your Type 2 window. Use VPC Service Controls around projects holding regulated or customer data, and prefer customer-managed keys where contracts or customers expect them. Because a Type 2 examination tests operating effectiveness over months, the priority is consistent, drift-free configuration sustained across the period, supported by continuous monitoring rather than a pre-audit scramble.