A sound Google Cloud baseline sets up an organization with folders by environment, groups-based access, organization policy constraints, centralized audit logging and private-by-default networking before the first workload ships. Google's enterprise foundations blueprint describes this pattern and provides Terraform to deploy it.
What does Google recommend as a foundation?
The enterprise foundations blueprint, formerly called the security foundations blueprint and last reviewed by Google in May 2025, describes a baseline of resources, configurations and capabilities for adopting Google Cloud. It is meant either as a complete starting point or as a reference to review an existing environment. The guide pairs with a Terraform example repository.
Google states the shared responsibility plainly: Google Cloud services benefit from Google's infrastructure security design, and it is your responsibility to design security into what you build on top. The blueprint uses three kinds of control: policy controls that prevent risky configurations, architecture controls such as network and resource hierarchy, and detective controls that find anomalous behavior.
What are the key decisions in the blueprint?
From Google's summary:
- Infrastructure managed as code in Terraform, in version control, deployed through a CI/CD pipeline that validates policy before deployment.
- Users and groups synchronized from your existing identity provider, with single sign-on there.
- Allow policies applied to groups by job function, with view-only access to foundation resources for most people and changes made through the pipeline's privileged service accounts.
- A single organization with folders that organise projects by environment, and projects labelled for governance and cost attribution.
- Shared VPC networking where all paths between on-premises, VPCs and Google services are private, with no inbound or outbound public internet traffic by default.
- Aggregated log sinks collecting security and audit logs into a central project for retention and analysis.
- Organization policy constraints that prevent high-risk configurations.
- Centralized projects for secrets and for encryption keys.
- Security Command Center for threat detection and monitoring.
Which organization policies come first?
Google publishes a catalog of organization policy constraints. A starter set worth reading in the catalog, using the constraint names Google lists:
- iam.disableServiceAccountKeyCreation, to stop downloadable service account keys.
- iam.allowedPolicyMemberDomains, to limit which identity domains can be granted access.
- compute.vmExternalIpAccess, to control which VMs may have external IP addresses.
- compute.requireOsLogin, to tie VM SSH access to IAM identities.
- compute.skipDefaultNetworkCreation, so new projects do not start with the default network.
- gcp.resourceLocations, to restrict where resources may be created.
- storage.publicAccessPrevention and storage.uniformBucketLevelAccess, to harden buckets.
Read each constraint's description in the catalog and test it in a non-production folder before enforcing, because some will break existing workflows.
What does a first week look like?
Constructed example. A startup gets a new organization. Day one: create admin groups, enforce multi-factor authentication in the identity provider, and remove individual owner roles. Day two: create folders for production, non-production and shared services. Day three: apply the starter constraints at the organization level, with a documented exception path. Day four: create a logging project with an aggregated sink for audit logs and set retention. Day five: put networks in a Shared VPC host project, private by default, and deploy via Terraform from a pipeline, so console changes stop being the norm.
What to do
- Create the organization, admin groups and break-glass accounts, with strong authentication.
- Assign access to groups, not individuals, and avoid broad primitive roles.
- Build a folder hierarchy by environment and apply labels for owner and cost.
- Enforce starter organization policy constraints after testing them.
- Route audit and security logs to a central project with retention set.
- Use private networking by default, with explicit paths for outbound access.
- Manage everything with infrastructure as code and policy checks in the pipeline.
- Turn on threat detection and review its findings on a schedule.
- Scan container images and dependencies before they deploy to the new projects.
Safeguard can scan dependencies and container images that you deploy to Google Cloud, and its policies and gates can block risky changes before deployment. Cloud account controls stay in your Google Cloud configuration.
Quick check
Should I download service account keys?
Avoid it. Google offers an organization policy constraint, iam.disableServiceAccountKeyCreation, to prevent key creation. Prefer attached service accounts and short-lived credentials.
Where do I start if I already have projects?
Use the blueprint as a review checklist. Compare your hierarchy, access, logging, networking and policies against it, then fix the highest-risk gaps first.
Sources
Last reviewed: 18 October 2026.
