Supporting compliance requirements

Shared responsibility and shared fate

Google secures the infrastructure: facilities, hardware, the hypervisor, the global network and the managed service platforms. The customer secures what they configure and put on it: identities and IAM, data classification, network rules, encryption choices, guest OS and application code for IaaS, and logging.

• Google’s compliance certifications cover Google’s part. They do not make your workload compliant. You still must configure controls and keep your own evidence.
• Shared fate is Google’s term for going beyond division of tasks: secure-by-default settings, blueprints (the security foundations blueprint), landing-zone guidance, and the Risk Protection Program (cyber insurance backed by the posture data you share). Don’t confuse it with shared responsibility: it describes Google’s help, not a transfer of your duties.
• Customers remain the data controller under privacy laws. Google acts as processor under the Cloud Data Processing Addendum.

Scoping and technical needs

Start every compliance design by deciding what is in scope.

1. Identify regulated data and systems: the cardholder data environment for PCI DSS, protected health information for HIPAA, controlled data for government regimes, personal data of EU residents for GDPR.
2. Draw the boundary in the resource hierarchy: put regulated workloads in their own folder and projects (or an Assured Workloads folder), their own VPC, and their own logging and key projects. A smaller, well-segmented scope means a smaller audit.
3. Check product coverage. Only certain services are covered by a given attestation or by a Business Associate Agreement. Use the Compliance Resource Center and the list of covered products, and block others with an organization policy (gcp.restrictServiceUsage) or Assured Workloads restrictions.
4. Translate to technical needs by layer:

Assured Workloads

Assured Workloads creates a workload (a folder with enforced controls) for a compliance regime, so you don’t have to hand-build guardrails.

• Regimes include FedRAMP Moderate and High, CJIS, IL2, IL4 and IL5 for US government, ITAR, HIPAA and HITRUST, plus regional and sovereignty packages (for example EU data boundary and sovereign controls, Canada, Australia, Japan, Israel, Saudi Arabia). Availability varies, so check the current list.
• What it configures: resource location restrictions, a restricted set of allowed services for the regime, CMEK/key requirements, personnel and support controls (for instance support only from US persons or EU staff), and enablement of Access Approval and Access Transparency where applicable.
• It applies the controls through organization policies on the folder, so projects inside inherit them. It does not create VPC Service Controls or network rules for you. Design those yourself.
• Monitoring: Assured Workloads reports compliance violations when a policy or setting drifts (a resource in a disallowed location, a changed organization policy) and suggests fixes. You can acknowledge or restore.
• Choose Assured Workloads when a regulation names a Google-supported regime or requires personnel controls, and a plain folder with org policies when only data location or CMEK is needed.

Access Transparency, Access Approval and key justification

By default Google staff cannot read your content, except limited cases. These controls give you visibility and control over the exceptions.

Rule of thumb: Transparency = see it, Approval = allow it, KAJ and EKM = control the key behind it.

Data residency and regionalisation

• The gcp.resourceLocations organization policy restricts where supported resources can be created. Use value groups such as in:eu-locations or in:us-locations, or specific regions. It applies at organization, folder or project level, doesn’t move existing resources, and covers only supported services (check the list). Resources can be regional, dual-region, multi-region or global, and multi-region location names in your policy must match the intended geography.
• Pick regional services and buckets for tight residency, and avoid global resources for regulated data. Note that some metadata stays global (IAM policies, project metadata).
• Data residency is not the same as sovereignty. Sovereignty adds control over who accesses data (personnel controls, Access Approval, EKM held in-country, Assured Workloads sovereign controls, and partner-operated clouds).
• Cross-border transfers (GDPR): use the data processing terms and standard contractual clauses, restrict locations, keep logs and backups in the same region too, and watch default multi-region choices (BigQuery datasets, Cloud Storage buckets, log buckets).
• Make backups, log buckets, key rings (KMS location must match), and Pub/Sub message storage policies follow the same location rule. Pub/Sub has a message storage policy that restricts where messages are stored.

Mapping regulations to controls

Network and access segmentation in detail

For regulated segments: place the regulated VPC in its own host project, allow traffic only through firewall policy rules that name approved sources, deny everything else, and use VPC-SC so even valid credentials cannot move data to a project outside the perimeter. Use separate Cloud Identity groups for in-scope admins, PAM for elevation, and Context-Aware Access to require managed devices. Verify with Network Intelligence Center connectivity tests and Firewall Insights.

Audit log coverage

Compliance auditors want a complete, tamper-resistant, retained trail.

• Turn on Data Access logs for all in-scope services (they are off by default), cover ADMIN_READ, DATA_READ and DATA_WRITE, and exempt only noisy non-human accounts.
• Export through an organization-level aggregated sink to a locked log bucket or a Cloud Storage bucket with retention lock, so neither project owners nor attackers can erase it.
• Retain for the longest period any regulation in scope requires. Admin Activity in _Required is kept 400 days only, so export if you need longer.
• Keep Access Transparency logs, VPC Flow Logs (if segmentation evidence is needed), DNS logs, and SCC findings for incident evidence.
• Restrict who reads and deletes them, with separation of duties between those who run the platform and those who manage logs.

Evidence, reports and assurance tools

Choosing the control

Common traps

• A Google certification does not make your application compliant.
• Resource-location policy stops new resources only, and not every service honours it.
• Assured Workloads doesn’t configure VPC-SC or firewall rules.
• Access Approval requires Access Transparency, and approval is not unlimited, because it expires.
• Data Access logs must be on before you need them.
• A regional bucket with a multi-region KMS key (or the reverse) can break residency.
• Residency (where data sits) is not sovereignty (who can reach it).