Chapter 30

Common Compliance Frameworks

Scope. This chapter maps frameworks to Google Cloud. For each, it states the current version, what Google actually attests to, where the customer's responsibility begins, and which GCP service satisfies the requirement — by section number. It re-teaches no control. Chapter 29 owns producing evidence; §30.11 owns mapping an artifact to a control. Nothing here is legal advice, and no framework is summarized in enough depth to substitute for reading it. Prerequisites. Chapter 29 (evidence), Chapter 16 (Security Command Center), Chapter 31 (the organization baseline). Verified against. Google Cloud console and API surface as of 2026-09, Cloud SDK 583.0.0; framework versions confirmed as noted; see sources at end.

A framework is a list of assertions someone else will test. The engineering question is which GCP control makes each assertion true and which artifact demonstrates it — and that mapping is mostly stable, while the frameworks' version numbers are not.

Version currency is the failure mode this chapter is written against. A control mapping built against PCI DSS v3.2.1 or NIST CSF 1.1 is not slightly stale; it is aligned to a document the assessor is not using. Every version number below was confirmed rather than recalled, and where confirmation failed the chapter says so instead of guessing.

One structural warning applies throughout. Google's own compliance tooling lags the published standards, sometimes by several versions. That gap is not a defect to work around silently — it is a fact your control mapping has to account for, and §30.9 is where it is sharpest.

Two things Google supplies and two it does not. It supplies its own certifications (§29.1) and a set of products that enforce or report against standards (§30.10). It does not supply your control implementation, and it does not supply your evidence. Every row in this chapter's tables that reads as a GCP service is a control you configure.

30.1 SOC 2 §

SOC 2 is an attestation by an independent auditor against the AICPA Trust Services Criteria, not a certification and not a pass/fail standard.

The five Trust Services Criteria categories are Security, Availability, Processing Integrity, Confidentiality, and Privacy. Only Security is mandatory; the rest are in scope if you claim them, which is a scoping decision rather than a technical one.

Type I versus Type II is the distinction that matters. Type I attests that controls were suitably designed at a point in time; Type II attests that they operated effectively over a period, typically six to twelve months. Type II is what customers ask for, and it is the reason §29.2's schedule exists: a period report needs evidence from the whole period.

Google issues Type II reports on a quarterly cycle, available through Compliance Reports Manager. The SOC 3 report is public; the SOC 1 and SOC 2 reports require an account relationship to obtain.

What the customer owns, and what a SOC 2 auditor will spend the engagement on:

Pitfall. SOC 2 has no prescribed control list, which teams read as flexibility and auditors read as an obligation to justify every choice. The absence of a checklist means the evidence has to explain why a control is sufficient, and that reasoning is the deliverable.

30.2 ISO 27001 §

ISO/IEC 27001 certifies an information security management system — a process for managing risk — rather than a set of technical controls.

The current revision is ISO/IEC 27001:2022, whose Annex A was restructured into four themes: organizational, people, physical, and technological. Google's own control identifiers follow that structure.

Google holds several related certifications and they answer different questions:

The processor-versus-controller distinction in 27701 is load-bearing. Google certifies as a processor; the controller obligations — deciding what personal data is collected and why — remain yours, and no Google certificate addresses them.

The certification is of the management system, so most of an ISO audit is about documented process: a risk assessment, a statement of applicability, management review, and internal audit. The GCP controls are inputs to that, not the subject of it.

Security Command Center's posture service ships an iso_27001 template (§30.10), which is the closest thing to a technical mapping Google supplies.

Pitfall. ISO certification scope is defined by you and stated on the certificate. A scope covering one product line does not cover the estate, and an auditor reading a scope statement that says less than the sales team does is a routine and avoidable embarrassment.

30.3 PCI DSS §

PCI DSS applies to the cardholder data environment, and the single most valuable engineering decision is making that environment small.

The current version is v4.0.1, and it is the only active one. v4.0 was retired at the end of 2024 and v3.2.1 earlier that year. A control mapping written against v3.2.1 is aligned to a retired standard — and, notably, Security Command Center's own PCI posture template is still pci_dss_v_3_2_1, which is exactly the lag §30.9 describes.

Google is a service provider, assessed by a QSA, and its in-scope services are listed in its attestation of compliance. Using a service that is not in scope puts it outside the boundary the assessor accepted.

Scope is the customer's and scope reduction is the whole game. The controls that shrink it are all in this book:

• Network segmentation — VPC Service Controls (Chapter 20) and firewall policies (§5.14) to isolate the cardholder data environment.
• Tokenization or de-identification — Sensitive Data Protection (Chapter 15) so most systems never hold a primary account number.
• A separate project boundary for the environment (§2.21's argument, applied to cardholder data).

There is no PCI regime in Assured Workloads. Its enum is sovereignty- and government-oriented, and expecting a PCI folder type is a common misreading (§30.5).

Pitfall. Every system that can reach the cardholder data environment is in scope, not only those that store card data. A monitoring agent, a jump host, or a CI runner with network access to it drags itself into the assessment — which is why segmentation is a scope decision before it is a security one.

30.4 HIPAA §

HIPAA is the one framework in this chapter with no certification at all. Google states plainly that there is no certification recognized by the US Department of Health and Human Services for HIPAA compliance.

The mechanism is a Business Associate Agreement. Google will execute a BAA, which contractually commits it to the Security Rule obligations of a business associate for a specified list of covered products. Two consequences follow directly:

1. Only products on the covered list may touch protected health information. Using one that is not covered is a contractual breach regardless of how the service is configured.
2. The BAA must be executed before PHI enters the environment, not discovered during an audit.

The Security Rule's safeguards map onto controls this book already owns:

Assured Workloads does have hipaa and hitrust regimes, which enforce personnel and data-location constraints rather than the Security Rule itself.

Pitfall. Data Access audit logs are the HIPAA audit-controls answer and they are disabled by default (§33.11). An organization that enables them during audit preparation has satisfied the control from that day forward and has no record for the period being audited — the same trap as §29.3.

30.5 FedRAMP §

FedRAMP authorizes a cloud service for US federal use, at Low, Moderate, or High impact levels, against a NIST 800-53 baseline.

Google Cloud holds a FedRAMP High P-ATO, and Moderate is a subset of High rather than a separate posture. The customer inherits Google's controls for the infrastructure and implements the rest.

Assured Workloads is not optional here — it is the mechanism that enforces the personnel, location, and support constraints a FedRAMP boundary requires. Its regime values are literal and lowercase-hyphenated in the CLI:

gcloud assured workloads create \
  --organization=123456789012 \
  --location=us-central1 \
  --display-name=fedramp-high-boundary \
  --compliance-regime=fedramp-high \
  --billing-account=billingAccounts/01A2B3-C4D5E6-F7G8H9

The enum is large and government-oriented. Alongside fedramp-high and fedramp-moderate it carries il2, il4, il5, cjis, itar, hipaa, hitrust, irs-publication-1075, and a parallel set of data-boundary-for-* values. There is no PCI, SOC 2, ISO, or CIS regime, which is the clearest statement of what Assured Workloads is for: sovereignty and government control, not commercial frameworks.

--compliance-regime is immutable after creation, so the regime is an architecture decision made before the folder exists.

The customer responsibility matrix is the artifact that matters, and it is obtained under an account relationship rather than published.

Pitfall. Creating an Assured Workloads folder does not make a workload compliant; it constrains what can be created inside it. Everything in Chapter 31 and Chapter 32 still applies, and the folder's constraints are a floor rather than the control set.

30.6 NIST Cybersecurity Framework §

The current version is CSF 2.0, published in February 2024, and its most consequential change is structural.

CSF 2.0 has six Functions, not five. It added GOVERN alongside Identify, Protect, Detect, Respond, and Recover. A mapping that lists five functions is against CSF 1.1 and is out of date.

Govern is the function most cloud programs cannot evidence, because it is about roles, policy, and risk decisions rather than about configuration. The GCP artifacts that speak to it are the organization policy baseline and its exceptions (§29.11) — a documented exception with a named owner is Govern evidence in a way a screenshot is not.

Google's own tooling still references CSF 1.1, so a posture template or report mapped to CSF will not carry the Govern function. Note the gap rather than assuming the tool is current.

CSF is voluntary and outcome-based, which makes it useful as an internal structure and weak as an audit target — it profiles rather than certifies.

Pitfall. CSF's Tiers describe the rigor of your risk management process, not a maturity score to be achieved. Reporting "we are Tier 3" as an accomplishment misreads the framework; the Tiers are a self-assessment of process, and choosing a lower one deliberately is a legitimate answer.

30.7 NIST 800-53 §

NIST SP 800-53 is a control catalog, currently at Revision 5, and it is the substrate under FedRAMP and several other regimes.

Controls are identified by a two-letter family and a number — AC-2, AU-6, SC-7 — and Google's own posture and finding identifiers follow that convention. The families include Access Control (AC), Audit and Accountability (AU), Configuration Management (CM), Contingency Planning (CP), Identification and Authentication (IA), Incident Response (IR), Risk Assessment (RA), System and Communications Protection (SC), and System and Information Integrity (SI), among others.

Rev. 5's structural change was integrating privacy and supply chain into the main catalog rather than treating them separately, which is why Chapter 37's material now appears in a control catalog at all.

Security Command Center ships a nist_800_53 posture template (§30.10), which is the most direct mapping Google provides.

The catalog is not a compliance regime by itself. You do not comply with 800-53; you comply with something that selects a baseline from it. Which baseline — and which overlays — is the scoping decision, and it is made by the regime rather than by you.

Pitfall. 800-53 controls are frequently satisfied partly by Google and partly by you, and the split differs per control. Claiming a control as inherited without the customer responsibility matrix to support it is the most common finding in a FedRAMP assessment, and the matrix is the artifact that settles it.

30.8 CIS Benchmarks §

CIS Benchmarks are prescriptive configuration guides, and they are the only framework in this chapter that ships as something close to a machine-checkable list.

Recommendations are organized into profiles. Level 1 is intended to be broadly applicable with limited functional impact; Level 2 is for environments where security outweighs convenience. There is also a STIG profile, which replaced the former Level 3.

Two CIS benchmarks are directly relevant to a Google Cloud estate: the Google Cloud Platform Foundation Benchmark (§30.9) and the Container-Optimized OS benchmark, which applies to GKE nodes (§9.31).

CIS Hardened Images are available on Google Cloud Marketplace, pre-configured to a benchmark profile. They are a reasonable starting point for §8.33's golden image pipeline and a poor endpoint — the image is hardened at publication, and §28.12's convergence is what keeps it that way.

Prescriptiveness is the benefit and the limit. A CIS recommendation says exactly what to set, which makes it testable; it also encodes a general-purpose judgment that may be wrong for your workload. A documented, justified deviation is a legitimate outcome and belongs in the same evidence store as the compliance itself.

Pitfall. Benchmark compliance measured against a hardened image at build time is not benchmark compliance in production. Configuration drifts, and only a scheduled convergence-and-assert run (§28.21) turns the benchmark into a continuous claim.

30.9 CIS Google Cloud Foundations Benchmark §

This is the most directly usable framework in the chapter and the one where Google's tooling lag is worst. That lag, not the control list, is the section's real content.

The benchmark's current version is v5.0.0. Google's tooling does not track it:

Three different Google products report against three different versions of the same benchmark, none of them current. That is the fact to design around: a "CIS compliant" dashboard in Security Command Center is a statement about v2.0.0, and an assessor working from v5.0.0 will ask about recommendations that dashboard does not know exist.

This chapter therefore prints no control numbers. Numbering has changed across major versions, and a number cited from one version and checked against another is worse than no citation. The benchmark's own document is the authority; buy it, read the version you are assessed against, and map from that.

What is stable is the structure. The benchmark is organized into numbered sections by domain — identity and access management, logging and monitoring, networking, virtual machines, storage, databases, and Kubernetes among them — and every one of those domains is a chapter of this book. The mapping from domain to chapter does not change between versions even though the recommendation numbers do.

Use the posture template as a starting baseline, not as the assessment:

gcloud scc posture-templates list --organization=123456789012
gcloud scc posture-templates describe TEMPLATE --organization=123456789012

Pitfall. Reporting a Security Command Center CIS percentage to an audit committee without naming the benchmark version presents a v2.0.0 result as a current one. State the version alongside every number, or the report is misleading in a way nobody in the room can detect.

30.10 Mapping Controls to GCP Services §

Every framework in this chapter asks similar questions in different vocabulary. This is the mapping, once, from requirement to the section that owns it.

Google's first-party mapping surfaces, and what each is actually good for:

• Security Posture Service — templates including cis_2_0, nist_800_53, iso_27001, and pci_dss_v_3_2_1, deployable as a posture and monitored for drift. The version lags (§30.9).
• Audit Manager — gcloud audit-manager audit-reports generate produces a report against an enrolled scope. It is the closest thing to a first-party evidence generator.
• Compliance Manager — Preview, and must not be a production dependency.
• Security Command Center findings carry compliance metadata, which §30.11 uses.

Pitfall. A control mapping is a living document and is usually written once. The GCP side changes — a service is renamed, a constraint gains a managed equivalent, a product goes Preview to GA — and a mapping that names products rather than section numbers rots faster than one that names capabilities.

30.11 Automating Compliance Evidence §

§29.2 owns producing an artifact. This section owns the other half: connecting an artifact to the clause it satisfies, and keeping that connection current.

The mapping is the thing that is automated, not the collection. Collection is a scheduled export (§29.2). Mapping is a stored relation — control identifier to artifact location to the query that interprets it — and it lives in version control alongside the infrastructure it describes.

Security Command Center findings carry compliance metadata, which makes them the one data source that arrives pre-mapped: a finding records the standard, the version, and the control identifiers it relates to. Exporting findings to BigQuery (§29.10) therefore gives a queryable control-to-finding join without building one.

Posture drift is the continuous form of the assessment. A deployed posture (§30.10) reports when configuration diverges from the template, which converts a periodic audit question into an alert — the same shift §26.22 makes for infrastructure and §28.21 makes for host configuration.

Automate the mapping's own maintenance. Three things break it and all are detectable: a framework version change (§30.9's lag), a renamed GCP product, and a control whose evidence query returns nothing. The third is the useful alarm — an evidence artifact that has stopped being produced looks exactly like a control that is passing.

What cannot be automated is the justification. A deviation from a benchmark, a compensating control, a risk acceptance — these are written by a person and reviewed by a person, and they are usually what the assessor spends the most time on.

Pitfall. An automated compliance dashboard reading green is a statement about the checks that were implemented, not about the framework. The controls nobody automated are silently absent rather than failing, so the dashboard's coverage — which clauses have an automated check at all — is a more important number than its score, and almost nobody publishes it.

Chapter Summary §

• Framework version currency is the failure mode: a mapping built against a retired version is aligned to a document the assessor is not using.
• Google's compliance tooling lags the published standards, sometimes by several major versions, and the gap must be designed around rather than assumed away.
• SOC 2 is an attestation, not a certification; Type II covers a period, which is why evidence must be collected on a schedule.
• Google issues SOC 2 Type II reports quarterly; the SOC 3 report is public and the SOC 1 and 2 reports are not.
• ISO/IEC 27001:2022 certifies a management system, and Google's 27701 certification is as a PII processor — controller obligations remain yours.
• ISO certification scope is defined by you and stated on the certificate; a narrow scope does not cover the estate.
• PCI DSS v4.0.1 is the only active version. Security Command Center's PCI posture template is still pci_dss_v_3_2_1.
• PCI scope includes every system that can reach the cardholder data environment, so segmentation is a scope decision before it is a security one.
• There is no HIPAA certification. The mechanism is a BAA covering a specific product list, executed before PHI enters the environment.
• Data Access audit logs answer HIPAA's audit-controls requirement and are off by default, so they cannot be produced retroactively.
• Google Cloud holds a FedRAMP High P-ATO; Assured Workloads enforces the boundary and --compliance-regime is immutable after creation.
• The Assured Workloads enum is sovereignty- and government-oriented: no PCI, SOC 2, ISO, or CIS regime exists.
• NIST CSF 2.0 has six Functions — it added GOVERN — and a mapping listing five is against CSF 1.1.
• NIST 800-53 is at Revision 5 and is a catalog, not a regime; controls are usually split between Google and you, and the customer responsibility matrix settles the split.
• CIS profiles are Level 1, Level 2, and STIG, which replaced the former Level 3.
• The CIS Google Cloud Foundation Benchmark is at v5.0.0 while Google's three reporting surfaces map to v2.0.0, cis_2_0, and v3.0 respectively. This chapter prints no control numbers, because numbering changes across versions.
• Always state the benchmark version alongside any CIS compliance percentage.
• Security Command Center findings carry compliance metadata, making them the one pre-mapped evidence source.
• A compliance dashboard's coverage — which clauses have an automated check at all — matters more than its score, because unautomated controls are silently absent rather than failing.

Security Checklist §

Sources §

• https://cloud.google.com/security/compliance/compliance-reports-manager — where Google's SOC, ISO, and PCI reports are obtained, and which are public (last validated 2026-09-04)
• https://cloud.google.com/security/compliance/soc-2 — Google's SOC 2 Type II attestation and its cycle (last validated 2026-09-04)
• https://cloud.google.com/security/compliance/iso-27001 — ISO/IEC 27001:2022 and the related 27017, 27018, and 27701 certifications (last validated 2026-09-04)
• https://cloud.google.com/security/compliance/pci-dss — Google's PCI DSS attestation and in-scope services (last validated 2026-09-04)
• https://cloud.google.com/security/compliance/hipaa — the BAA mechanism and the absence of a HIPAA certification (last validated 2026-09-04)
• https://cloud.google.com/security/compliance/fedramp — Google Cloud's FedRAMP authorization (last validated 2026-09-04)
• Cloud SDK 583.0.0, gcloud assured workloads create --help — the --compliance-regime enum, resolved offline 2026-09-04
• https://cloud.google.com/security-command-center/docs/security-posture-overview — posture templates and posture deployment (last validated 2026-09-04)
• https://cloud.google.com/security-command-center/docs/security-posture-cis-20-template — the CIS posture template and the benchmark version it maps to (last validated 2026-09-04)
• https://cloud.google.com/security-command-center/docs/compliance-management — how Security Command Center reports against compliance standards (last validated 2026-09-04)
• https://www.nist.gov/cyberframework — NIST Cybersecurity Framework 2.0 and its six Functions (last validated 2026-09-04)
• https://www.cisecurity.org/benchmark/google_cloud_computing_platform — the CIS Google Cloud Platform Foundation Benchmark and its current version (last validated 2026-09-04)