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 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:
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.
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.
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.
Above the floor, two inputs decide how much security is enough. Everything else is detail.
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:
“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.
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.
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.
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:
Within 24 hours, you receive a structured summary of the gaps and the next steps. Six slots run each week across two architects.
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.
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.
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.
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.
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.