PCI DSS on Google Cloud (GCP) — The QSA's Guide to Cloud Compliance

Does Hosting on Google Cloud Make You PCI Compliant?

No — and the reasons are the same as for every other hyperscale provider. Google Cloud Platform is a validated PCI DSS Level 1 Service Provider. An independent QSA has assessed GCP against PCI DSS v4.0.1, and Google publishes an Attestation of Compliance (AOC) to customers through Compliance Reports Manager. That validation covers the physical data centres, the underlying infrastructure, and the platform services Google operates. It does not cover anything you build, configure, or deploy on top of them.

PCI DSS in the cloud follows a shared responsibility model. Google is responsible for the security of the cloud; you are responsible for security in the cloud. Where that line falls depends on the service model you use:

Google formalises this split in the Google Cloud Platform PCI DSS v4.0.1 Shared Responsibility Matrix — a requirement-by-requirement mapping across its Compute, Networking, Storage, and Security & Identity product categories, published as a public PDF and referenced from the Google Cloud PCI DSS compliance page. Your QSA will use it to decide which controls can be inherited from Google's AOC and which must be evidenced from your environment. A useful discipline: for every requirement marked "shared", write down what Google's half covers and what yours must show. That list becomes the skeleton of your evidence request.

Scoping Your Cardholder Data Environment in Google Cloud

Scoping determines cost and effort more than any other decision, and Google Cloud's resource hierarchy gives you good tools for it if you use them deliberately. In GCP, your cardholder data environment (CDE) is defined by projects, VPC networks, service perimeters, and identity bindings rather than physical network segments. Four practices consistently produce a clean, defensible scope:

Dedicated projects and a dedicated folder for the CDE. Placing cardholder data workloads in their own projects, grouped under a folder in the organisation hierarchy, creates a natural assessment boundary. IAM policies, Organization Policy constraints, and log sinks can then be applied at the folder level and inherited downward, which is far easier to evidence than per-resource settings scattered across a shared project.

Segmentation with VPC firewall rules, Shared VPC, and Cloud Armor. VPC firewall rules and hierarchical firewall policies replace the physical firewalls of on-premises segmentation, and Cloud Armor fronts internet-facing services. In a Shared VPC design, the host project's network team controls the segmentation that the CDE service projects depend on — so the host project is in scope too. The PCI DSS rule is unchanged in the cloud: any system that can reach the CDE is in scope, and default-allow rules or broad peering are the cloud version of a flat network. Segmentation must still be verified by penetration testing.

VPC Service Controls and Private Google Access. Google-managed services such as Cloud Storage, BigQuery, and Cloud SQL are reached over Google's API endpoints rather than through your VPC, so firewall rules alone do not constrain them. VPC Service Controls let you define a service perimeter around CDE projects so that data in those services cannot be read from outside the perimeter, and Private Google Access keeps that traffic off the public internet. Both are strong scoping controls when they exist, and their absence is a common reason a "small" CDE turns out to be reachable from far more places than the diagram shows.

Identity as a scope boundary. In cloud environments, identity is the perimeter. Every principal with a role binding on CDE projects — users, Google Groups, service accounts, and workload identities — is part of the assessment. Basic roles (Owner, Editor, Viewer) granted at project or folder level, and service accounts with keys that were downloaded and never rotated, are the identity findings we encounter most often when reviewing Google Cloud environments.

The PCI Security Standards Council's cloud computing guidance covers these principles in provider-neutral terms — see the PCI SSC document library for the Cloud Computing Guidelines information supplement. Google also publishes a reference architecture for PCI DSS compliance on Google Cloud and a separate guide for PCI DSS on GKE, both of which are worth reading before you draw your scope diagram rather than after.

Mapping PCI DSS v4.0.1 Requirements to Google Cloud Services

The table below is the mapping our assessors use as a starting point in Google Cloud engagements — which native service typically satisfies each requirement family, and what evidence the QSA will ask for. It is not exhaustive, but it covers where the bulk of assessment effort goes.

Two requirement families remain almost entirely yours regardless of which Google Cloud services you adopt: Requirement 9 (physical security) is inherited from Google's AOC for the data centres but still applies to your own offices and media, and Requirement 12 (policies, risk assessments, training, incident response) has no cloud service that can do it for you.

The Google Cloud Gaps Our QSAs Find Most Often

The findings that recur when our QSAs assess cloud-hosted cardholder data environments translate directly to Google Cloud, and in the GCP-hosted environments we have reviewed the same pattern holds — almost none of them are platform problems. They are configuration, identity, and process gaps:

1. The default Compute Engine service account still holds the Editor role. Unless an Organization Policy disables it, new projects grant the default Compute Engine service account the Editor basic role, and every VM that runs as that account inherits it. In a CDE that means a compromised workload can modify most resources in the project. Requirement 7 expects least privilege by job function; a dedicated service account per workload with narrowly scoped predefined or custom roles is the expected pattern.

2. Data Access audit logs disabled, or retention shorter than twelve months. Admin Activity audit logs are always on and kept for 400 days in the _Required log bucket, which is why teams assume logging is covered. Data Access audit logs — the ones that record reads of cardholder data in Cloud Storage, Cloud SQL, or BigQuery — are off by default for most services, and when they are enabled they land in the _Default bucket with 30-day retention. Requirement 10 expects twelve months of audit trail history with three months immediately available. This one fails quietly, and it is the finding we would check first.

3. Over-broad basic roles and project-wide SSH keys. Owner and Editor bindings granted at project or folder level during migration and never revisited, and project-level SSH metadata keys that grant login to every instance in the project. Both are the cloud equivalent of shared administrative accounts, and both are straightforward to find with IAM Recommender and Cloud Asset Inventory before the assessor does.

4. GKE clusters with a public control plane, no network policy, and untested segmentation. Kubernetes changes the segmentation question. A cluster in the CDE with a public control-plane endpoint, no Kubernetes network policy between namespaces, and nodes running as the default service account expands scope to everything that can reach the API server and everything else on the cluster. Private clusters, network policy, Workload Identity, and Binary Authorization are the controls QSAs look for, and segmentation inside the cluster must be penetration-tested like any other segmentation control.

5. Shadow cardholder data in Cloud Storage buckets and BigQuery exports. Application exports, diagnostics, backups, and analytics extracts routinely contain live PANs, and buckets with allUsers or allAuthenticatedUsers bindings still appear in environments that believe they have no public data. Every copy expands scope. Sensitive Data Protection (formerly Cloud DLP) can find these systematically, and the Organization Policy constraint that enforces public-access prevention on Cloud Storage removes the most damaging version of the finding entirely.

None of these are exotic. They are the cloud translations of the classic on-premises findings, and they are all avoidable with a pre-assessment gap analysis — see our breakdown of what PCI DSS compliance actually costs for why finding them early matters.

PCI DSS on AWS, Azure, Alibaba Cloud and in Multi-Cloud Environments

The shared responsibility model is conceptually identical across the major providers — each is a validated PCI DSS Level 1 service provider, each publishes a responsibility matrix, and each leaves configuration, identity, logging, and application security to you. The service names change (VPC firewall rules for Security Groups or NSGs, Cloud IAM for AWS IAM or Entra ID, Cloud Audit Logs for CloudTrail or Activity Logs, Security Command Center for Security Hub or Defender for Cloud), but the assessment approach does not. For the provider-specific versions of this guide, see PCI DSS on AWS, PCI DSS on Azure, and PCI DSS on Alibaba Cloud. Our hub guide, PCI DSS in the Cloud: AWS, Azure, GCP and Alibaba Cloud Compared, puts the four side by side.

Multi-cloud environments deserve one specific warning: each provider's controls only cover its own platform. A tokenisation service in AWS does not descope a BigQuery dataset in Google Cloud, and centralised logging must actually centralise — a SIEM that ingests Cloud Audit Logs but not CloudTrail leaves a Requirement 10 gap. In our experience, multi-cloud CDEs are best assessed with a single consolidated scope document that maps every requirement to the specific control in each platform, rather than treating each cloud as a separate assessment. Evidence collection should follow the same principle: one evidence set, organised by requirement, regardless of how many consoles it came from.

Automating Google Cloud Evidence Collection

The most labour-intensive part of a cloud PCI DSS assessment is not implementing controls — it is proving them. Traditional evidence collection means screenshots: IAM pages for role bindings, Cloud Logging pages for bucket retention, firewall rule lists, SCC finding views, captured one by one, dated, and filed against requirements. For a Level 1 environment this consumes weeks, and the evidence is stale the moment it is captured.

Google Cloud makes a better approach practical because almost everything a QSA needs is exportable in a structured form: IAM policies via gcloud or Cloud Asset Inventory, firewall rules and Organization Policy constraints as exports, Cloud Audit Logs through log sinks, and Security Command Center findings through its API. The discipline is to collect those exports on a schedule, tie each one to the requirement it evidences, and keep the history so the assessor can see the control operating over time rather than on the day of the screenshot.

This is the workflow EIC built Complium around. Complium has native read-only integrations for Microsoft Azure (Microsoft Entra ID, Azure Activity Logs, Microsoft Defender for Cloud) and AWS (IAM, CloudTrail, Security Hub, Config), where evidence is pulled from the environment directly. For Google Cloud environments there is not yet a native connector: exported Cloud Audit Logs, IAM policy exports, and Security Command Center findings are uploaded into Complium as evidence, mapped to PCI DSS v4.0.1 requirements by the same engine, and reviewed by the QSA inside the platform that produces the Report on Compliance. Native read-only Google Cloud connectors are on the product roadmap, and we would rather say that plainly than imply a connector that is not live.

Because Complium is built and operated by a PCI QSA Organisation, the platform and the assessor who signs your validation come from the same accountable provider. Complium is available directly and through the Microsoft Marketplace.

Frequently Asked Questions

If you are planning a PCI DSS assessment for a Google Cloud-hosted environment, our PCI DSS compliance assessment service covers scoping, gap analysis, and the full ROC or SAQ engagement — and our complete PCI DSS guide covers the standard itself in depth.