How to sequence Google Cloud security debt before it stalls a business deal

A public Cloud Function running as the default Compute Engine service account, with that account still carrying the Editor role, gives anyone who reaches the function a path to read, modify, or delete almost everything in the project. Each of those three settings is a routine default in a young Google Cloud project. Together, they form one of the most common routes to full project compromise.

Most of the thousands of entries in a Security Command Center dashboard never rise to that level. Learning to tell the two apart is the core problem in Google Cloud security once a company has been shipping for a while.

Security debt does not threaten a business evenly.

• A misconfiguration no attacker can reach costs nothing until the day it becomes reachable.
• A cluster of medium-severity gaps that link into a route to your customer database is already an active risk.

Severity labels and finding counts cannot separate those two cases, because they score issues in isolation and the danger lives in how they combine.

This becomes urgent at a specific moment, and for most mid-market companies that moment arrives with a deal, not a breach. A prospective enterprise customer reaches the security review stage of procurement and sends a security questionnaire, and the clock that starts here is unforgiving. You get about seven days to complete the first round. How that round lands decides the deal.

A strong first round can close the deal fast, with no further questions. A vague-but-solid first round buys a second round, another roughly seven days to clarify and provide evidence, and the deal still goes through. A weak first round stalls it, and now you are three weeks deep and slipping. A bad first round can end it outright, with no second round and no deal. The asymmetry is the whole point: the same week of work produces a closed deal or a dead one depending only on whether your environment can answer the questions when they are first asked.

This is where most Google Cloud security advice stops being useful, because it assumes a clean project. The companies that need the advice shipped fast, took on debt while finding product-market fit, and now run an access model built for five people across an environment that serves hundreds. When the questionnaire arrives, that gap between the form and the infrastructure is what they have a week to close.

Marius-Florin Cristian, CISSP and cyber lead at Revolgy, who has taken B2B SaaS companies from pre-seed to exit, frames the triage around how the data actually flows:

“When you have to deal with vulnerabilities and potential exploits, you need to consider them as part of the path the data flows through. You cannot treat vulnerabilities individually, or you get overwhelmed with tens of thousands of alerts that most of the time are not relevant. What makes a series of vulnerabilities actually exploitable is that they compound into an attack chain, bypassing several layers of in-depth defence until they become an active exploit that exfiltrates data, modifies it without authorization, or denies access to the service.”

This guide covers how to separate dangerous security debt from cosmetic noise, the order to fix it while the business keeps shipping, and how to set a stopping point so the work matches the risk.

Google Cloud security debt accumulates the same way in every fast-growing company

The pattern is predictable, and it reflects rational decisions rather than carelessness. A team finding product-market fit

• runs everything in one Google Cloud project,
• grants every engineer the Owner role so they can deploy and test without waiting on anyone,
• puts all of it on a single VPC behind default firewall rules, and skips group-based access because there are five people who already trust each other.

Shipping is the only thing keeping the company alive at that stage, so anything that slows shipping loses.

The early setup is a reasonable starting point. It turns into debt when it survives unchanged while the company grows around it. By Series B the same project hosts forty people and a dozen services on an access model that was designed for five, and the symptoms are consistent across almost every environment:

• All-owners IAM. Access that was convenient at five people becomes impossible to reason about at forty, when nobody can say with confidence who can reach what.
  
• The default Compute Engine service account carrying Editor. Every VM and GKE node that runs as it inherits broad permissions across the whole project.
  
• A single flat VPC. Staging, production, and developer machines share one network because segmenting them created friction no one had time for.
  
• Terraform that is missing or monolithic. Infrastructure changed by hand in the console, with no single definition to audit the current state against.

The moment security debt turns into a revenue problem

For most mid-market companies, the event that forces the issue is commercial. A prospective enterprise customer reaches the security review stage of procurement and asks for compliance documentation as part of vendor due diligence, usually with a deadline of a week or two. When the artifacts do not exist, the deal stops moving.

That deadline changes what security spending is for. Most teams think about security as risk reduction, lowering the odds of a breach or a fine. The more useful frame for a growth-stage company is access. Certification is what qualifies you to bid for contracts that would otherwise be closed to you. Marius makes the commercial case directly:

“People are more receptive when you say you should invest five, ten percent of your yearly budget into security, and it’s not a time sink because it gives you access to these contracts, and they value much more in business income.”

The return compounds, which is what makes the frame more than a one-deal calculation. The spend is front-loaded, but it does not open a single contract. It qualifies you for every deal in your pipeline and for the whole market segment that shares that risk profile. The investment holds roughly flat in absolute terms as you grow, so as the budget rises, it falls as a percentage, and the lean posture stays lean.

It helps to separate two kinds of security spend. Operational investment is the cost of running the system day to day: reacting to alerts, tracking incidents, keeping controls live. Strategic investment is aligning that operational spend to a specific goal, meeting the risk profile of the larger clients you are trying to reach. The percentages are always relative to your financials and your ambition, but the split is what keeps spending tied to a commercial outcome rather than to fear.

You do not always need the certificate to win the deal. For the first few contracts you can pass on evidence alone, producing proof during security due diligence that you operate the controls the certification would attest to. The certificate changes the economics later. In a crowded market of near-identical products, it is a trust differentiator that tips a close decision your way. And once you have more than a deal a month in the pipeline, handing over a certificate is far faster than completing a 150-row questionnaire each time. The framework you need still depends on the deal you are chasing:

• SOC 2. The baseline a US enterprise buyer asks for first, broad and attestation-based, covering how you manage customer data.
  
• ISO 27001. The certification enterprise customers expect across Europe and much of the rest of the world, including Japan and Australia, confirming you run an information security management system audited against a defined standard.
  
• PCI DSS. Required once you store, process, or transmit cardholder data. The current version is 4.0.1, and the future-dated v4.0 requirements are now mandatory.
  
• DORA. The EU’s Digital Operational Resilience Act, Regulation (EU) 2022/2554, in force since 17 January 2025. Selling software to an EU bank, insurer, or payment firm pulls you into its Article 30 contractual obligations even if your own company is not a financial entity.
  
• NIS2. Directive (EU) 2022/2555, with a transposition deadline of 17 October 2024. Its supply-chain provisions are why SaaS vendors now receive NIS2 questionnaires from customers in essential and important sectors. The pressure behind those questionnaires is real: NIS2 sets tight breach-notification windows, an early warning within 24 hours and a fuller notification within 72, and it can hold senior management personally liable for non-compliance. If a breach through your service hits a critical-infrastructure customer, their director carries that risk personally, so their first screening question about any vendor is why they should take it on. Passing that gate is the deal.
  
• MiCA. The EU’s Markets in Crypto-Assets regulation. A crypto-asset service provider authorized under MiCA also falls under DORA, so one crypto deal can bring both into scope at once.

Cost is a quieter second trigger. Many startups run for a year or two on Google Cloud credits from their investor network, and when the credits expire, the real bill arrives. Marius has seen the same pattern several times: “We have two months, and then we actually have to start paying.” A cost review and a security review tend to land in the same quarter, which is a difficult moment to also be untangling a large, un-audited estate.

The short version: the debt has a due date you do not control. Your sales pipeline sets it for you.

Filter 1: Separate real attack chains from alert noise

When a security review lands, the natural response is to start working down the list of flagged findings. That response burns the most valuable week you have. A large Google Cloud environment produces thousands of findings, most of them isolated misconfigurations with no realistic path to anything that matters. Clearing them first consumes engineering time and leaves the genuinely dangerous gaps in place.

The starting point that works is the attack chain: a sequence of weaknesses that together form a realistic route from an entry point to a high-value resource. Marius is direct about where attention belongs:

“If you have two or three that are actually attackable, an attack chain, then you should really prioritize it. Inform the executives about the urgent things to fix now, and why they should care, then bundle the big non-urgent rest for later. There’s no point in making a report of two thousand pages. The shorter and more on point the report is, the more chance it has of landing, because one or two pages gets read and acted on where sixty pages gets filed away.”

Google Cloud has native tooling built for this triage. Security Command Center’s Risk Engine runs attack path simulations across a graph of your resources, IAM bindings, and network connections. Then assigns each finding an attack exposure score based on whether a simulated attacker starting from the public internet can actually reach a resource you have marked as high-value. Two of its finding types map directly onto Marius’s point:

• Toxic combinations. Groups of individually low or medium findings that together open a path to a high-value resource.
• Chokepoints. Resources where several attack paths converge, so remediating one node closes many exposures at once.

The same discipline governs ongoing alerting, not only one-time audits. Revolgy’s standard guidance is to stop alerting on basic infrastructure signals such as CPU, which generate noise that teams quickly learn to ignore, and to alert instead on application health: latency, error rates, and whether the service is actually serving.

Filter 2: Fix identity, because it’s at the center of most attack paths

The identity layer repays attention before anything else, because it is where attack chains converge and where an auditor looks first. It is also where the textbook answer, managing every permission in code and granting least privilege everywhere, runs hardest into a team that still has to ship. The work is divided into three parts, in order.

Replace the default service account first

The highest-value single fix is taking the shared, over-privileged default service account out of anything that runs your code and giving each workload a dedicated service account scoped to what it actually needs.

• For workloads on GKE, Workload Identity Federation for GKE lets each Kubernetes workload assume its own Google Cloud identity with no key files involved, which is also what the CIS GKE Benchmark recommends over running pods as the Compute Engine default account.
• For workloads authenticating from outside Google Cloud, such as CI/CD on GitHub or a service running on AWS, Workload Identity Federation exchanges the external identity for short-lived credentials and removes exported JSON service account keys, the long-lived secrets that show up as audit findings and leak through container images and source control.

This is the clearest case of debt that grows more painful the longer it sits. As Revolgy cloud architect David Kotalík points out, retrofitting it can mean replacing service accounts across every application you run. A firewall rule can be changed almost any time by adding the new rule before removing the old one, but a service account migration reaches into every running workload, so postponing it only raises the eventual cost.

Make Terraform authoritative, with one documented bypass

The textbook answer to IAM sprawl is fully Terraform-managed, authoritative IAM, with one source of truth and no manual changes. Incidents are what break that ideal in practice, because routing an emergency permission change through a Terraform pull request while production is down at 2 AM is not realistic. Marius’s social contract keeps the source of truth intact without pretending incidents do not happen:

“It’s authoritative by default, but the on-call engineer has the privilege to bypass it. If it is bypassed, then there should not be drift.”

That arrangement has three parts. Terraform owns the IAM policy, so the code is the default source of truth. The designated on-call engineer holds an explicit, documented privilege to override it during an incident. Once the incident closes, the bypass is reconciled in one of two ways: either the emergency change is codified into Terraform because it should persist, or it is reverted so the live state matches what the code already describes. Either way the drift is closed, deliberately, and recorded.

That reconciliation is where the compliance value is created, not just the access control. Each incident leaves a paper trail: the ticket that opened it, the documented bypass, the resolution, and the post-mortem. Those artifacts are what an auditor or an enterprise customer’s due diligence actually wants to see, because they prove you operate a process for handling the unexpected rather than simply claiming one. Marius treats the underlying accountability as non-negotiable:

“You cannot talk about security without having somebody accountable for the actions that they do.”

An authoritative state with a logged, deliberate exception, and a trail behind it, stays auditable in a way that ad hoc console changes never are.

Tie access changes to identity events

Managing group membership by hand becomes a liability as the team grows. The sustainable model treats lifecycle events in your directory, Google Workspace onboarding, role changes, and offboarding, as the triggers for permission changes. A developer who moves into a platform role picks up the new access automatically, and a marketing hire never receives production access in the first place.

Filter 3: Contain the structural debt that compounds

Some security debt sits quietly as risk, and some of it grows and makes itself harder to remove the longer you leave it. Monolithic Terraform state is the clearest example of the second kind. A single root module managing hundreds of resources creates three problems that compound together:

• Runtime that scales with the estate. Plan and apply cycles lengthen with resource count and reach 30 to 60 minutes in large environments, time that costs money in compute and in idle engineers.
• A whole team blocked every change. Each engineer waits for every plan regardless of which module they touched, and with 10 or 20 developers pushing several times a day, the lost time adds up fast.
• A blast radius the size of the whole estate. A single bad change in one shared state can reach the entire infrastructure, which is a security problem as much as an operational one.

The fix is to modularize by domain, giving each area that changes independently its own state. Marius splits his estates into distinct modules:

• Roles and permissions, isolated so IAM changes can be reviewed on their own.
• Database and replicas, where the data lives and the strictest controls apply.
• Monitoring and alerting, separated so observability work never touches production logic.
• Network rules, owned by whoever manages connectivity.
• A thin root whose only job is to read environment variables such as subscription IDs and pass them through.

With that split, a two-line change touches only the module it belongs to, runtime drops, the blast radius is contained, and the change is straightforward to reason about.

Filter 4: Set a stopping point with OWASP ASVS tiers

The three filters tell you what to fix first. ASVS tiering tells you when to stop, which matters because building security past your actual risk profile wastes the same budget you are trying to protect. The OWASP Application Security Verification Standard, whose version 5.0 arrived in May 2025, defines three assurance levels, and the v5 release deliberately rebalanced them so that Level 1 is a realistic entry point:

• Level 1. The baseline for general consumer-facing applications.
• Level 2. The level for applications handling sensitive data, including financial services, healthcare, and SaaS that processes personal data. This is what most procurement security questionnaires implicitly expect.
• Level 3. Reserved for applications where a breach is catastrophic, such as defense, critical infrastructure, and high-value financial systems.

The goal is to match the tier to your application’s real risk profile and use that as the input to how much infrastructure security you build around it. A marketing-analytics SaaS and a payment platform sit at different levels, and knowing which one you are gives you a defensible place to stop.

Marius pairs the tier with the CIA triad as the underlying test, treating confidentiality, integrity, and availability as a tripod: data that is perfectly confidential and correct but reachable only one hour a day is useless, and data that is always available but exposed is a liability. Remove any leg and the system fails, which is why the application that processes the data gets secured before the networking and infrastructure wrapped around it.

The sequence in practice for Google Cloud security

Applied in order, the filters give you a working sequence:

1. Find the attack chains. Use Security Command Center’s attack exposure scores, toxic combinations, and chokepoints to pull the two or three real exploitation paths out of the thousands of cosmetic findings, and leave the noise where it is.
   
2. Fix the identity layer. Replace the default service account with dedicated, least-privilege identities and Workload Identity Federation, make Terraform authoritative with one documented on-call override, and tie access changes to identity events.
   
3. Contain the structural debt. Modularize Terraform state by domain before the blast radius and runtime grow further.
   
4. Set the stopping point. Use your ASVS target level to decide when the infrastructure security matches the application risk, so the work ends where the business stops needing it.

The value of all this is in the order. Fixing the wrong thing first is how a team spends a deal deadline and still comes out exposed.

Talk to a Revolgy Google Cloud security expert

If you have read this far and still cannot tell which gaps in your environment sit on a real attack path and which are noise, that uncertainty is the starting point for an Architecture Clinic with Revolgy.

Revolgy has worked through this with companies on both sides:

• the ones where a focused remediation unblocked a stalled enterprise deal,
• and the ones where the honest call was that the debt was smaller and less urgent than it looked.

That is the judgment worth borrowing before you commit engineering time to a findings list.

Revolgy runs free 45-minute 1:1 working sessions with senior Google Cloud architects. Bring your current IAM setup, your Security Command Center findings, or the compliance deadline you are working toward. Within 24 hours of the session, you receive a structured summary of the gaps that actually matter and the order to address them.

Free consultation with a senior Google architect

Book a free 45-minute Architecture Clinic with a Revolgy Google Cloud expert now. Only 6 slots run per week.

Claim yours now

Frequently asked questions about Google Cloud security

How do I prioritize Google Cloud security fixes when I have hundreds of findings?

Prioritize attack chains ahead of individual findings. A connected sequence of weaknesses that forms a realistic path to a high-value resource carries far more risk than an isolated misconfiguration with no way to reach anything. Google Cloud’s Security Command Center Risk Engine scores findings by attack exposure and flags toxic combinations and chokepoints, which turns the triage into something concrete.

Should Terraform manage all Google Cloud IAM permissions?

Terraform should be the authoritative source for IAM by default, with one documented exception for the on-call engineer during incidents. Any drift introduced while responding to an incident is reconciled back into Terraform afterward, alongside a root cause analysis, so the code stays the source of truth. This keeps incident response fast without giving up auditability.

When should a startup start investing in Google Cloud security controls?

The practical trigger is your first enterprise or regulated-industry prospect asking for compliance documentation during due diligence. Putting the foundations in earlier, specifically group-based IAM, dedicated service accounts, authoritative Terraform state, and network segmentation, avoids the emergency rework of fixing everything at once under a deal deadline.