GCP Landing Zone: Security & Guardrails — Org Policy Constraints, VPC Service Controls, Security Command Center, CMEK & Assured Workloads

Where this fits

Parts 1–3 built the resource hierarchy, the identity plane, and the network of the Google Cloud landing zone. Security & Guardrails is the layer that makes all three enforceable: it turns “we agreed not to do that” into “the platform will not let you do that.” On Google Cloud the guardrail model is preventive first — Organization Policy stops disallowed configurations before they exist, VPC Service Controls draw a data-exfiltration perimeter around your APIs, CMEK puts you in control of the encryption keys under your data, and Assured Workloads pins whole folders to a sovereignty or compliance regime — and detective second, with Security Command Center continuously scoring posture and surfacing threats across the org. This article goes deep on those five sub-components and, critically, on how they compose: an Org Policy that blocks public IPs, a VPC-SC perimeter that blocks the exfiltration path, a CMEK boundary that blocks decryption outside your key ring, an Assured Workloads folder that pins residency, and SCC watching the whole thing — that is defence in depth expressed as landing-zone configuration, not slideware.

Organization Policy constraints — preventive guardrails on the hierarchy

What it is. The Organization Policy Service lets you set constraints on the resource hierarchy (Organization, folder, or project) that restrict what configurations are even allowed, regardless of a principal’s IAM permissions. This is the key distinction from IAM: IAM governs who can act; Org Policy governs what may exist. A user with roles/owner on a project still cannot create a VM with an external IP if an Org Policy forbids it. Constraints come in two flavours: list constraints (allow/deny specific values, e.g. which regions, which external IPs, which sharing domains) and boolean constraints (on/off, e.g. disable SA key creation, require OS Login). A constraint set on a node becomes the effective policy for everything beneath it, with child nodes able to inherit, merge, or override depending on how the policy is written.

Why it matters. Org Policy is the preventive backbone of the entire guardrail strategy. Detective controls tell you the barn door is open; preventive controls nail it shut. Because constraints are evaluated at resource-creation and modification time by the API itself, a misconfiguration is rejected, not merely flagged hours later by a scanner. That is the difference between “we found a public bucket in last night’s scan” and “the public bucket could never be created.” For regulated landing zones this is non-negotiable — auditors want to see that residency and exposure controls are enforced, not aspirational.

How to do it well.

• Set baseline constraints at the Organization node so every folder and project inherits them, then relax narrowly per folder where genuinely needed (e.g. a sandbox folder that permits external IPs). Inheritance means you write the strict policy once.
• Anchor on the curated guardrail baselines. The Secure Foundations Blueprint and the Assured Workloads / org-policy bundles ship a vetted starting set. Don’t invent your list from scratch — start from the blueprint and tighten.
• Use the high-value constraints deliberately. A landing-zone baseline almost always includes the constraints in the table below.
• Prefer dry_run_spec (the “dry-run / audit” mode) when introducing a new constraint to an existing estate. Org Policy supports a dry-run policy that logs what would be violated without blocking, so you can find and remediate non-compliant resources before flipping to enforcement.
• Author the new-style constraints with conditions and tags where supported, and reach for Custom Organization Policies (backed by Common Expression Language, CEL) when no built-in constraint fits — e.g. “GKE clusters must have Shielded Nodes” or “Cloud SQL must not have a public IP.” Custom constraints let you write resource.<field> == <value> rules against supported services.
• Manage every policy as code in Terraform (google_org_policy_policy, google_org_policy_custom_constraint) and review via pull request — Org Policy drift is a real incident vector.

Key artifacts: an Org Policy baseline document mapping each constraint to a control objective; the Terraform module that applies it at Org/folder scope; a dry-run rollout plan for any constraint added to a live estate; and a register of approved exceptions (which folder, which constraint, why, expiry).

VPC Service Controls — a data-exfiltration perimeter around your APIs

What it is. VPC Service Controls (VPC-SC) create a service perimeter — a virtual boundary around a set of projects within which Google-managed APIs (Cloud Storage, BigQuery, Cloud KMS, Pub/Sub, and dozens more) can be called, and across which data cannot move unless an explicit rule allows it. The crucial insight is that VPC-SC does not control identity (that’s IAM) — it controls context and data movement. Even a principal holding valid, correct IAM permissions on a BigQuery dataset is blocked from reading it if the request originates outside the perimeter, or from copying it to a project outside the perimeter. VPC-SC closes the gap that IAM alone cannot: a leaked credential or a malicious insider with legitimate access still cannot exfiltrate data out of the boundary.

Why it matters. This is GCP’s principal defence against data exfiltration via the API surface. The classic attack — stolen service-account credential, then gsutil cp the data to an attacker-controlled bucket in their own project — is exactly what a perimeter stops, because the destination project is outside the perimeter and the egress rule denies it. VPC-SC is also how you ensure that data which must stay inside the company cannot be reached from the public internet even with valid keys, and how you stop the subtler “service-to-service” exfiltration where data hops between Google services. For any landing zone handling regulated or high-value data, VPC-SC is the control that makes “valid credentials are not enough” literally true.

How to do it well.

• Start in dry-run (audit) mode. A perimeter can run in dry-run so violations are logged to Cloud Audit Logs but not blocked. This is mandatory before enforcement on a live estate — VPC-SC famously breaks things you didn’t know depended on cross-project API calls (CI pipelines, data exports, third-party SaaS pulls). Run dry-run for weeks, mine the vpcServiceControlsUniqueId violation logs, then enforce.
• Design the perimeter topology deliberately. Options: one large perimeter around all production data projects (simplest, strongest), multiple perimeters per data domain, or a Perimeter Bridge that lets two perimeters share specific projects. Most landing zones begin with a single production perimeter and add bridges only when a genuine cross-domain need appears.
• Define Access Levels (via Access Context Manager) that describe trusted context — corporate IP CIDRs, specific regions, required device-trust posture, or specific identities — and attach them as ingress rules so that, e.g., admins on the corporate network can reach perimeter data while the same call from a coffee-shop IP is denied.
• Write precise ingress/egress rules. The modern policy model uses ingress policies (who/what may enter) and egress policies (what may leave, e.g. to a specific partner project) keyed on identity, project, and service. Keep them minimal — every rule is a hole in the wall.
• Plan for private connectivity. Route Google API calls through Private Google Access / Private Service Connect endpoints (e.g. restricted.googleapis.com, which resolves only to VPC-SC-protected APIs) so on-prem and VPC traffic reaches APIs inside the perimeter without traversing the public internet. Pair with DNS for *.googleapis.com pointing at the restricted VIP.
• Account for the break-glass path. Enforcement can lock out legitimate emergency work; pre-define an ingress rule or an Access Level for the break-glass group, and document it.

Key artifacts: a perimeter topology diagram; the Access Context Manager access-level definitions; the ingress/egress rule catalogue with justification per rule; the dry-run violation report and remediation log; and the DNS/PGA configuration that routes APIs to the restricted VIP.

Security Command Center — the detective and posture plane

What it is. Security Command Center (SCC) is Google Cloud’s centralized security and risk-management platform — the single pane that aggregates misconfiguration findings, vulnerabilities, and threats across the whole organization. It runs three broad classes of capability: posture/CSPM (built-in detectors like Security Health Analytics flag misconfigurations such as public buckets, open firewall rules, disabled audit logs, or non-CMEK resources against benchmarks like CIS GCP); threat detection (Event Threat Detection mines Cloud Audit and other logs for IOC patterns and anomalous IAM grants; Container Threat Detection and VM Threat Detection watch runtime behaviour); and attack-path and exposure analysis (the Attack Path Simulation and Toxic Combination features in the premium/Enterprise tiers show how an internet-exposed resource could chain to a high-value asset). Everything lands as a normalized Finding in the SCC inventory, scored by severity.

Why it matters. Org Policy and VPC-SC are preventive, but no preventive control is complete — new services ship, exceptions get granted, drift happens. SCC is the detective net that catches what slips through, plus the inventory (Cloud Asset Inventory under the hood) that answers “what do we even have and how exposed is it?” Critically, SCC is org-scoped: it sees every project, so it is the right place to measure whether the landing-zone guardrails are actually holding. It is also the integration point that pushes findings to your SIEM/SOAR so security operations runs from one normalized feed rather than per-product consoles.

How to do it well.

• Choose the tier deliberately. SCC sells as Standard (free; basic Security Health Analytics and some Web Security Scanner), Premium, and Enterprise (adds Event/Container/VM Threat Detection, Attack Path Simulation, broader compliance reporting, and — in Enterprise — multi-cloud coverage and Mandiant-powered capabilities via the Google SecOps integration). Regulated landing zones almost always need Premium or Enterprise for threat detection and attack-path analysis. Activate at the Organization level so coverage is complete; project-level activation leaves blind spots.
• Wire up notifications and export. Configure Finding Notifications to Pub/Sub and stream to your SIEM (Chronicle/Google SecOps, Splunk) and to ticketing. Use the Continuous Exports to BigQuery for long-term analytics and audit evidence.
• Operationalize muting and remediation. Use mute rules to suppress accepted-risk findings (with documented justification) so the queue reflects actionable items; track mean time to remediate (MTTR) per severity. Many findings have Security Health Analytics remediation guidance and can be auto-remediated with Cloud Functions/Workflows triggered off the Pub/Sub feed.
• Use the compliance dashboards (CIS GCP, PCI-DSS, NIST, ISO mappings in Premium/Enterprise) as standing evidence rather than building your own spreadsheets.
• Lean on Attack Path Simulation to prioritize: a medium-severity misconfig on an asset that sits on a path to a crown-jewel database outranks a high-severity finding on an isolated sandbox.

Key artifacts: the SCC tier decision and org-level activation; the Pub/Sub→SIEM export configuration; the mute-rule catalogue with justifications; a finding-triage runbook with severity-based SLAs; and the compliance-dashboard mapping used as audit evidence.

Customer-managed encryption keys (CMEK) — owning the keys under your data

What it is. Every byte at rest in Google Cloud is encrypted by default with Google-managed keys — that is automatic and free. CMEK changes who controls the key-encryption key: instead of Google managing it opaquely, you create and own a CryptoKey in Cloud KMS (or Cloud HSM, or Cloud External Key Manager / EKM) and point your services — Cloud Storage, BigQuery, Persistent Disk, Cloud SQL, Pub/Sub, Spanner, and many more — at that key via a CMEK setting. The service then calls KMS to wrap/unwrap data-encryption keys using your key. Because you govern the key’s IAM, rotation, and lifecycle, you gain a powerful lever: disabling or destroying the key cryptographically renders the data inaccessible — a hard, provable control that Google-managed keys cannot give you.

Why it matters. CMEK matters for three concrete reasons. First, separation of duties / cryptographic shredding: the ability to revoke access to data by disabling a key — independent of the data service’s own IAM — is exactly what many regulators and risk teams require. Second, key residency and HSM/external control: Cloud HSM keeps keys in FIPS 140-2 Level 3 hardware in a chosen region; Cloud EKM keeps the key material outside Google entirely, in a partner key manager (Thales, Fortanix, etc.) or your own, so Google never holds the key — the basis for “hold your own key” sovereignty stories. Third, auditability: every key use is logged, so you can prove what decrypted what, when. The landing-zone decision is which data classes get CMEK, in which protection level, in which region — and how you stop resources being created without CMEK.

How to do it well.

• Stand up a dedicated KMS topology. Create key rings per region per environment (KMS keys are regional and a key ring’s location is fixed at creation) in a tightly-controlled key-management project, separate from the workload projects that use the keys. This separates the duty of managing keys from using data.
• Pick the protection level per data class: SOFTWARE (KMS) for general workloads, HSM (Cloud HSM) for regulated/high-value data, EXTERNAL/EKM when key material must live outside Google. Document the mapping from data classification to protection level.
• Grant each service its CMEK permission precisely. Every CMEK-using service runs as a per-service agent (e.g. the Cloud Storage service agent) that needs roles/cloudkms.cryptoKeyEncrypterDecrypter on the specific key — grant that and nothing broader, and never grant humans encrypt/decrypt on production keys.
• Automate rotation (set a rotation_period on the CryptoKey so KMS generates new key versions on schedule) and define a key-destruction / disable runbook for the cryptographic-shredding scenario, including the 24-hour-plus scheduled-destruction safety window KMS enforces.
• Enforce CMEK at the guardrail layer. Use the Org Policy constraints gcp.restrictNonCmekServices (deny resource creation in named services unless CMEK is set) and gcp.restrictCmekCryptoKeyProjects (restrict which KMS projects may supply CMEK keys) so a developer cannot quietly create a non-CMEK BigQuery dataset. This is where CMEK and Org Policy compose.
• Mind the operational gotchas: a destroyed/disabled key takes the data offline; key region must match (or be compatible with) the resource region; CMEK adds KMS API calls and a small cost/latency — all worth designing for, not discovering in production.

Key artifacts: a data-classification-to-protection-level matrix; the KMS key-ring / key-management-project Terraform; the per-service-agent IAM bindings; the rotation and destruction runbooks; and the CMEK-enforcement Org Policies.

Assured Workloads — pinning a folder to a compliance and sovereignty regime

What it is. Assured Workloads lets you create a folder (the Assured Workloads workload) that is bound to a specific compliance or sovereignty regime — for example FedRAMP Moderate/High, IL4/IL5, CJIS, HIPAA, ITAR, EU Regions & Support / EU Sovereign Controls, Canada Regions & Support, and others. Once a workload is created under a regime, Google automatically applies and continuously enforces the controls that regime requires: data residency (resources can only be created in approved regions), personnel access controls (support and operations restricted to vetted personnel in approved geographies — the sovereign / support-access dimension), encryption requirements (often CMEK mandatory, sometimes EKM), and product restrictions (only services that meet the regime are permitted in the folder). It is, in effect, a pre-packaged, Google-enforced bundle of Org Policies, residency rules, personnel controls, and key requirements wrapped around a folder — plus continuous monitoring that flags drift from the regime.

Why it matters. Assembling FedRAMP-High or EU-sovereignty controls by hand — every region constraint, every CMEK rule, every support-access restriction, every product allow-list — is enormous, error-prone, and hard to prove. Assured Workloads collapses that to a regime selection and delivers continuous, auditable enforcement plus the personnel/operational controls (data residency and who-can-touch-the-data) that you fundamentally cannot build yourself with Org Policy alone, because they govern Google’s own support staff. For organizations under government, defence, healthcare, or data-sovereignty mandates, this is the difference between a multi-quarter compliance project and a configured folder. It is the landing zone’s answer to “this entire workload domain must provably stay within these legal and operational boundaries.”

How to do it well.

• Place regulated workloads in their own folder hierarchy and create an Assured Workloads workload for the right regime, rather than retrofitting controls onto a general-purpose folder. The regime is chosen at creation and shapes everything beneath.
• Understand what the regime enforces so teams don’t fight it: which regions are allowed, which products are excluded (some services aren’t authorized for some regimes — design around the allow-list), whether CMEK or EKM is mandatory, and what the personnel access / support-access posture is.
• Combine with CMEK and your own Org Policies. Assured Workloads sets a baseline; layer additional org constraints and your CMEK keys (often EKM for the strongest sovereignty) on top. The two are designed to compose.
• Use the continuous-monitoring / violations view to catch and remediate any drift from the regime, and feed those signals alongside SCC.
• Plan the operating model: restricted personnel access affects how your engineers and Google support troubleshoot; brief teams that some convenience features are intentionally unavailable inside the boundary, and define the support pathway in advance.

Key artifacts: the regulated-folder design and the Assured Workloads workload definition (regime + region); the documented region/product allow-list for that regime; the CMEK/EKM keys mandated by the regime; and the continuous-monitoring view wired into the security operating model.

Real-world enterprise scenario

Helvetia HealthGrid (fictional) is a Swiss-headquartered digital-health platform, 2,400 employees, processing patient data across the EU and a growing US federal-research line of business. It is subject to GDPR, Swiss data-protection law, HIPAA for the US research data, and a contractual EU data-sovereignty requirement from several hospital customers. Its landing zone, built in Parts 1–3, has a folder hierarchy with a Platform folder, an EU clinical domain (dev/staging/prod), and a new US federal-research domain.

Organization Policy. The Platform team applies a baseline at the Org node: gcp.resourceLocations restricted to europe-* for the clinical domain (overridden to us-* only in the federal folder), compute.vmExternalIpAccess default-deny, storage.publicAccessPrevention and uniformBucketLevelAccess enforced, iam.disableServiceAccountKeyCreation on, iam.automaticIamGrantsForDefaultServiceAccounts disabled, and sql.restrictPublicIp enforced. Two Custom Org Policies (CEL) require Shielded GKE nodes and forbid Cloud SQL public IP estate-wide. Every constraint was rolled out via dry_run_spec for three weeks first; the dry-run logs surfaced 11 legacy public-IP VMs and 4 non-uniform buckets, all remediated before enforcement. All policy is Terraform (google_org_policy_policy, google_org_policy_custom_constraint).

VPC Service Controls. A single production service perimeter wraps the EU clinical prod projects plus the KMS key-management project. Access Context Manager access levels permit the corporate CIDRs and the SecOps device-trust posture; ingress rules admit the named GitHub Actions deployer principals and on-call admins; egress rules allow exactly one approved analytics-export project. API traffic is forced through restricted.googleapis.com via Private Google Access and a DNS override. The perimeter ran in dry-run for six weeks — the violation logs caught a nightly BigQuery export to an out-of-perimeter project, which was rebuilt as an egress rule before enforcement.

Security Command Center. SCC is activated at the Organization level at the Enterprise tier for Event Threat Detection, Container Threat Detection, and Attack Path Simulation. Findings stream via Pub/Sub into Google SecOps (Chronicle) and to Jira; Continuous Exports land in BigQuery for audit evidence. Mute rules suppress accepted sandbox findings. The team prioritizes off Attack Path Simulation, which flagged a medium-severity over-permissive firewall on a path to the clinical database as the top item that quarter.

CMEK. Data classified restricted (patient records) uses Cloud HSM keys; the EU-sovereignty hospital contracts mandate Cloud EKM with a Swiss-hosted Fortanix key manager so key material never resides in Google. Key rings live per region per env in a dedicated hhg-keymgmt project; per-service agents hold cryptoKeyEncrypterDecrypter on the specific keys; rotation is set to 90 days. gcp.restrictNonCmekServices mandates CMEK for Storage, BigQuery, and Cloud SQL, and gcp.restrictCmekCryptoKeyProjects locks CMEK keys to hhg-keymgmt. A documented key-disable runbook provides cryptographic shredding for offboarding a hospital tenant.

Assured Workloads. The US federal-research domain is created as an Assured Workloads workload under FedRAMP Moderate (with a path to HIPAA controls for the PHI subset). This auto-enforces US-region residency, US-personnel support access, and mandatory CMEK, and continuously monitors for drift. The EU clinical prod folder is additionally pinned with EU Regions & Support / EU Sovereign Controls so EU residency and EU-personnel access are Google-enforced, satisfying the hospital sovereignty clauses without the Platform team hand-building those personnel controls.

Measurable outcome (first two quarters). Preventive guardrails meant zero public buckets and zero public-IP Cloud SQL instances could be created (down from 9 such resources in the legacy estate). The VPC-SC perimeter blocked 3 real exfiltration attempts in dry-run analysis (misrouted exports + one stolen-credential test by the red team) before enforcement. SCC MTTR for high-severity findings fell to under 24 hours, and the CIS GCP compliance score rose from 71% to 96%. CMEK with EKM let them sign the two largest hospital sovereignty contracts, and the Assured Workloads FedRAMP folder turned an estimated two-quarter compliance build into a configured folder, passing the customer’s federal audit on first submission.

Deliverables & checklist

• Org Policy baseline applied at the Org node (locations, external-IP deny, public-access prevention, uniform bucket access, SA-key disable, default-SA-grant disable, restrict-public-IP), with per-folder overrides documented.
• Custom Org Policies (CEL) authored for gaps the built-ins don’t cover; everything in Terraform and PR-reviewed.
• Dry-run rollout completed for any constraint added to a live estate, with a remediation log and an approved-exceptions register.
• VPC-SC perimeter designed (topology, bridges), with Access Levels, ingress/egress rules, restricted.googleapis.com + PGA/PSC + DNS, and a break-glass path.
• VPC-SC dry-run run for weeks, violation logs triaged, then enforced.
• Security Command Center activated at Org level at the right tier; Pub/Sub→SIEM export and BigQuery continuous export wired; mute-rule catalogue and severity-based triage SLAs defined.
• CMEK topology: key-management project, per-region/env key rings, protection levels mapped to data classes, per-service-agent IAM, scheduled rotation, and disable/destroy runbook.
• CMEK enforcement via gcp.restrictNonCmekServices and gcp.restrictCmekCryptoKeyProjects.
• Assured Workloads workloads created for regulated/sovereign domains under the correct regime, with region/product allow-lists, mandated CMEK/EKM, and continuous-monitoring wired to the security ops model.
• A defence-in-depth map showing how Org Policy, VPC-SC, CMEK, Assured Workloads, and SCC compose per data domain.

Common pitfalls

• Enforcing VPC-SC (or a new Org Policy) without a dry-run. Flipping straight to enforce breaks CI, exports, and SaaS integrations you didn’t know existed, and triggers an emergency rollback. Fix: always run dry-run / dry_run_spec mode for weeks, mine the violation logs, remediate, then enforce.
• Treating SCC findings as the whole strategy. Detection without prevention means you are forever cleaning up misconfigurations after the fact. Fix: make Org Policy and VPC-SC the preventive first line, and use SCC to catch the residue and measure that the guardrails hold.
• Granting humans encrypt/decrypt on production CMEK keys, or co-locating keys with data. This defeats separation of duties and the cryptographic-shredding control. Fix: keys live in a dedicated key-management project, only per-service agents get cryptoKeyEncrypterDecrypter, and CMEK is enforced with restrictNonCmekServices.
• Forgetting that destroying or disabling a key takes the data offline. Teams disable a key for “cleanup” and take production down, or destroy a key still in use. Fix: a documented key lifecycle/shredding runbook, the KMS scheduled-destruction safety window, and rotation rather than ad-hoc deletion.
• Activating Security Command Center (or Assured Workloads regimes) at project scope or after the fact. Project-scoped SCC leaves blind spots; retrofitting a regime onto a populated general-purpose folder is painful. Fix: activate SCC at the Organization level, and create Assured Workloads workloads up front as the home for regulated domains.
• Building sovereignty/personnel controls by hand instead of using Assured Workloads. Org Policy can pin regions but cannot restrict Google’s own support personnel by geography or vetting. Fix: use Assured Workloads for residency and personnel/support-access controls, and layer your CMEK/EKM and custom Org Policies on top.

What’s next

With preventive guardrails, the data-exfiltration perimeter, posture detection, customer-controlled keys, and sovereignty regimes in place, Part 5 — Logging, Monitoring & Operations designs the org-wide log sinks, the security/audit log architecture, monitoring, and the operational runbooks that keep the landing zone observable and accountable.