GCP Architecture & Security Review

Something prompted this. A penetration test came back worse than expected. An enterprise customer sent a security questionnaire with forty questions your team cannot answer in writing. A new CISO asked who has project owner, and nobody knew until they ran the query.

The underlying condition is usually the same. The estate grew one project at a time, each one provisioned by whoever needed it, and no single person now holds the whole picture. Security Command Center is switched on and reporting thousands of findings that nobody triages, because triaging them would take a month and there is no month available.

What makes this hard to fix internally is not skill. It is that the people who built the estate cannot see it fresh, and the people who could see it fresh do not have the context. An external review is worth paying for precisely because the reviewer has no attachment to the decisions being reviewed.

What gets assessed

The review works against the Google Cloud architecture framework, but the output is not a framework score. It is a list of specific things in your estate, each one with a project, a resource, and a fix.

• +IAM and organization policy. Who holds primitive roles, where service accounts have been granted more than they use, which org policy constraints are unset, and where a folder-level binding is quietly granting production access to a sandbox group.
• +Network topology and VPC Service Controls. Shared VPC structure, peering, egress paths, and whether service perimeters exist around the data that would matter in a breach. Perimeters in dry-run mode that were never enforced are a common finding.
• +KMS and secrets. Key rotation, separation between key admin and key user, and whether secrets sit in Secret Manager, in environment variables, or in a repository.
• +Security Command Center. Existing findings triaged into a ranked list rather than an export. Most estates have a large volume of low-value findings obscuring a small number that matter.
• +Workload Identity. Where workloads still authenticate with downloaded service account keys, and what it would take to remove them.
• +External exposure. Public buckets, unauthenticated endpoints, load balancers without Cloud Armor, and any resource reachable from the internet that nobody remembers creating.
• +AI workload security. Where Vertex AI endpoints sit in the network, how they authenticate, and whether Model Armor policies filter prompts and responses on the paths that carry customer data.

What you get at the end

Three artefacts. A findings report where every item carries a severity, an affected resource, and an explanation of the actual exposure rather than a generic control description. A remediation plan sequenced by risk reduction per unit of effort, because the order matters more than the list. And Terraform for the fixes at the top — not pseudocode, not a recommendation to write Terraform.

The report is written to be read by two audiences without being written twice. The findings are technical enough for the engineer who has to act on them. The summary is direct enough to forward to a board without translation.

Where this review stops

This package assesses. It does not build. That boundary is deliberate: a reviewer who is also bidding to implement every finding has an incentive problem, and you should be suspicious of one who does not name it.

Remediation beyond the top-fix Terraform is a separate engagement, quoted separately, and you are free to have your own team do it or hire someone else. Application-layer security — code review, dependency analysis, business logic — is out of scope; this is an infrastructure review. Compliance certification is out of scope entirely. The findings support a SOC 2 or ISO audit, but Sumech is not an auditor and does not issue attestations.

Deliverable. Severity-ranked findings report, remediation plan, and Terraform for the top fixes.