During technical due diligence, VCs are mainly checking three things: how your cloud environment is configured, who has access to what, and whether you've had (and handled) any security incidents.
Founders who look at these before the data room opens tend to face fewer surprises and a shorter back-and-forth once diligence starts. Founders who skip it often get a term sheet with a security condition attached, or a delay while questions get answered mid-process. A breach or a sloppy AWS account six months after a Series A becomes the fund's problem too. Diligence is how they try to price that risk before it's theirs.
Cloud configuration: are the basics actually in place?
Most growing companies run on AWS, GCP, or Azure, and most technical due diligence starts there. Investors, or the firm they hire, aren't hunting for a perfect environment. They want evidence that someone owns it.
Are storage buckets and databases public by accident? Is there a single AWS root account with no multi-factor authentication (MFA), used day-to-day? Are logging and monitoring switched on, or is there no record of what happened last week, let alone last year? Is production separated from staging and development?
In one engagement with a venture-backed technology company, a cloud security review across AWS and Google Cloud Platform (GCP) surfaced more than 900 findings on the AWS side and led to over 580 remediated on GCP. Those two numbers aren't directly comparable — one is findings identified, the other is findings actually closed out — and the raw counts matter less than what they contained: a mix ranging from minor misconfigurations to a smaller number of more serious exposures that needed fixing quickly. Nobody had reviewed that particular environment end to end with a security lens before.
That result is specific to that one company; it isn't a benchmark for what any other startup's environment looks like, and a much smaller or larger number elsewhere wouldn't mean much on its own. What matters to an investor is whether you're finding and fixing issues like this proactively, or whether they're the ones who find them first.
Access controls: who can touch what, and why
The second thing diligence teams probe is identity and access. This is less about tooling and more about discipline.
Do former employees and contractors still have active credentials? Is there a shared admin login that three people know the password to? Can engineers reach production databases directly, with no approval trail? Is there any separation between who writes code, who deploys it, and who can change security settings?
Investors read weak access control as a signal about company maturity generally, not just security. If nobody has ever asked who can do what and why, other operational basics probably haven't been asked either.
Most of this is something a founder or lead engineer can fix directly, without hiring anyone: revoke access for anyone who's left, replace shared logins with individual accounts, turn on MFA everywhere it's missing, and add a basic approval step before anyone touches production.
What usually does need outside help is the deeper work — mapping every service account and permission across a growing cloud footprint, and setting up the ongoing process so access doesn't quietly drift back to the same state a year later. That's the part that tends to get skipped when there's no dedicated security person watching it.
Incident history: what happened, and how you handled it
Every serious investor will ask, directly or via a questionnaire, whether you've had a security incident. The honest answer matters far less than how you answer it.
A founder who says "yes, we had an intrusion attempt, here's what we found, here's what we contained, here's what changed afterward" sounds in control. A founder who says "no, never," with no monitoring in place to actually know that, sounds unaware rather than lucky.
In the same engagement referenced above, an active intrusion was identified and contained during the course of the work, alongside achieving full endpoint detection and response (EDR) coverage across the company's devices. That's the kind of specific, documented outcome that's easy to describe in a diligence call — a lot more useful than a general assurance that "security is a priority."
If you've genuinely never had an incident because you've never had visibility to detect one, that's worth addressing before diligence starts, ideally through ongoing monitoring rather than a one-time check, so the answer to "have you had an incident" is one you can actually back up.
What actually counts as a dealbreaker
Founders often assume that finding problems during a pre-raise review is itself the risk. In practice, it's usually the opposite: a review that turns up real issues, paired with evidence you fixed or are actively fixing them, tends to read as a company that takes this seriously.
Most investors expect a growing company's environment to have gaps. What they're gauging is whether those gaps are known and being worked on, or invisible.
What tends to actually concern an investor is different: findings that were known about and left unaddressed for a long time with no plan, inconsistent or evasive answers about an incident, or no one on the team who can credibly explain what happened and what changed.
Serious issues discovered by your own review before diligence, with a remediation plan and a timeline attached, are a far better position than the same issues being found by someone else's diligence team mid-process.
How to walk in prepared, not scrambling
The founders who handle this well don't do anything exotic. They just start earlier, before there's a deadline forcing the pace.
- Run an independent review well before you expect to be in active fundraising conversations. A cloud and access review, plus a penetration test of your core application, gives you a documented baseline and enough runway to actually fix what it finds rather than patch it under pressure.
- Fix, then verify. A list of findings with nothing closed out looks worse than a shorter list where everything was actually remediated. Verification after the fix matters more than the initial scan.
- Write down your incident history honestly, with context. One contained incident with a clear response is a stronger story than a blank "N/A" nobody can back up.
- Have someone senior who can speak to the reasoning behind your security decisions, not just an engineer defending code. A virtual CISO (vCISO) can sit in the diligence call and explain the "why," which diligence teams generally find reassuring.
You can see the scope of one engagement like this — cloud review across AWS and GCP, penetration testing, vCISO leadership, and incident containment — in our case study with a venture-backed technology company. For general frameworks on thinking about this systematically, the NIST resources on cybersecurity risk management are a solid public reference point.
FAQ: security due diligence for founders
How early should we start preparing for a security review?
Earlier than most founders expect — before you're in active conversations with investors, not once a term sheet is on the table. Fixing and verifying findings takes real time, and that's harder to compress under deadline pressure.
Will finding problems in our own review hurt us with investors?
Generally no. Investors expect a growing company's environment to have gaps. A documented remediation plan for issues you found yourself is a stronger position than the same issues surfacing later in someone else's diligence.
Can we fix access control issues ourselves, or do we need to hire someone?
The basics — revoking old credentials, enabling MFA, removing shared logins — can usually be done in-house. Mapping permissions across a growing cloud environment and keeping access from drifting back over time is where outside help tends to pay off.
What if we've never had a security incident?
That's only reassuring if you have the monitoring in place to know it's true. Without visibility, "no incidents" is closer to "we don't know" than "we're secure."
Where founders should start
VCs aren't trying to catch you out. They're trying to answer one question: will security slow this company down after we invest?
A cloud environment that's been reviewed, access that's been tightened, and an honest, documented incident history go a long way toward answering that before anyone has to ask it out loud.
If you've got a raise on the horizon and haven't had eyes on this yet, start with a free security review. It's a low-friction way to see where you stand before the data room opens.
For more on related topics like cloud security and vCISO support, browse our insights section.
Originally published at sheersafe.com
