GCP Cloud Infrastructure
A Google Cloud organization as code you own: projects vend through a factory, guardrails deny at the org, regulated data sits inside a service perimeter, and no service-account key exists to leak. Built in 4-8 weeks.
GCP Security Foundations + CFT
Terraform + CFT modules
Shared VPC + VPC Service Controls
4-8 weeks for starter org
These are design rules of the delivery kit shown below, enforced by org policy and CI, and the runbooks exist on disk before the first client call.
Four GCP debts that compound quietly.
Projects nobody can account for
Every team made its own projects, IAM is per-user, and the invoice splits by nothing. A resource hierarchy with a project factory gives every workload an owner, a budget, a folder and enforced labels from the minute it exists.
Service-account keys everywhere
A JSON key is a password that never rotates, lives in files and works from anywhere; most GCP breaches start with one. Here key creation is disabled at the organization and CI authenticates through Workload Identity Federation, so the leak path is closed by construction.
The data perimeter scheduled for "later"
IAM decides who may call an API; it does not stop a credentialed identity copying BigQuery datasets out of the organization. VPC Service Controls closes exactly that path, and our dry-run-first procedure means it lands without breaking integrations.
EU residency promised, unenforced
You told customers their data stays in the EU; nothing in the console holds that promise. An org policy pins resource locations to EU, audit logs land in a retention-locked bucket, and the auditor gets evidence instead of assurances.
Projects come from a factory. Mistakes stop at the org.
Three views of the operating model: a project vended from pull request to handover, the guardrails denying the classic mistakes before they exist, and the delivery kit folder by folder, Terraform included.
Four foundations, all in your organization and your repo.
An organization, designed and documented
Folder hierarchy per ADR, project naming that survives growth, billing export to BigQuery from week 1, and a decommissioned folder so retirement is a state instead of a mystery.
CFT-aligned Terraform in your org
Five modules: hierarchy, project factory, Shared VPC, org policies, keyless IAM. Cloud Foundation Toolkit is the starting point, adapted to your reality rather than run stock.
Identity with zero standing keys
Group-based IAM, Workload Identity Federation for pipelines, break-glass with a quarterly sign-in test, and a monthly key hunt that drains any stock predating the policy.
Guardrails that produce audit evidence
Org policies mapped to Security Foundations and CIS, SCC triage with severity SLAs, and a control matrix where the pipeline itself is the evidence source for DORA, NIS2 and ISO 27001.
In scope
- GCP organization design + folder hierarchy
- Shared VPC + VPC SC perimeters
- Cloud Identity / Workspace federation
- Terraform baseline aligned to CFT
- Organization policies + SCC Premium baseline
- Runbook library for top 10 platform tasks
Deliberately out of scope
- Application migration to GCP (separate per-workload scope)
- Anthos on-prem / multi-cloud control plane
- Custom BigQuery data-warehouse design (separate scope)
- Looker deployment + modeling
Start with the organization. Grow into the perimeter.
Each tier carries its delivery arc inside it: discovery and ADRs first, build with a vended pilot project next, then operate or a documented hand-off. The scope sheet gets signed during discovery.
Essential
The starter organization, built and handed over.
- Weeks 1-2: discovery, Security Foundations gap read, ADR set signed
- Weeks 3-6: hierarchy + factory + Shared VPC + org policies deployed
- First workload project vended through the factory
- Billing export + budgets on every project from day 1
- 10 platform runbooks + 30-day hand-off support window
Outcome
A governed GCP estate your own team operates, with the design decisions on paper.
Operate
The landing zone plus the platform rhythm that keeps it honest.
- Everything in Essential
- Monthly platform review: estate integrity, posture, cost by owner
- SCC finding triage with severity SLAs
- Monthly SA-key hunt + exception-expiry review
- Named platform engineer, same-day incident triage
Outcome
The estate stays as designed, and the monthly review proves it with pipeline evidence.
Sovereign
Perimeter-grade isolation for regulated, multi-region estates.
- Everything in Operate
- VPC Service Controls programme with dry-run discipline
- Multi-region topology + residency evidence
- Audit-grade change records mapped to DORA / NIS2 / ISO 27001
- Exit kit + state hand-off, rehearsed annually
Outcome
Regulated data sits inside an enforced perimeter, and leaving us is a documented procedure.
Honest answers to the questions buyers actually ask.
Do you use the Cloud Foundation Toolkit (CFT)?
+
Yes - as the starting point. We adapt CFT modules to your reality rather than running them stock. Stock CFT is a great reference, but every org has 10-20% custom shape.
Anthos / GKE in scope?
+
GKE foundations (cluster design, network, IAM, GKE-Hub) yes. Anthos on-prem / multi-cloud control plane is a separate engagement.
We already have BeyondCorp / IAP. Do we need VPC SC too?
+
Different layers. IAP / BeyondCorp protect the access plane (user → app). VPC SC protects the data plane (workload → service). Most regulated estates need both.
Are you a Google partner?
+
Honest status: no partner tier is claimed. Our Google reseller application is pending, so GCP consumption and Workspace stay billed directly by Google, at Google prices, with zero markup from us either way. The engineering in this service needs no reseller badge: it lives in your organization and your repository.
Azure or GCP: which do you actually recommend?
+
We build both, with the same kit discipline (the Azure sibling of this page exists). The honest answer is workload gravity: M365-heavy organisations usually land on Azure, data-platform and Kubernetes-heavy teams often fit GCP better. If the answer were always one cloud, we would only publish one page.
Do we need VPC Service Controls from day one?
+
Only around data that warrants it. The perimeter starts on the projects holding regulated BigQuery and Storage, grown deliberately, and every change runs in dry-run mode for days before enforcement. A perimeter around everything on day one is where VPC SC projects historically go to die, so we deliberately do not do that.
We already have projects in GCP. Greenfield only?
+
Brownfield is the normal case. Existing projects are inventoried, imported into Terraform state so the plan tells the truth, then remediated in reviewed steps: labels and budgets first, network moves in windows, key elimination on a drain schedule. Nothing moves without its owner knowing the window.
What happens to the Terraform if we part ways?
+
Nothing: it was in your GitHub organisation and your state bucket from the first commit. The exit kit adds the state hand-off, where your successor proves the toolchain by running a plan that comes back empty, plus the honest list of anything unfinished.
The organization is the floor. Build on it.
Cloud Infrastructure Modernization
The architecture narrative around landing zones, cloud-agnostic by design.
OpenAzure Cloud Infrastructure
The Azure sibling: same kit discipline, CAF instead of CFT, PIM instead of WIF-only.
OpenCloud Licensing & Procurement
The audit covers GCP spend too, whichever channel bills it.
OpenSettle the folder and project layout while it still costs one meeting.
Organisation policy, IAM boundary and project factory are the decisions that are expensive to reverse. The workshop takes them first.