GCP Cloud Adoption Framework: Secure Theme — Advanced Security Posture, Identity/Network/Data Security, Compliance & Proactive Defense-in-Depth

In a nutshell

The Secure theme of Google’s Cloud Adoption Framework asks one deceptively simple question: as your organization moves onto Google Cloud, how systematically — and how early — is security built into the way you work? It is not a product you buy or a box you tick. It is a measure of maturity: whether protecting your data is a reactive scramble bolted on after each incident, or a designed-in property of your platform that every new project inherits automatically.

Think of it like the safety of a modern apartment building versus a single locked front door. A beginner’s instinct is “put a strong lock on the door” — that is one control, at one layer. A mature building has a lock and a fire-alarm and CCTV and a concierge who checks IDs and sprinklers and compartment walls that stop a fire spreading floor to floor. If any one control fails, the next still protects you. That layering is defense-in-depth, and pairing it with the rule “trust nobody by default; verify every request no matter where it comes from” is zero-trust. The Secure theme is the discipline of building that layered, trust-nothing model into your cloud from day one — and then proving it works.

Two mental shifts make everything else click. First, identity is the new perimeter: in the cloud there is no castle wall, so who is asking (a verified user or workload) matters more than where they are asking from. Second, the shared-responsibility model: Google secures the platform underneath your workloads (the hardware, the hypervisor, the physical datacenter); you are responsible for how you configure what you build on top (your IAM, your firewall rules, your buckets). Most cloud breaches are not Google failing its half — they are a customer misconfiguring theirs. The Secure theme is the programme that stops that.

Google scores your Secure maturity on the same three-rung ladder as every other theme — Tactical → Strategic → Transformational — across four levers: your security posture (how exposed you are, and the guardrails holding that in place), your identity/network/data controls, your compliance evidence, and your proactive threat management. This lesson walks all four, shows what each looks like at each rung, and ends with a real bank’s ten-month journey from Tactical to Strategic.

Level: Advanced — with a beginner on-ramp · Time: ~45 min

Read left to right: the Secure theme layers guardrails and posture, an identity perimeter, network-and-data containment, continuous compliance, and proactive detect-and-respond — each layer catching what the one before it missed — and the whole programme matures Tactical → Strategic → Transformational.

Before you start, it helps to know: the GCP resource hierarchy (Organization → Folders → Projects) and how policy inherits down it, the basics of IAM (members, roles, bindings), and what a VPC is. If any of those are fuzzy, skim GCP Resource Hierarchy & Org-Policy Guardrails and IAM Fundamentals first. This is part 5 of the Cloud Adoption Framework series; the CAF Overview sets up the maturity model this lesson uses.

After this lesson you will be able to:

• Explain the Secure theme, the shared-responsibility model, zero-trust and defense-in-depth in plain language, and place any control on the Tactical → Strategic → Transformational ladder.
• Describe the four levers of Secure — posture, identity/network/data, compliance, threat management — and name the primary GCP service behind each.
• Design a prevent → detect → score posture programme using Organization Policy guardrails and Security Command Center.
• Explain why VPC Service Controls, CMEK, DLP and domain-restricted sharing together defeat a stolen-but-valid credential — the essence of defense-in-depth.
• Recognise the most common Secure anti-patterns (exportable SA keys, detection without prevention, compliance-as-a-scramble) and the mature pattern that replaces each.

Where this fits

Google’s Cloud Adoption Framework (Google’s CAF) measures organizational cloud readiness across four themes — Learn, Lead, Scale, and Secure — and rates each across the Tactical → Strategic → Transformational phase ladder. Secure is the theme that measures the maturity of your capability to protect your services from unauthorized and inappropriate access with a multi-layered, identity-centric, defense-in-depth approach that deepens as the rest of your cloud estate matures; its natural owner is the CISO. This article is part 5 of the series — the last of the four themes — and goes deep on the four levers that move Secure from “products bolted on after an incident” to “security designed into the operating model”: advanced security posture, identity, network and data security, compliance, and proactive threat management and defense-in-depth. The framing that matters throughout: in Google’s model, Tactical security is reactive and per-project, Strategic security is standardized and centrally governed, and Transformational security is automated, continuously assessed, and shifted left into the platform itself — security as code that ships with every landing-zone change rather than a gate that work queues behind.

The security mental model — zero-trust, defense-in-depth, and shared responsibility

Before the four sub-components, internalise the three ideas that the entire Secure theme rests on. Everything after this section is an application of one of these three.

Zero-trust: identity is the new perimeter

The old security model was a perimeter: a hard network wall (the corporate firewall/VPN) with a soft, trusting interior — get inside, and you were assumed friendly. In the cloud that model collapses, because there is no single wall: your resources are reachable over the internet by definition, your workforce is remote, and your workloads talk to managed APIs. Zero-trust replaces “trust the network location” with “never trust, always verify” — every request is authenticated and authorized on its own merits (verified identity + device posture + context like location and time), regardless of where it originates. That is why Google’s CAF treats Secure as identity-first: when there is no wall, who is asking becomes the perimeter. Practically, zero-trust on GCP means federated identity with phishing-resistant MFA, least-privilege IAM, context-aware access, and putting Identity-Aware Proxy / BeyondCorp in front of apps so you can retire the VPN entirely.

Defense-in-depth: assume every single control will fail

Defense-in-depth is the architectural principle that no single control should be load-bearing on its own. You layer independent controls so that defeating one still runs the attacker into the next — and you assume breach, designing as if the outer layers have already failed. Here is the same attack meeting six layers:

1. An attacker phishes an analyst’s password. Layer 1 (identity): phishing-resistant FIDO2/Titan MFA means the password alone is useless. Suppose they steal a live session token anyway.
2. That session has BigQuery read on a PII dataset; they try to copy it to their own project. Layer 2 (network): VPC Service Controls denies the egress — the data cannot leave the perimeter to an unauthorized project.
3. They try to share the dataset out to an external Gmail account. Layer 3 (identity/data): iam.allowedPolicyMemberDomains rejects any principal outside your domain.
4. They query and attempt a bulk export. Layer 4 (data): Sensitive Data Protection (DLP) flags the bulk-PII read and BigQuery column-level security masks the PAN and Aadhaar columns.
5. Even a raw table copy is CMEK-encrypted; without Cloud KMS access the bytes are meaningless, and you can revoke the key.
6. The anomalous access pattern already tripped Event Threat Detection, and a SecOps SOAR playbook auto-revokes the session and disables the key — in seconds. Layer 6 (detect + respond).

Defeating one control simply runs the attacker into the next. That is why the Secure theme insists on all of identity, network and data — not identity alone.

Shared responsibility: know exactly which half is yours

Google secures the platform; you secure what you build on it. The dividing line slides with how managed the service is — the more managed (Compute Engine → GKE → Cloud Run → BigQuery), the more of the stack Google operates and the less you configure — but IAM and your data are always yours.

The single most important consequence: the overwhelming majority of cloud breaches are customer-side misconfigurations, not platform failures. A public bucket, an open firewall, a leaked service-account key, an over-broad grant — every one of these lives on your side of the line. The Secure theme is, at heart, the discipline of getting your half right systematically.

The maturity ladder, applied to Secure

Keep this ladder in your head for the rest of the lesson: every control below is really an answer to “what moves this capability one rung to the right?”

Sub-component 1: Advanced security posture

What it is. Your security posture is the aggregate, measurable state of how exposed your Google Cloud estate is right now — the sum of your misconfigurations, your vulnerabilities, your over-broad grants, your toxic combinations, and your drift from a known-good baseline — together with the organization-wide guardrails that hold that state in place. An advanced posture is one that is (a) centrally visible across the whole resource hierarchy rather than per-project, (b) expressed as policy-as-code so the secure configuration is the default and deviations are prevented or flagged automatically, and © continuously scored so you can prove the posture is improving over time, not just asserted to be “fine.” Posture is the theme’s centre of gravity: identity, network, data, compliance, and threat management are all just facets of posture, and Security Command Center is the lens through which Google’s CAF expects you to see all of them.

Why it matters. The dominant way enterprises get breached in cloud is not a zero-day — it is a misconfiguration: a bucket made public, a firewall rule opened to 0.0.0.0/0, a service-account key leaked into a repo, a default network left in place, an over-privileged role binding nobody remembers granting. These are posture failures, and they are invisible until something points a continuous evaluator at the estate. A Tactical organization discovers them during a pen-test or, worse, in an incident; a Strategic organization sees them on a dashboard the day they appear; a Transformational organization prevents most of them from ever being created because the guardrail rejects the change. Posture is also the thing auditors and boards actually ask about — “show me your security score and its trend” is a posture question, and you cannot answer it without a posture management capability.

How to do it well. Build posture from three reinforcing layers — prevent, detect, score — and wire all three to the resource hierarchy so they apply by inheritance, not per-project effort.

• Prevent with policy-as-code (the guardrails). The Organization Policy Service is the foundational preventive control: org-level constraints that are inherited down the Organization → Folders → Projects hierarchy. Enforce the high-value baseline early — iam.disableServiceAccountKeyCreation, compute.requireOsLogin, compute.vmExternalIpAccess (deny by default), storage.publicAccessPrevention, sql.restrictPublicIp, gcp.resourceLocations (residency), iam.allowedPolicyMemberDomains (domain-restricted sharing, your single strongest defence against external data exfiltration via IAM), and custom org-policy constraints for anything Google does not ship a managed constraint for. Pair these with Security Command Center’s posture management (security posture definitions and Posture as a service) so a named, versioned posture can be deployed to a folder and its drift continuously detected.
• Detect with continuous evaluation. Security Command Center (SCC) is GCP’s native CSPM/CNAPP and the single most important service in the entire Secure theme. Its Security Health Analytics detector library continuously flags misconfigurations (public buckets, open firewalls, disabled logging, weak SSL policy) against benchmarks (CIS GCP, PCI-DSS, NIST 800-53, ISO 27001) mapped to findings. Web Security Scanner finds app-layer vulns (XSS, outdated libraries) in your App Engine, Compute Engine and GKE web apps. The Attack Path Simulation and Toxic Combination features (SCC Enterprise) are the genuinely advanced part — they correlate a public-facing VM + an over-privileged service account + an open firewall into a single ranked attack path to a high-value resource, so you fix the chain, not 200 unranked findings.
• Score and trend. Use the SCC Security Posture score / attack exposure score as the executive metric. Export findings to BigQuery and build a Looker dashboard of posture-score-over-time, mean-time-to-remediate (MTTR) per finding class, and the count of high/critical open findings by folder. A score that is trending up and to the right is the artifact the board wants; a one-time snapshot is not.

SCC tiers — choose deliberately.

Posture KPIs.

Artifacts & decisions: the Organization Policy baseline (as Terraform), the deployed SCC security posture definitions per folder, the SCC tier decision (Standard/Premium/Enterprise) and its budget justification, a findings-to-BigQuery export + Looker posture dashboard, and a remediation runbook mapping each finding class to an owner and an SLA.

Sub-component 2: Identity, network and data security

This is the technical heart of defense-in-depth — the three planes you protect. Google’s CAF treats Secure as identity-centric first, then network, then data; that ordering is deliberate, because in a zero-trust cloud, identity is the new perimeter.

Identity security

What it is. Everything that controls who (human or machine) can do what to which resource: authentication, authorization, the privilege model, and the lifecycle of credentials. On GCP this means Cloud Identity / Google Workspace as the identity source (ideally federated from your existing IdP via SAML/OIDC), Cloud IAM for authorization, groups as the unit of grant, and a disciplined approach to service accounts for workload identity.

Why it matters. Compromised or over-privileged identity is the highest-leverage attack vector in cloud — one leaked service-account key or one Owner grant on the org node can be game-over. The CAF rewards moving from individual, long-lived, over-broad grants toward group-based, least-privilege, short-lived, federated identity.

How to do it well.

• Federate, don’t fork. Use Cloud Identity federated from your enterprise IdP (Entra ID, Okta, Ping) so joiners/movers/leavers are governed by one HR-driven lifecycle. Enforce 2-Step Verification, preferably phishing-resistant Titan / FIDO2 security keys, and context-aware access.
• Grant to groups, at the right node, with least privilege. Never bind roles to individual users; bind Google Groups to roles at the folder that matches the blast radius. Prefer predefined roles over Owner/Editor, and build custom roles for the long tail. Use IAM Conditions (time-bound, resource-tagged) and Privileged Access Manager (PAM) for just-in-time elevation so standing privilege approaches zero.
• Eliminate service-account keys. Disable key creation org-wide (iam.disableServiceAccountKeyCreation) and replace keys with Workload Identity Federation (for external/CI workloads, e.g. GitHub Actions, AWS, on-prem) and Workload Identity (for GKE), so workloads authenticate with short-lived tokens and no exportable secret exists.
• Right-size continuously. Use the IAM Recommender (Active Assist) to strip unused permissions, and Policy Analyzer / Policy Troubleshooter to answer “who can access this?” and “why can this principal do that?”
• Reach for zero-trust app access. BeyondCorp Enterprise / Identity-Aware Proxy (IAP) put identity-and-context in front of apps and VMs so you can retire the VPN and stop trusting the network location at all.

Network security

What it is. The controls that constrain reachability and traffic — segmentation, perimeters, ingress/egress filtering, DDoS and WAF protection, and private connectivity — so that even an authenticated principal cannot reach what it should not.

Why it matters. Network controls are the layer that contains an identity compromise and prevents data exfiltration. The single most distinctive GCP network-security control — VPC Service Controls — exists specifically to stop a credential-theft attack from turning into a data breach.

How to do it well.

• Architect with Shared VPC + hub-and-spoke so networking is centrally governed by the platform team, not improvised per project. Disable the default network and default-allow rules via Org Policy.
• Build a service perimeter with VPC Service Controls (VPC-SC). This is the control that earns the Secure theme its keep: it draws an identity-and-resource perimeter around your sensitive managed services (BigQuery, Cloud Storage, etc.) so that even valid credentials cannot read or copy data out of the perimeter to an unauthorized project or the public internet. Pair with Private Google Access and Private Service Connect so traffic to Google APIs never traverses the public internet.
• Filter and segment. Use hierarchical firewall policies (inherited from folders), firewall policy rules and network tags / service accounts for micro-segmentation, and Cloud NGFW (Cloud Firewall Plus) for L7 inspection, IDS/IPS and TLS interception where required.
• Protect the edge. Front internet-facing apps with Cloud Armor (managed WAF + OWASP rules + Adaptive Protection ML-based L7 DDoS defence) behind the global Cloud Load Balancer, with Google Cloud Armor managed rules and rate-limiting.

Data security

What it is. Protecting the data itself — at rest, in transit, and increasingly in use — through encryption, key management, classification, de-identification, and exfiltration prevention.

Why it matters. Data is what you are ultimately protecting; everything else is a means. Regulated data (PII, PHI, PCI) carries legal obligations around encryption, key control, residency and de-identification that the CAF’s compliance lens depends on.

How to do it well.

• Own your keys deliberately. Data is encrypted at rest by default with Google-managed keys; move to Customer-Managed Encryption Keys (CMEK) in Cloud KMS for sensitive workloads, Cloud HSM (FIPS 140-2 Level 3) for high-assurance, and Cloud External Key Manager (EKM) when policy demands keys live outside Google. Consider Key Access Justifications (KAJ) so you can deny Google operational access to your keys.
• Classify and de-identify. Use Sensitive Data Protection (Cloud DLP) to discover and classify PII/PHI across BigQuery, Cloud Storage and Datastore, and to de-identify (tokenize, mask, format-preserving-encrypt, redact) data before it lands in analytics. Apply BigQuery column-level security, dynamic data masking, and row-level security with policy tags from Dataplex/Data Catalog.
• Prevent exfiltration end-to-end. Combine VPC-SC (network egress of data) + DLP (content inspection) + iam.allowedPolicyMemberDomains (no sharing to external identities) + CMEK (revoke the key, revoke the data).
• Protect data in use with Confidential Computing (Confidential VMs / Confidential GKE Nodes, memory encrypted while processing) for the most sensitive analytics.

The three planes at a glance.

Sub-component 3: Compliance

What it is. The discipline of demonstrating, with evidence, that your Google Cloud estate meets the regulatory, contractual and internal-policy obligations you are bound by (PCI-DSS, HIPAA, ISO 27001, SOC 2, GDPR, DPDP, FedRAMP, RBI/IRDAI/sovereign mandates, etc.) — and doing so continuously rather than as a once-a-year scramble. Compliance in the CAF is the bridge between technical posture and the business’s licence to operate; it turns “we have controls” into “we can prove the control to an auditor on demand.”

Why it matters. In regulated industries, compliance is not optional and not cheap to fake. The CAF distinguishes a Tactical organization — which assembles audit evidence manually, screenshot by screenshot, in a panic before each audit — from a Transformational one that produces continuous, automated compliance evidence as a by-product of its posture tooling. The difference is the cost of every audit, the ability to enter regulated markets at all, and whether a control gap is found by you (cheap) or by a regulator (expensive). Crucially, the CAF expects you to internalize the shared responsibility model: Google certifies the platform; you are responsible for configuring your workloads compliantly and evidencing it.

How to do it well.

• Map controls to a framework, then automate the evidence. Pick your control frameworks, then use Security Command Center compliance reports (which map live findings to PCI-DSS, NIST 800-53, ISO 27001, CIS GCP Benchmark, HIPAA, SOC 2) and Assured Workloads to enforce the control set rather than merely check it.
• Use Assured Workloads for hard regulatory/sovereignty boundaries. Assured Workloads creates a compliance-controlled environment that enforces data residency, personnel access controls (e.g. EU/US-only support personnel), provider access transparency, and an approved product set for regimes like FedRAMP High/Moderate, CJIS, IL4/IL5, ITAR, HIPAA, and regional sovereign packages (EU, and Sovereign Controls offerings). This is how you bind residency and operational-sovereignty controls technically, not just on paper.
• Evidence the platform’s certifications. Pull Google’s own audit reports, certifications and CAIQ from Compliance Reports Manager to satisfy the platform half of shared responsibility, and use Access Transparency / Access Approval so you can prove (and gate) any Google operational access to your data.
• Make evidence continuous and immutable. Centralize Cloud Audit Logs (Admin Activity, Data Access, System Event, Policy Denied) into a log sink to a locked, retention-policy’d BigQuery dataset / Cloud Storage bucket so the audit trail is tamper-evident and queryable. Treat policy-as-code itself (Org Policy, IAM, firewall in Terraform) as compliance evidence — the Git history is your change-control record.
• Govern data residency with gcp.resourceLocations Org Policy constraints and region-locked resources, mapped to your DPDP/GDPR/sovereign obligations.

Compliance toolchain.

Artifacts & decisions: a control-to-framework mapping (control → framework → GCP enforcing service → evidence source), the Assured Workloads folder design for regulated workloads, the audit-log architecture (sinks, destinations, retention locks, who can read), a data-residency policy enforced via Org Policy, and a shared-responsibility matrix the auditor can read.

Sub-component 4: Proactive threat management and defense-in-depth

What it is. The operational arm of Secure: the people, process and tooling that detect, investigate, and respond to active threats in near-real-time, layered so that no single control failure is fatal (defense-in-depth), and increasingly proactive — hunting for threats and automating response rather than waiting for an alert to be triaged by a human. Posture is about reducing exposure (the static state); threat management is about handling the adversary (the dynamic event). A mature Secure theme needs both: you minimize the attack surface and you assume breach and instrument for it.

Why it matters. No posture is perfect; a determined adversary will eventually find a gap, an insider will misuse access, or a supply-chain dependency will be compromised. The CAF’s top maturity rung is reserved for organizations that have moved from reactive security operations (a ticket gets filed, someone looks at it days later) to proactive operations (threats are detected in seconds, enriched with context, and frequently remediated by automation), and that have layered controls so that defeating one (say, a stolen credential) still runs into the next (VPC-SC blocks the exfil, DLP flags the content, the anomaly trips Event Threat Detection). Defense-in-depth is the architectural principle; proactive threat management is its operational expression.

How to do it well.

• Detect across every layer (the depth). Layer GCP’s native detection: Event Threat Detection (SCC Premium) mines Cloud Audit/VPC Flow/DNS logs for IAM anomalies, brute force, crypto-mining, data exfiltration and malware C2; Container Threat Detection and VM Threat Detection watch runtime behaviour and memory for kernel rootkits and miners; Cloud IDS does deep packet inspection on network traffic; Sensitive Actions Service flags high-risk operations (e.g. disabling logging). These produce SCC findings — one pane of glass.
• Aggregate into a SIEM and hunt. Feed everything into Google Security Operations (Google SecOps, formerly Chronicle) — a cloud-native SIEM with sub-second search over petabytes, built-in Applied Threat Intelligence from Mandiant and VirusTotal, UEBA, and detection-as-code via the YARA-L rule language. This is where proactive threat hunting happens: you write detections, run retro-hunts against a year of telemetry, and enrich alerts with Mandiant’s frontline intel.
• Automate the response (SOAR). Use Google SecOps SOAR (formerly Siemplify) for case management and playbooks that auto-enrich, auto-contain (quarantine a VM, revoke a session, disable a key, isolate a network), and route to the right responder — collapsing mean-time-to-respond from hours to seconds for known patterns.
• Shift detection left and harden the supply chain. Adopt Software Delivery Shielding / Software Supply Chain Security: Binary Authorization (only signed, attested images deploy), Artifact Analysis / Artifact Registry vulnerability scanning, Assured Open Source Software, and SLSA-aligned provenance, so threats are caught in CI before they ever run in production. Use Shielded VMs and Confidential Computing to harden the runtime itself.
• Instrument the human loop. Stand up (or buy) a SOC function, define incident-response runbooks and severities, run purple-team / tabletop exercises, and engage Mandiant for incident-response retainers and threat assessments. Detection without a tested response process is theatre.

The defense-in-depth layers and what holds each.

Threat-management KPIs.

Artifacts & decisions: the detection architecture (which detectors → SCC → SecOps), YARA-L detection content under version control, SOAR playbooks for the top incident types, an incident-response plan with severities and runbooks, the Binary Authorization policy and CI integration, and a Mandiant / IR-retainer decision.

How Secure interlocks with Learn, Lead, and Scale

Google’s CAF is deliberately four themes, not one, because security maturity is bounded by the other three — you cannot buy a Transformational Secure posture and bolt it onto a Tactical organisation. The four themes move together or not at all.

• Learn feeds Secure the skills. VPC Service Controls, SecOps YARA-L detections, CMEK key hierarchies and Assured Workloads are not turn-key; a team that has not built the muscle will misconfigure the very controls meant to protect them (a badly scoped perimeter that locks out production is a classic Learn gap that surfaces as a Secure incident). Every rung you climb on Secure assumes a matching rung on Learn.
• Lead gives Secure its authority. Guardrails only work if someone can enforce them over the objections of a team in a hurry. The Lead theme supplies the executive sponsor, the governance body that owns the Org Policy constraints, and — crucially — the CISO as the named owner of Secure. Without that mandate, iam.disableServiceAccountKeyCreation is a polite suggestion, not a guardrail.
• Scale is where Secure ships. The Scale theme’s landing zone, project factory and golden CI/CD pipeline are the delivery vehicle for Secure. This is what “shift left” means concretely: a project vended by the factory is born with IAM, Org Policy, logging and a VPC-SC-ready posture already wired; Binary Authorization lives in the golden pipeline and belongs to both themes at once. Security that ships as code with every landing-zone change is the same motion as Scale’s automation.
• Secure gives the others their licence to grow. The relationship runs both ways: Learn, Lead and Scale let Secure mature, and a credible Secure posture is what lets the business enter regulated markets, sign enterprise customers, and scale without the board applying the brakes.

The practical takeaway: assess Secure alongside the other three on the CAF Overview radar, and sequence the work so a Secure epic never gets ahead of the Learn skills and Lead mandate that make it stick.

Going deeper

This section is for the reader who already gets the concepts and wants the internals, the edge cases, and the “how do I not lock myself out” detail. All identifiers are placeholders; none of the snippets were run live, but each reflects the current GCP surface.

Organization Policy: managed vs custom constraints, and the dry-run safety net

Org Policy constraints come in two shapes. Boolean constraints (e.g. iam.disableServiceAccountKeyCreation, storage.publicAccessPrevention) are on/off. List constraints (e.g. gcp.resourceLocations, iam.allowedPolicyMemberDomains, compute.vmExternalIpAccess) allow or deny specific values. Managed constraints are the ones Google ships; custom constraints let you write your own rule in CEL against a resource type when Google has no managed constraint for what you need. Express all of it as Terraform so the Git history is your change-control evidence:

# Boolean guardrail — no exportable service-account keys, anywhere under the org
resource "google_org_policy_policy" "disable_sa_keys" {
  name   = "organizations/123456789012/policies/iam.disableServiceAccountKeyCreation"
  parent = "organizations/123456789012"
  spec {
    rules { enforce = "TRUE" }
  }
}

# List guardrail — sharing restricted to your Cloud Identity customer ID(s)
resource "google_org_policy_policy" "domain_restricted_sharing" {
  name   = "organizations/123456789012/policies/iam.allowedPolicyMemberDomains"
  parent = "organizations/123456789012"
  spec {
    rules {
      values { allowed_values = ["C0xxxxxxx"] } # directory customer ID, not the domain string
    }
  }
}

For anything Google does not ship, a custom constraint enforces your own rule — here, “every VM must carry a data-classification label” — using CEL over the resource:

resource "google_org_policy_custom_constraint" "require_dataclass_label" {
  name           = "custom.requireDataClassLabel"
  parent         = "organizations/123456789012"
  display_name   = "Require a data-classification label"
  description     = "Every Compute Engine instance must declare a data-classification label."
  action_type    = "DENY"
  condition      = "!has(resource.labels) || !('data-classification' in resource.labels)"
  method_types   = ["CREATE", "UPDATE"]
  resource_types = ["compute.googleapis.com/Instance"]
}

The equivalent YAML that gcloud org-policies set-custom-constraint constraint.yaml consumes (useful in a pipeline that is not Terraform-native):

name: organizations/123456789012/customConstraints/custom.requireDataClassLabel
resourceTypes:
  - compute.googleapis.com/Instance
methodTypes:
  - CREATE
  - UPDATE
condition: "has(resource.labels) && 'data-classification' in resource.labels"
actionType: DENY
displayName: Require a data-classification label
description: Every Compute Engine instance must declare a data-classification label.

Two operational nuances beginners miss. Inheritance is not automatic override: a child folder can reset or merge with the parent via inherit_from_parent, so audit the effective policy at a node, not just the policy you set. And dry-run first: a constraint has both a live spec and a dryRunSpec (violations logged, nothing blocked) so you can measure the blast radius against real traffic before you enforce — indispensable before you turn on something like compute.vmExternalIpAccess across an estate that might have legitimate external IPs.

VPC Service Controls: the exfiltration boundary — and how not to lock yourself out

VPC-SC is the control IAM cannot replace. IAM decides whether a principal is allowed; VPC-SC decides whether the data may leave the perimeter at all — so a valid, correctly-authorized credential that has been stolen still cannot copy your BigQuery tables to an attacker’s project or a public bucket. A perimeter is a set of projects + a list of restricted services (the managed APIs it protects) + ingress/egress rules + access levels (from Access Context Manager: allow this identity from this device posture / IP range). The classic ways teams break production with it — and the fixes:

• The Terraform state bucket or CI runner sits outside the perimeter. Your pipeline suddenly cannot read state or push artifacts. Fix: put the automation project inside the perimeter, or add a precise ingress rule for it.
• Two perimeters need to talk. Use a perimeter bridge (a controlled, bidirectional allowance between named perimeters), not a hole punched in both.
• Private Google Access is not configured, so in-perimeter VMs cannot even reach the APIs. Fix: route *.googleapis.com to the restricted.googleapis.com VIP and set the DNS/routes.

The golden rule is dry-run before enforce — VPC-SC emits RESOURCES_EXIST_WITHIN_ACCESS_POLICY-style violation logs in dry-run so you can see exactly what would have broken:

# 1. Add restricted services to the DRY-RUN spec first — nothing is blocked yet
gcloud access-context-manager perimeters dry-run update prod_payments \
  --add-restricted-services=bigquery.googleapis.com,storage.googleapis.com \
  --policy=POLICY_ID

# 2. Watch the dry-run violation logs for days; confirm no legitimate flow would break
# 3. Only then promote the dry-run config to enforced
gcloud access-context-manager perimeters dry-run enforce prod_payments \
  --policy=POLICY_ID

Keyless everything: how Workload Identity Federation removes the secret

The exportable service-account key is the single most common real-world breach vector — a key.json in a Git repo, a CI variable, a laptop. Workload Identity Federation (WIF) removes it entirely: instead of a long-lived key, an external workload presents an OIDC/SAML token from its own IdP (GitHub’s token.actions.githubusercontent.com, AWS STS, your on-prem IdP), GCP’s Security Token Service exchanges it for a short-lived Google access token, and the workload impersonates a service account with no exportable secret in existence. The security control that makes this safe is the attribute-condition — without it, any GitHub repo in the world could mint tokens against your pool:

gcloud iam workload-identity-pools create github-pool \
  --location=global --display-name="GitHub Actions"

gcloud iam workload-identity-pools providers create-oidc github-provider \
  --location=global --workload-identity-pool=github-pool \
  --issuer-uri="https://token.actions.githubusercontent.com" \
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository" \
  --attribute-condition="assertion.repository_owner == 'cygnet-bancorp'"   # <-- the critical guard

You then grant only the specific principalSet://…/attribute.repository/cygnet-bancorp/payments-api the roles/iam.workloadIdentityUser on the target service account. For GKE, the in-cluster equivalent is Workload Identity, which binds a Kubernetes ServiceAccount to a Google service account so pods get short-lived credentials with no node-level key. Pair either with the iam.disableServiceAccountKeyCreation guardrail above and the exportable-key attack surface goes to zero.

Posture-as-code and finding automation at scale

A dashboard is not the endpoint — automated response is. Two mechanisms take posture from “visible” to “self-healing.” First, SCC security postures: a posture is a named, versioned bundle of Org Policy and Security Health Analytics settings that you deploy to an org, folder or project, after which SCC continuously reports drift from it — stricter for prod-payments than for sandbox. Second, Continuous Exports stream new findings to Pub/Sub, where a Cloud Function can auto-remediate the safe, unambiguous classes (revoke a public-bucket ACL, close a 0.0.0.0/0 rule) while routing the rest to a ticket:

# Stream active public-bucket findings to a Pub/Sub topic for auto-remediation
gcloud scc notifications create public-bucket-remediation \
  --organization=ORG_ID \
  --pubsub-topic=projects/PROJECT_ID/topics/scc-findings \
  --filter='category="PUBLIC_BUCKET_ACL" AND state="ACTIVE"'

Export the same findings to BigQuery for the trend line, and use mute rules to suppress the accepted-risk findings so the score reflects actionable exposure, not noise.

Crypto-shredding, Key Access Justifications, and the caveats that bite

CMEK uses envelope encryption: Cloud KMS holds a key-encryption-key that wraps the data-encryption-keys, so destroying the KMS key cryptographically shreds the data — the fastest possible “delete” for a residency or right-to-erasure obligation. But that power cuts both ways, and these caveats are where teams get hurt:

• KMS availability is data availability. If the key is disabled, in the wrong region, or its permissions are broken, every service that needs it fails to read the data. Treat the key hierarchy and its IAM as production-critical.
• Key destruction is irreversible after the scheduled-destroy window (there is a mandatory delay you can cancel within — after that, the data is gone for good).
• Key Access Justifications (KAJ) and External Key Manager (EKM) let you deny Google itself operational access, or hold the key entirely off-Google — the strongest sovereignty posture, at the cost of operational complexity and an external-KMS dependency.

Finally, the cost, quota and IAM caveats that shape the whole programme: SCC Enterprise and Google SecOps are priced tiers (budget them deliberately); Data Access audit logs are billed by volume, so enable them on sensitive services rather than everywhere; Assured Workloads restricts the available product set and generally must be created as a new folder/environment — you cannot retrofit a compliance regime onto an existing project; managing Org Policy needs roles/orgpolicy.policyAdmin at the org node, which is itself a privileged grant to protect. For the full perimeter mechanics, see the VPC Service Controls deep dive.

Real-world enterprise scenario

Company: Cygnet Bancorp, a mid-tier digital bank with ~9,000 employees, headquartered in Bengaluru, regulated by the RBI and expanding into the EU. Their Google Cloud estate has grown organically to ~140 projects across retail-banking, payments, data-analytics and a new Vertex AI fraud-scoring platform. A CAF assessment, grounded with Security Command Center evidence, rates them Tactical on Secure: IAM is a sprawl of individual Editor grants, 60+ exportable service-account keys exist, there are no Organization Policies, audit logs are scattered and unretained, public-bucket findings sit open for weeks, and “threat detection” means someone occasionally reads Cloud Logging. The CISO sponsors a 10-month program to reach Strategic on Secure (with the fraud platform and EU launch as the forcing functions), and the Cloud Center of Excellence owns delivery.

Decisions per sub-component.

• Advanced security posture. Cygnet enables SCC Enterprise at the org node (justified by the multi-cloud roadmap and the need for attack-path analysis). The CCoE ships an Organization Policy baseline as Terraform — disabling SA-key creation, external IPs, public bucket access, default networks, and restricting iam.allowedPolicyMemberDomains to Cygnet’s Cloud Identity domain plus an allowlist. A security posture is deployed per folder (stricter for prod-payments than for sandbox). Findings export to BigQuery; a Looker dashboard trends the posture score and critical-finding MTTR. Within eight weeks, open critical misconfigurations drop from 214 to 11, and the attack-path simulation surfaces (and the team closes) three toxic combinations leading to the cardholder-data store.

• Identity, network and data security. Cloud Identity is federated from Cygnet’s existing Okta with FIDO2 keys enforced for all engineers. IAM is rebuilt group-based and least-privilege at the folder level; the 60+ service-account keys are eliminated via Workload Identity Federation (for GitHub Actions CI) and GKE Workload Identity, and standing admin is replaced with Privileged Access Manager JIT elevation. On the network, the CCoE lands a Shared VPC hub-and-spoke and — the keystone control — wraps VPC Service Controls around BigQuery and Cloud Storage in prod-payments and prod-analytics, with Cloud Armor + Adaptive Protection fronting the customer apps. For data, all regulated datasets move to CMEK in Cloud HSM, Sensitive Data Protection (DLP) classifies and de-identifies PII before it reaches the fraud-analytics layer, and BigQuery column-level security with policy tags restricts who sees PAN and Aadhaar fields.

• Compliance. Cygnet maps controls to PCI-DSS (payments) and ISO 27001 / SOC 2 (org-wide), and stands up an Assured Workloads environment with EU sovereign controls and data residency for the EU launch, enforced alongside gcp.resourceLocations Org Policy. SCC compliance reports generate continuous PCI/ISO evidence; Cloud Audit Logs (including Data Access logs on payments services) flow to a retention-locked BigQuery sink as the tamper-evident trail; Access Transparency + Access Approval gate Google operational access. The PCI QSA’s evidence-gathering, previously a six-week manual scramble, becomes a set of saved SCC reports and BigQuery queries.

• Proactive threat management and defense-in-depth. All detectors — Event Threat Detection, Container & VM Threat Detection, Cloud IDS — feed SCC and then Google SecOps (Chronicle), where the SOC writes YARA-L detections enriched with Mandiant intel and runs weekly retro-hunts. SOAR playbooks auto-contain on high-confidence signals (quarantine VM, disable key, revoke session). The CI pipeline enforces Binary Authorization so only signed, scanned images reach GKE, and Confidential VMs run the fraud-scoring inference. A Mandiant IR retainer is signed and the first tabletop exercise is run against a simulated credential-theft-to-exfil scenario — which the layered controls (ETD alert → SOAR session-revoke → VPC-SC exfil-block) defeat in the drill.

Measurable outcome (month 10). Open critical SCC findings fall from 214 to under 15 and stay there; exportable service-account keys go from 60+ to 0; MTTD drops from days to ~4 minutes and MTTR for known patterns to under 5 minutes via SOAR; the PCI-DSS audit passes with continuous SCC evidence and no major findings; the EU launch ships on Assured Workloads with enforced residency; and the next CAF assessment rates Cygnet Strategic on Secure, with the enforced Org-Policy guardrails, VPC-SC perimeter, Assured Workloads boundary, and the SecOps SIEM/SOAR pipeline cited as the decisive evidence — and the fraud platform’s posture pushing toward Transformational.

Deliverables & checklist

• Organization Policy baseline as Terraform (SA-key, external-IP, public-access, default-network, domain-restricted sharing, resource-location constraints) enforced org-wide by inheritance
• Security Command Center enabled at the org node, tier chosen and justified (Standard/Premium/Enterprise), with per-folder security posture definitions deployed
• Findings → BigQuery export + Looker posture dashboard trending the security score and critical-finding MTTR
• Identity model: Cloud Identity federated from the enterprise IdP, phishing-resistant MFA, group-based least-privilege IAM at the right hierarchy node, PAM for JIT elevation
• Service-account-key elimination plan executed via Workload Identity Federation and GKE Workload Identity (keys → 0)
• Network security: Shared VPC + hub-and-spoke, VPC Service Controls perimeter around sensitive managed services, hierarchical firewall-as-code, Cloud Armor + Adaptive Protection, Private Service Connect / Private Google Access
• Data security: CMEK (Cloud KMS / HSM / EKM) standard for regulated data, Sensitive Data Protection (DLP) classification + de-identification, BigQuery column/row-level security, Confidential Computing where warranted
• Compliance: control-to-framework mapping, Assured Workloads boundary for regulated/sovereign workloads, SCC compliance reports, Access Transparency/Approval, data-residency Org Policy, retention-locked audit-log sink
• Threat management: detection architecture (ETD, Container/VM Threat Detection, Cloud IDS → SCC → Google SecOps SIEM/SOAR), YARA-L detection content, SOAR playbooks, an incident-response plan, Binary Authorization policy, and a Mandiant/IR-retainer decision
• Secure KPI dashboard: posture score & trend, critical-finding MTTR, MTTD/MTTR, key-count = 0, detection coverage, supply-chain assurance status

Common pitfalls

1. Treating Secure as a product checklist instead of an operating-model maturity. Turning on Security Command Center and declaring victory ignores that the theme is about how systematically and early security is built in. Avoid it by enforcing guardrails as code in the landing zone (Org Policy in Terraform) so the secure path is the default, and by trending a posture score over time, not a one-off snapshot.
2. Leaving exportable service-account keys (and standing privilege) in place. Long-lived keys and permanent Owner/Editor grants are the most common real-world breach vector and the easiest thing an auditor flags. Avoid it by disabling key creation org-wide, migrating to Workload Identity Federation, and using PAM so standing privilege trends to zero.
3. Posture without prevention — detecting misconfigurations you never stopped. A dashboard full of “public bucket” findings you remediate by hand forever is Tactical, not Strategic. Avoid it by pairing SCC detection with Organization Policy prevention (storage.publicAccessPrevention, etc.) so the bad state cannot be created in the first place.
4. Compliance as a once-a-year manual scramble. Assembling screenshots before each audit is expensive and fragile. Avoid it by generating continuous evidence from SCC compliance reports, enforcing hard boundaries with Assured Workloads, and centralizing Cloud Audit Logs to a retention-locked sink so the trail is always audit-ready.
5. Detection without response — alerts nobody actions. Wiring up Event Threat Detection but having no SOC, runbook, or automation means findings pile up unworked. Avoid it by aggregating into Google SecOps with SOAR playbooks for the top incident types and a tested incident-response plan (run the tabletop).
6. Skipping the network and data exfiltration controls because identity “feels” sufficient. Identity is the first layer, not the only one; a stolen-but-valid credential walks straight past IAM. Avoid it by adding VPC Service Controls (perimeter), DLP (content), domain-restricted sharing, and CMEK so defeating identity still hits three more layers — the essence of defense-in-depth.

Common beginner mistakes

These are the conceptual traps — the wrong mental model that makes people build the wrong thing — as distinct from the operational pitfalls above.

• “Security is a product I turn on.” The instinct is that enabling Security Command Center (or buying a WAF) is being secure. Why it’s wrong: the Secure theme measures maturity of an operating model, not a feature flag. A dashboard you never act on and never trend is still Tactical. Right model: prevent-as-code (Org Policy) + detect (SCC) + a trending score + a remediation runbook with owners and SLAs. The product is one ingredient, not the dish.
• “Google secures my cloud, so I’m covered.” Why it’s wrong: the shared-responsibility line puts your IAM, firewall rules, buckets, keys and data squarely on your side — and that is exactly where breaches happen. Google securing the hypervisor does nothing about your public bucket. Right model: learn precisely which half is yours (it slides with how managed the service is) and own it systematically.
• “Once someone is authenticated, they’re trusted.” This is the old perimeter mindset. Why it’s wrong: in zero-trust there is no trusted interior; a valid session can be stolen, and an insider is already “inside.” Right model: verify every request (identity + device + context), grant least privilege, and layer network/data controls so an authenticated-but-malicious principal still cannot exfiltrate.
• “Encryption at rest means my data is safe.” Why it’s wrong: default at-rest encryption defends against a stolen physical disk — it does nothing against a stolen credential or a misconfigured IAM policy, because the service decrypts transparently for any authorized caller. Right model: encryption is one layer; you still need least-privilege IAM, VPC-SC, DLP, and (for control) CMEK you can revoke.
• “A public-bucket finding just needs remediating.” Fixing it by hand feels productive. Why it’s wrong: you will remediate the same class forever while new ones appear. Right model: prevention beats detection — an Org Policy (storage.publicAccessPrevention) means the bad state cannot be created, turning an endless finding stream into a one-time guardrail.
• “More alerts means we’re more secure.” Why it’s wrong: detection without a tested response process is theatre; a thousand un-triaged findings is less safe than ten actioned ones, because the real signal drowns. Right model: aggregate into a SIEM, mute the accepted-risk noise, and wire SOAR playbooks + a runbook so alerts become actions.

Practice challenges

Work these in order — they escalate from “place the concept” to “design the control.” Try each before opening the solution.

1. (Beginner) Put it on the ladder. Classify each as Tactical, Strategic, or Transformational: (a) a team turns on SCC after a public-bucket incident and fixes findings by hand; (b) Org Policy guardrails inherit down the hierarchy and SCC is org-wide with a SOC; © posture is trended and SLO’d, and SOAR auto-remediates safe finding classes.

   <details><summary>Solution</summary>

   (a) Tactical — reactive, per-project, manual. (b) Strategic — standardised, centrally governed. © Transformational — automated, continuously assessed, self-healing. Why: the ladder is defined by how systematically and automatically security is built in, not by which products are enabled. </details>

2. (Beginner) Whose half is it? For each, say whether Google or you are responsible: (a) patching the hypervisor; (b) a firewall rule opened to 0.0.0.0/0; © encryption at rest by default; (d) a service account granted Owner; (e) physical datacenter access control.

   <details><summary>Solution</summary>

   (a) Google, (b) You, © Google (the default mechanism) though choosing CMEK is you, (d) You, (e) Google. Why: the shared-responsibility line puts configuration, IAM and data on your side; the platform substrate on Google’s — and (b) and (d) are exactly the misconfigurations that cause most breaches. </details>

3. (Intermediate) Stop public buckets org-wide. Write the guardrail that makes it impossible to create a public bucket anywhere under the organization — as code.

   <details><summary>Solution</summary>

   resource "google_org_policy_policy" "no_public_buckets" {
     name   = "organizations/ORG_ID/policies/storage.publicAccessPrevention"
     parent = "organizations/ORG_ID"
     spec {
       rules { enforce = "TRUE" }
     }
   }
   

   (Or gcloud resource-manager org-policies enable-enforce storage.publicAccessPrevention --organization=ORG_ID.) Why: this is prevention, not detection — the bad state can never be created, so it never becomes a finding to chase. </details>

4. (Intermediate) Defeat the stolen credential. An attacker steals a valid analyst session that has BigQuery read on your PII dataset. IAM already said “yes.” Name the layers that still stop the data leaving, and how each works.

   <details><summary>Solution</summary>

   VPC Service Controls denies egress to any project outside the perimeter or the internet; iam.allowedPolicyMemberDomains blocks sharing the dataset to an external identity; DLP + BigQuery column-level security flag the bulk-PII read and mask sensitive columns; CMEK means a raw copy is useless without KMS access (and you can revoke the key); Event Threat Detection → SOAR spots the anomaly and revokes the session. Why: defense-in-depth — IAM is only the first layer, and every subsequent layer is independent, so one stolen credential meets five more walls. </details>

5. (Advanced) Keyless CI. GitHub Actions must deploy to GCP with no service-account key. Sketch the Workload Identity Federation setup and name the single most important line that stops another organization’s repo from impersonating you.

   <details><summary>Solution</summary>

   Create a WIF pool and an OIDC provider with --issuer-uri=https://token.actions.githubusercontent.com, an --attribute-mapping for google.subject and attribute.repository, and — the critical guard — an --attribute-condition="assertion.repository_owner == 'your-org'". Then grant only the specific principalSet://…/attribute.repository/your-org/your-repo the roles/iam.workloadIdentityUser on the target service account. Why: the attribute-condition is the whole security boundary — without it, any repo on GitHub could mint tokens against your pool; with it, no exportable secret exists to leak. </details>

6. (Advanced) Prove it to the QSA. Your PCI assessor wants evidence that public-access-prevention was enforced all year and that nobody disabled Data Access logging. Design the evidence pipeline — no screenshots allowed.

   <details><summary>Solution</summary>

   Org Policy in Terraform (the Git history is the change-control record showing the constraint’s continuous enforcement); SCC compliance reports mapped to PCI-DSS for the live control state; Cloud Audit Logs (Admin Activity for Org Policy / IAM changes, plus the SetIamPolicy/logging-config events) routed to a retention-locked BigQuery sink; Sensitive Actions Service to flag any attempt to disable logging; then a saved BigQuery query the QSA runs directly. Why: continuous, tamper-evident, queryable evidence is a by-product of the posture tooling — no six-week manual scramble, and no gap a regulator can find that you couldn’t. </details>

Glossary

• Cloud Adoption Framework (CAF): Google’s model for scoring cloud readiness across four themes (Learn, Lead, Scale, Secure) on a Tactical → Strategic → Transformational ladder.
• Secure theme: the CAF theme measuring how systematically and early security is built into your cloud operating model; owned by the CISO.
• Tactical / Strategic / Transformational: the three maturity rungs — reactive-and-per-project / standardised-and-centrally-governed / automated-continuously-assessed-and-shifted-left.
• Zero-trust: “never trust, always verify” — authenticate and authorize every request on identity + context, regardless of network location.
• Defense-in-depth: layering independent controls (and assuming breach) so defeating one still runs the attacker into the next.
• Shared-responsibility model: Google secures the platform (hardware, hypervisor, datacenter); you secure your configuration and data. The line slides with how managed the service is; IAM and data are always yours.
• Security posture: the aggregate, measurable state of how exposed your estate is right now, plus the guardrails holding it in place.
• CSPM / CNAPP: Cloud Security Posture Management / Cloud-Native Application Protection Platform — the category Security Command Center occupies.
• Security Command Center (SCC): GCP’s native posture-management and threat-detection hub; tiers are Standard / Premium / Enterprise.
• Security Health Analytics: SCC’s detector library that continuously flags misconfigurations against CIS/PCI/NIST/ISO benchmarks.
• Attack Path Simulation / toxic combination: SCC Enterprise features that correlate several weaknesses into one ranked path to a high-value resource.
• Organization Policy: org-level constraints (boolean or list, managed or custom) that inherit down the resource hierarchy — the primary preventive guardrail.
• Guardrail vs gate: a guardrail (Org Policy) makes the secure path the default automatically; a gate (manual review) queues work behind a human — guardrails scale, gates do not.
• IAM (Identity and Access Management): the authorization system of members, roles, and policy bindings deciding who can do what to which resource.
• Service account (SA) / SA key: a machine identity; an SA key is a long-lived exportable secret — the most common breach vector, to be eliminated.
• Workload Identity Federation (WIF): keyless auth where an external workload exchanges its own OIDC/SAML token for a short-lived Google token — no exportable secret.
• Workload Identity (GKE): binds a Kubernetes ServiceAccount to a Google service account so pods get short-lived credentials without node keys.
• Privileged Access Manager (PAM): just-in-time, time-bound privilege elevation so standing admin trends to zero.
• IAM Conditions: attribute-based constraints on a grant (time, resource tag, etc.).
• IAP / BeyondCorp Enterprise: Identity-Aware Proxy and Google’s zero-trust access product — identity-and-context in front of apps/VMs so you can retire the VPN.
• VPC: Virtual Private Cloud, GCP’s software-defined network. Shared VPC centralises networking across projects.
• VPC Service Controls (VPC-SC): an identity-and-resource perimeter around managed services so even valid credentials cannot exfiltrate data out of it.
• Hierarchical firewall policy: firewall rules attached at org/folder nodes that inherit down.
• Cloud Armor / Adaptive Protection: managed WAF + ML-based L7 DDoS defence at the global load balancer edge.
• Private Google Access / Private Service Connect: reach Google APIs / services over private paths instead of the public internet.
• CMEK: Customer-Managed Encryption Keys in Cloud KMS — you control the key, so revoking it cryptographically shreds the data.
• Cloud KMS / Cloud HSM / EKM: key-management service / FIPS 140-2 L3 hardware keys / External Key Manager (keys held outside Google).
• Key Access Justifications (KAJ): lets you require a justification for (and deny) Google operational access to your keys.
• Sensitive Data Protection (DLP): discovers, classifies and de-identifies (tokenize/mask/redact) PII/PHI across BigQuery, Cloud Storage, Datastore.
• Column-level / row-level security: BigQuery access controls (via policy tags) that restrict which columns/rows a principal can read.
• Confidential Computing: Confidential VMs / GKE Nodes that keep memory encrypted while data is in use.
• Compliance: proving, with evidence, that your estate meets regulatory/contractual obligations — continuously, not once a year.
• Assured Workloads: a compliance-controlled environment enforcing residency, personnel-access and provider-access controls for regimes like FedRAMP, HIPAA, and EU sovereign packages.
• Access Transparency / Access Approval: logs and gates any Google operational access to your data.
• Cloud Audit Logs / log sink / retention lock: the Admin Activity / Data Access / System Event / Policy Denied trail, routed to a locked, retention-protected sink so it is tamper-evident.
• Event Threat Detection (ETD): SCC Premium detector mining audit/flow/DNS logs for IAM anomalies, brute force, crypto-mining, exfiltration, C2.
• Container / VM Threat Detection: runtime and memory detectors for rootkits, miners and memory attacks.
• Cloud IDS: deep-packet-inspection intrusion detection on network traffic.
• SIEM / SOAR: Security Information & Event Management / Security Orchestration, Automation & Response — aggregation-and-hunting / automated-response.
• Google SecOps (Chronicle): Google’s cloud-native SIEM+SOAR with sub-second petabyte search, Mandiant/VirusTotal intel, UEBA, and YARA-L.
• YARA-L: the detection-as-code rule language in Google SecOps.
• UEBA: User and Entity Behavior Analytics — anomaly detection on behavioural baselines.
• Mandiant: Google’s incident-response and threat-intelligence arm (retainers, tabletop, frontline intel).
• Binary Authorization / SLSA: deploy-time policy that only signed, attested images run / a framework for supply-chain provenance levels.
• MTTD / MTTR: Mean Time To Detect / Mean Time To Respond (also Remediate) — the core threat-management KPIs.
• CISO / CCoE: Chief Information Security Officer (owner of Secure) / Cloud Center of Excellence (delivery team).

What’s next

You have now completed all four themes of the series — Learn, Lead, Scale, and Secure; return to part 1, the Overview & Maturity Model, to assemble the four-theme scorecard, plot your radar chart, and sequence the prioritized epic backlog that turns these per-theme assessments into a funded cloud-adoption roadmap.