Security foundations are staged systems, not a Terraform apply

Google Cloud’s security-foundation blueprint begins before infrastructure deployment: establish Cloud Identity and domain ownership, secure administrator accounts, choose the identity source of truth, create access-control groups, decide network topology, and select source-control and CI/CD mechanisms.

That sequence prevents a common inversion where infrastructure exists before the organisation has decided who controls it. Billing, identity, groups, address planning and hybrid connectivity are part of the foundation because they shape every later workload.

The referenced terraform-example-foundation is deployed as an ordered pipeline: bootstrap the foundation pipeline, configure organisation-level resources, create environments, deploy the chosen network topology, create project infrastructure, and optionally deploy sample application infrastructure.

Staging makes dependencies explicit. Organisation policy should exist before workload projects depend on it; environments should exist before networks are attached; networking should be governed before application infrastructure assumes reachability.

• 0-bootstrap: foundation pipeline
• 1-org: organisation-level resources
• 2-environments: environment structure
• 3-networks: Shared VPC or hub-and-spoke
• 4-projects: infrastructure pipeline
• 5-app-infra: optional sample application infrastructure

The source explicitly includes work after the initial IaC deployment: complete on-premises changes, activate Security Command Center capabilities, export billing data, enable transparency and identity controls, assess additional controls for sensitive workloads and connect the environment to operational practices.

This matters because a successful apply only proves resource creation. It does not prove that monitoring, support, administration, compliance and incident processes are operating.

For sensitive workloads, the blueprint identifies controls such as VPC Service Controls, resource-location restrictions, Assured Workloads and expanded data-access logging. It also warns that additional controls can introduce cost and operational complexity and may break existing service paths until exceptions are designed.

Security maturity is not the maximum number of controls enabled. It is the ability to choose controls against compliance requirements, risk appetite and data sensitivity, then operate the resulting constraints deliberately.

The source documents alternatives for resource hierarchy, organisation-policy placement, CI/CD tooling, source repositories, identity providers, regions, address allocation, hybrid networking, VPC Service Controls, secrets, key management, log sinks and infrastructure-pipeline granularity.

A reference foundation is most valuable as a decision framework. Copying defaults without understanding the control objective can create an environment that is technically consistent and organisationally wrong.

The durable outcome is not a collection of projects. It is a governed substrate where identity, network boundaries, policy inheritance, deployment authority, logging and operational responsibility are established before workload teams arrive.

That is what allows application delivery to move faster without weakening control: teams inherit a prepared environment rather than renegotiating the security model for every system.

Primary source: Google Cloud Architecture Center, Security Foundations Blueprint summary. Canonical source: https://docs.cloud.google.com/architecture/blueprints/security-foundations/summary . Source capture reviewed 7 August 2026.

This note preserves the blueprint’s staged deployment model, post-IaC requirements, sensitive-workload controls and documented alternatives, while treating them as general foundation-design principles.