Google Cloud, Security
Quickly jump to section in this article:
Most cloud security advice treats security as a level: more is safer, less is riskier, and the job is to climb. That framing is why growing companies get it wrong in both directions. Asked as a question of level, “how much security is enough” has no answer, because there is always one more control to buy. Asked as a question of where to draw the line, it becomes answerable.
Both directions in security have a failure mode. Too little, and an opportunistic attacker walks through a door you left open. Too much, and security starts taxing the speed and focus keeping the company alive.
A new Google Cloud project does not start neutral. The auto-created default network ships with firewall rules that allow ingress from any address on the internet: default-allow-ssh opens TCP port 22 to 0.0.0.0/0, and default-allow-rdp opens TCP port 3389 the same way. Google secures the infrastructure underneath, and what you run on top is yours to configure. The defaults are built to get you moving fast, which is the opposite of what a production environment needs.
As Josef Bárta puts it:
Even Google’s own security tooling starts flagging a freshly set up project as insecure, because you get the default SSH rule open to the whole world. These are things you almost want to trash straight away.
The opposite mistake costs just as much. A team that reacts to its first security scare by buying every tool and enforcing every control produces friction, and engineers route around friction. A password policy that forces a rotation every two weeks produces sticky notes. An approval gate that adds three days to every deploy produces a shadow process that skips the gate. Over-securing fails quietly, by being bypassed.
Based on a conversation between Michael Fitzgerald, Solutions Manager at Revolgy, and Josef Bárta, Chief Architect at Revolgy, this guide covers where the line sits between undersecured and oversecured, how it shifts as you grow, and what it takes to enforce it on Google Cloud.
Two inputs that decide the line between undersecured and oversecured
Two inputs decide where the line sits between these two: the attacker you can realistically expect, and the customers who will not sign until you meet their bar. Everything above that line is what insurance exists for. The line is different for a ten-person startup and a fifty-person company selling into banks, and most teams never draw it on purpose.
What stays constant is one distinction worth getting straight first:
- The floor is the non-negotiable baseline every company clears regardless of size. Below it, you are exposed no matter how early you are.
- The sizing is everything above the floor, the variable amount you tune to your risk and your buyers.
Get the floor wrong, and no amount of sizing saves you. Get the sizing wrong, and you either bleed budget on threats you will never face or fail the security review that just lost you a deal.
The floor: what every company clears regardless of size
Before you size anything, there is a baseline that does not scale with your stage. It is cheap, it is mostly configuration, and on Google Cloud it is where the avoidable breaches actually come from. Josef’s observation from years of looking at real environments is that the breach is almost never a brilliant attacker. It is something boring that nobody cleaned up.
Three items make up the floor.
- Close the insecure defaults. A new Google Cloud project ships with a default VPC that allows SSH and RDP from any address on the internet, and a default service account that has historically carried the broad editor role, as Google’s firewall documentation confirms. Delete the default network, or block it with the compute.skipDefaultNetworkCreation organization policy, then build custom VPCs with your own firewall rules. Route administrative access through Identity-Aware Proxy from its range 35.235.240.0/20 instead of leaving port 22 open to the world.
- Get keys off the public surface. An unrestricted API key in client-side code or a public repo is an open invoice. In early 2026, Truffle Security found 2,863 live Google API keys exposed publicly, and leaked keys were used to run high-cost AI calls, with one reported case hitting $82,314 in two days on an account that normally spent $180 a month. Restrict every key to one service, split Maps and AI workloads into separate projects, and rotate exposed keys into Secret Manager.
- Remove access nobody uses. Elevated access granted “just to get something built” and never revoked is the most common finding in any real environment. As Michael Fitzgerald put it in the same conversation, “that lock it down afterwards doesn’t always happen.” Strip standing privileges down to what each identity actually needs.
- Keep the blast radius small. Start from the assumption every experienced security leader works from: you will be breached eventually, and the design question is what happens when you are. Put the highest privileges behind a break-glass procedure and give admins a separate identity for day-to-day work, so a single compromised account does not open the whole estate.
- Handle the European layer where it applies. For teams with EU data-residency obligations, the US CLOUD Act is a real consideration, and Google offers customer-managed and external encryption keys to weigh against it. Google’s open-source posture, including its origination of Kubernetes, also makes an exit plan more credible than a more closed platform would.
Each of these is visible without guesswork. Security Command Center surfaces the open defaults, secret scanning finds the exposed keys, and the IAM recommender flags access nobody has touched in months. The floor is easy to find and easy to skip, which is the whole problem.
None of this is a sizing decision. It is the price of running on the cloud at all, and it is the same for a five-person startup and a five-hundred-person scale-up.
The sizing: two dials that set your security size
Above the floor, two inputs decide how much security is enough. Everything else is detail.
1. Dial one: your adversarial model
Name the attacker you are actually likely to face, and defend against that one. A SaaS company with tens of millions in ARR is not going to stop a well-resourced nation-state, and it should not try. “If a well-funded governmental organisation of a big country tries to hack you, they probably will,” Josef says, and that residual risk is what cyber insurance is for.
The line worth defending is the opportunistic attacker: the credential scraper, the automated scanner, the phishing email that lands at 5 a.m. Defend hard against the breach that would be embarrassing because it was cheap to prevent.
You can write a usable version in an afternoon:
- List your crown-jewel data and where it lives.
- Name the two or three attacker types most likely to come for it, such as an opportunistic scraper, a disgruntled insider, or a competitor.
- For each, write the single path you would take if you were them.
- Fix the cheapest step on each path first.
2. Dial two: your customers
“Your customers eventually end up dictating your security posture,” Josef says. A buyer in critical infrastructure or financial services demands controls a mid-market SaaS buyer never mentions, and those demands arrive as a 200-question security questionnaire or a clause in a contract.
If a deal requires SOC 2 or ISO 27001, that requirement sizes your security whether or not your threat model alone would have asked for it. When that deadline hits, it is rarely a question of whether your posture is strong enough in theory. It is a question of whether your live environment can answer the questions in the week you have. How to sequence Google Cloud security debt before it stalls a business deal covers exactly that triage.
Read together, the two dials give you a number. Your threat model sets what you need to sleep at night. Your customers set what you need to close deals. Enough security is whichever is higher, and not much above it.
Sizing by stage: what enough looks like as you grow
The right amount changes as you grow, because the failure modes change. Josef’s rule of thumb: an early team should focus on building and not let anything slow it down, and the moment you start professionalising, with CI/CD pipelines and real engineers, least privilege and key hygiene stop being optional.
The trigger to move up a row is rarely a calendar date. It is a moment of pain: a failed security review, a near-miss, an audit request, a bill you did not run up.
|
Stage |
Trigger moment |
What “enough” adds above the floor |
|
Early / building |
Pre-revenue or first users |
The floor, and little else. Move fast, use managed services, keep secrets out of code, avoid standing admin access. |
|
Professionalising |
First real customers, CI/CD, a growing team |
Scope service accounts to the minimum, rotate keys on a schedule, remove access as roles change, turn on posture scanning. |
|
Scaling / selling up-market |
Enterprise or regulated buyers, board attention |
Break-glass for top privileges, separate admin accounts, deny-by-policy on risky actions, security involved early in projects, compliance where customers require it. |
The mistake runs both ways. Applying the third row’s controls to a first-row company buys drag you cannot afford. Running a third-row company on first-row habits is how a scaling business gets breached through access it forgot to remove.
How to find your current cloud security size?
Every part of this guide needs one input you cannot get from a policy document or an audit report: the live state of your environment. Your stage tells you what you should have. Your dials tell you how much is enough. Only the environment tells you where you actually are.
That means enumerating the real thing: the firewall rules open right now, the service accounts holding more than they use, the keys sitting in a public bundle, the standing access nobody remembers granting. Compare that against your stage and your two dials, and the gap is your work. Josef’s one-line version for a CTO or CISO: get an assessment, then be intentional about what you fix and what you consciously leave.
Find your cloud security sizing line with a Revolgy expert
If you have read this far and still cannot say what your environment is actually exposed to right now, that uncertainty is the starting point. Revolgy’s architects have run this exercise across single-cloud and multi-cloud estates, including the cases where a breach in one cloud opens a path into another, and they will tell you where your line already sits before recommending a single control.
An Architecture Clinic is a free 45-minute working session, one-to-one with a senior Google Cloud architect at Revolgy. You bring an active problem and your environment context. In the session, you will:
- Review your default network and firewall exposure against the changes that matter first
- Walk your IAM and blast-radius setup to find privileges that should have been removed
- Get findings prioritized using the Security Command Center Premium 30-day trial, so you leave knowing what is worth fixing and in what order.
Within 24 hours, you receive a structured summary of the gaps and the next steps. Six slots run each week across two architects.
Frequently asked questions
How much should a startup spend on cloud security?
Early-stage startups should spend on the floor and little else: closing insecure defaults, keeping secrets out of code, and avoiding standing admin access, which are mostly configuration rather than budget. Heavier controls like break-glass access and compliance certification are worth adding when your customers or your threat model actually call for them, not before.
Can a company have too much security?
Yes. Security controls carry costs in engineer time, shipping friction, and lost focus, so past the point that covers your real risk and your customers’ requirements, more security buys drag rather than safety. A security function that constantly collides with the rest of the business is usually a sign the posture is mis-sized.
What is the minimum cloud security every company needs?
Every company on the cloud needs to close insecure platform defaults, keep API keys restricted and off public surfaces, and remove access that is no longer used, regardless of size or stage. This baseline is where most avoidable breaches come from and it is largely free to fix.
How do I decide which threats to defend against?
Define an adversarial model by naming the attacker you are realistically likely to face, then defend against that one rather than every theoretical threat. A mid-sized SaaS company should focus on opportunistic attackers like credential scrapers and phishing, and treat nation-state risk as something cyber insurance covers rather than something to out-engineer.
Does a growing company need SOC 2 to be secure?
No, a SOC 2 or ISO 27001 certificate proves you documented and examined a set of controls, which is a diligence signal and often a sales requirement, but it does not by itself make your live environment secure. Pursue certification when a customer or contract requires it, and treat your actual configuration as a separate thing to verify.
.webp)