Supporting compliance requirements · Topic 1 of 2
Shared Responsibility, Compliance Scope and Control Mapping
Apply the shared responsibility model on Google Cloud, set the compliance scope, find technical needs and map regulations to Google Cloud controls.
- 5 min
- Google secures the infrastructure; you always own identity, access, configuration and data.
- IaaS leaves the OS to you; PaaS moves the runtime to Google.
- Use only services in scope for the certification, and sign a BAA for HIPAA.
What it is
Moving to Google Cloud does not move compliance to Google. Google certifies its infrastructure and services, and you remain responsible for how you configure and use them. The engineer's job is to know which part is whose, which systems a regulation covers, and which Google Cloud controls meet each requirement.
How it works
The shared responsibility model
| Layer | IaaS (Compute Engine) | PaaS (Cloud Run, App Engine) | SaaS (Google Workspace) |
|---|---|---|---|
| Physical data centers, hardware, global network | |||
| Hypervisor and host OS | |||
| Guest OS, patching, runtime | You | ||
| Application code | You | You | |
| Network configuration, firewall rules | You | Mostly you | |
| Identity, access and IAM | You | You | You |
| Data classification, encryption key choices | You | You | You |
The more managed the service, the more Google handles, but identity, access and data are always yours. Google describes its approach as shared fate: it also provides secure defaults, blueprints and guidance to help you meet your share.
Evidence from Google
| Resource | Use |
|---|---|
| Compliance Reports Manager | Download Google's third-party audit reports and certificates, such as ISO/IEC 27001, SOC 2 and PCI DSS attestations |
| Services in scope lists | Check that every service you use is covered by the certification you rely on |
| Business Associate Agreement (BAA) | Required before storing protected health information under HIPAA; use only covered services |
A service being available in Google Cloud does not mean it is in scope for a given certification. The exam often hides a non-covered service in an otherwise correct answer.
Determining technical needs
| Area | Typical regulatory needs | Google Cloud features |
|---|---|---|
| Compute | Hardened, patched systems; sometimes dedicated hardware | Golden images, VM Manager patching, Shielded VM, Confidential VM, sole-tenant nodes |
| Data | Classification, encryption, key control, minimisation | Sensitive Data Protection, CMEK, Cloud HSM, Cloud EKM, tokenization |
| Network | Segmentation, encrypted transmission, restricted internet exposure | Separate VPCs, firewall policies, VPC Service Controls, TLS, HA VPN, MACsec |
| Storage | Location, retention, immutability, deletion | Resource locations policy, retention policies, Bucket Lock, lifecycle rules |
Determining the environment in scope
The scope is every system that stores, processes or transmits regulated data, plus the systems that can affect their security. Shared services such as identity, CI/CD and logging often fall in scope because they connect to regulated workloads.
Reduce scope deliberately:
- Put regulated workloads in a dedicated folder, projects and VPC network.
- Draw a VPC Service Controls perimeter around them.
- Tokenize data such as card numbers with Sensitive Data Protection so downstream systems never hold the real values.
- Restrict who can administer the regulated folder.
A smaller scope means fewer systems to audit and fewer controls to prove.
Mapping requirements to controls
| Requirement (paraphrased) | Google Cloud control |
|---|---|
| Restrict access to data by business need | IAM groups and least-privilege roles, PAM for elevated access, VPC Service Controls |
| Segment regulated systems from others | Separate projects and VPCs, hierarchical firewall policies, no peering to untrusted networks |
| Log and review all access to regulated data | Data Access audit logs, aggregated sinks, alerts, Log Analytics |
| Keep audit logs for a set period and protect them | Locked log buckets or Cloud Storage with Bucket Lock, separate logging project |
| Encrypt stored data and control keys | CMEK, Cloud HSM or Cloud EKM, with key rotation |
| Encrypt data over public networks | TLS with SSL policies, HA VPN, MACsec |
| Keep data in a country or region | gcp.resourceLocations, Assured Workloads |
| Manage vulnerabilities | Artifact Analysis, VM Manager, Security Health Analytics |
| Continuously show compliance | Security Command Center Premium compliance reports and security posture |
PCI DSS, for example, requires audit log history of at least one year, with the last three months immediately available. That maps to a locked log bucket or archive with matching retention.
A worked example
A retailer must meet PCI DSS for online payments. The engineer limits scope by placing the payment service in its own folder, project and VPC, inside a perimeter, and tokenizing card numbers with Sensitive Data Protection so the analytics platform never sees real numbers.
Every control is mapped in a matrix: IAM groups and PAM for access, Data Access logs into a locked bucket for one year, CMEK on storage, and SCC Premium PCI DSS reports for continuous evidence. Google's PCI DSS attestation from Compliance Reports Manager covers the infrastructure layer.
How the exam asks about this
- "Who is responsible for patching the operating system of Compute Engine VMs?" The customer, because Compute Engine is IaaS.
- "Reduce the number of systems in PCI DSS scope while analysts still analyze purchases." Tokenize card data with Sensitive Data Protection and isolate the payment environment.
- "An auditor asks for evidence that Google's data centers meet ISO 27001." Download the report from Compliance Reports Manager.
What to remember for the exam
- Google secures the infrastructure; you always own identity, access, configuration and data.
- IaaS leaves the OS to you; PaaS moves the runtime to Google.
- Use only services in scope for the certification, and sign a BAA for HIPAA.
- Shrink scope with isolation and tokenization before mapping controls.
- Map each requirement to a specific control and to the evidence that proves it.
Google's certifications cover Google's part only. A certified platform with a public bucket or an open firewall still fails your audit.
Common mistakes
Assuming a managed service makes you compliant. Managed services shift infrastructure work, not your duty to set access, keys and logging correctly.
Leaving shared services out of scope. CI/CD, identity and logging systems that touch regulated workloads can change them, so assess them too.
Mapping requirements to products, not evidence. Auditors need proof the control works, such as logs and reports, not just a product name.
Check yourself
Under the shared responsibility model, which layer is always the customer's?
Identity and access management, configuration of services, and the data itself, whatever the service model.
How can tokenization reduce PCI DSS scope?
Downstream systems store tokens instead of card numbers, so they no longer handle cardholder data.
Where do you obtain Google's third-party audit reports?
From Compliance Reports Manager.
Topic 1 of 2 in Supporting compliance requirements
Test yourself on Supporting compliance requirements
The full Google Cloud Professional Cloud Security Engineer question bank has 749 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Google Cloud. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.