Why Enterprise Deals Stall at the Security Review — and How to Fix It Before It Happens
I’ve seen this pattern more times than I can count. A B2B SaaS company gets deep into an enterprise sales cycle — procurement is engaged, legal is aligned, the technical team has done a demo — and then the security questionnaire lands. Suddenly the deal is on hold. Engineering is scrambling to answer questions about encryption at rest, network segmentation, IAM controls, and audit logging. The answers either don’t exist or can’t be evidenced quickly enough. The deal slips a quarter. Sometimes it dies.
The frustrating part is that this is almost always preventable. Enterprise security reviews don’t ask for anything exotic. They ask for the same set of controls every time — and if your GCP platform was built with those controls in mind from the start, the questionnaire becomes a two-hour exercise instead of a two-month crisis.
I work with engineering teams in Canada and the USA — CTOs and founders at B2B SaaS companies running on GCP — to build platforms that pass enterprise security reviews before the question is asked. This is what I’ve learned about what reviewers actually check and how to be ready for it.
What Enterprise Security Reviewers Actually Look For
The questionnaire varies by company but the underlying requirements are consistent. Every enterprise security review I’ve encountered maps to five core areas.
Identity and access management. Reviewers want to know who can access what, how access is granted and revoked, and whether there is evidence of least-privilege enforcement. In GCP this means org-level IAM structure, group-based access rather than direct user bindings, no primitive roles (Owner, Editor) on production projects, and a documented process for access reviews. The specific finding I see most often: service accounts with Editor or Owner roles, often created during a fast early build and never cleaned up.
Workload Identity Federation matters here too — if your CI/CD pipeline or GKE workloads are still using downloaded service account keys, that’s an immediate flag. Reviewers from regulated enterprises and government-adjacent buyers treat static credentials as a critical finding. I covered the migration path in detail in the Workload Identity Federation post.
Network segmentation. Reviewers check whether your production workloads are reachable from the internet by default and whether internal services are over-permissioned. In GCP the baseline is a custom mode VPC — not a default VPC with open internal rules — with explicit least-privilege firewall rules between subnets, private cluster networking for GKE, and Private Google Access so workloads reach GCP APIs without external IPs.
For regulated data, VPC Service Controls is what enterprise reviewers specifically ask for. A VPC Service Controls perimeter means that even if credentials are compromised, data cannot be exfiltrated outside the defined boundary. This is the control that satisfies data residency and data perimeter requirements for Canadian enterprises under PIPEDA and FINTRAC, and for US enterprises under HIPAA and SOC 2.
Encryption. Encryption at rest and in transit is table stakes — GCP provides it by default. What reviewers actually dig into is key management. Are you using Google-managed keys or customer-managed keys (CMEK) via Cloud KMS? For regulated industries the answer needs to be CMEK with documented key rotation and access controls. I set this up as part of the Landing Zone Blueprint so it’s consistent across every service from day one.
Audit logging and monitoring. Reviewers want evidence that you know what is happening in your environment — who accessed what, when, and from where. In GCP this means Cloud Audit Logs enabled for Admin Activity, Data Access, and System Events across all projects, log export to a centralised GCS bucket or BigQuery dataset with retention that meets compliance requirements, and alerting on anomalous activity. The finding I see here: Data Access audit logs disabled by default on many services to control cost, leaving gaps in the audit trail that a reviewer will catch immediately.
Incident response and DR. Enterprise buyers want to know what happens when something goes wrong. This means a documented incident response process, a tested DR plan with defined RTO and RPO, and evidence that failover actually works. I covered the DR architecture in detail in the GCP Disaster Recovery and HA page.
The Platform Posture That Passes Reviews
The controls above are not hard to implement. What makes them hard is implementing them consistently across a platform that grew organically — where different teams provisioned resources differently, where org policies were never enforced, and where the security posture was never formally documented.
The answer is a structured platform foundation built on the SCALE Framework — Security by Design, Cloud-Native, Automation/IaC, Lifecycle Ops, Elastic Scalability. When security controls are embedded in the platform foundation rather than applied workload by workload, the security review becomes a documentation exercise rather than a remediation sprint.
Specifically, the GCP Landing Zone Blueprint I deliver establishes the org hierarchy, IAM boundaries, network topology, audit logging, and org policy constraints as Terraform-managed baseline configuration. Every project created in the org inherits these controls automatically. When a reviewer asks “how do you enforce least-privilege IAM across all projects” the answer is an org policy and a Terraform module — not a manual process that depends on individual engineers doing the right thing.
SOC 2 Is the Threshold for Most Enterprise Buyers
In my experience working with B2B SaaS companies in Canada and the USA, SOC 2 Type II is the practical threshold for most enterprise buyers. A SOC 2 report doesn’t guarantee you’ll pass every security review, but it signals that your security posture has been independently assessed and that you have documented controls in place.
For GCP specifically, SOC 2 maps directly to the controls above — CC6 (logical access), CC7 (system operations and monitoring), CC8 (change management via IaC), and CC9 (risk mitigation including DR). If your GCP platform is structured correctly, the evidence for most of these controls is already in your audit logs, your Terraform state, and your IAM configuration.
I’ve worked with SaaS teams mid-audit — including a startup using Drata for continuous compliance monitoring — where the primary remediation work was GCP platform structure rather than policy writing. The policies existed. The technical controls didn’t match them.
What I Do for Teams Facing This Problem
I work directly with CTOs and engineering leads at B2B SaaS companies in Toronto, across Canada, and in the USA who are either facing an imminent enterprise security review or want to get ahead of it before the next sales cycle.
The engagement typically starts with an Architecture Review — I assess your current GCP posture against the five control areas above, identify the specific gaps that would fail an enterprise review, and produce a prioritised remediation plan. For teams that want implementation, I build the remediated platform foundation directly.
No account managers, no junior engineers, no handoffs. More about my background and approach →
Related Reading
