What VCs Actually Look for in Security Due Diligence (And How to Pass)

We get a version of this call every few weeks. A founder, usually mid-raise, sometimes days before a partner meeting, asking whether we can turn around a pentest report fast. The story is always the same: the VC's due diligence team sent over a security questionnaire, or the term sheet has a clause requiring a third-party security assessment, and they weren't prepared for it.

Five years ago, security was an afterthought in venture due diligence. The checklist was financials, market size, team, product-market fit. Security came up only if the company had already been breached or was selling directly to regulated industries. That has changed dramatically.

Today, security due diligence is standard practice at most institutional VC firms from Series A onward, and increasingly at seed. We've worked with startups going through diligence with firms ranging from early-stage specialists to multi-stage growth funds. This article covers what we've seen them actually check, what kills deals, and how to be ready.

How VC due diligence evolved to include security

The shift didn't happen overnight. It was driven by three converging forces.

First, breaches at portfolio companies became expensive. When a Series B startup suffers a breach that burns through six months of runway on incident response, legal fees, and customer churn, the fund feels it. After enough of these, firms started treating security risk the same way they treat financial risk: something you diligence before you write the check, not after.

Second, enterprise buyers raised the bar. The SOC 2 requirement that used to be limited to Fortune 500 procurement has trickled down to mid-market and even SMB buyers. According to Vanta's 2025 State of Trust Report, 89% of companies reported that compliance certifications directly accelerated their sales cycles.^[1] VCs know that a startup without a security program will hit a revenue ceiling when it can't close enterprise deals.

Third, regulatory exposure increased. GDPR, CCPA, state privacy laws, SEC cybersecurity disclosure rules, the EU AI Act. The regulatory surface area for technology companies has expanded dramatically. A startup that's non-compliant isn't just a security risk; it's a legal liability that could trigger fines, lawsuits, or force a pivot in how the product operates.

The result: most institutional VCs now have a security component in their due diligence process. Some outsource it to specialized firms. Others have in-house platform teams that run the assessment. A few of the larger funds have dedicated CISOs on staff specifically for portfolio diligence and support.

What VCs actually check

The specifics vary by firm and stage, but in our experience working with startups through these processes, the diligence consistently covers six areas.

SOC 2 status and compliance posture

This is the first question. Not "do you have SOC 2?" but "where are you on the path?" Investors at Series A and beyond expect you to either have SOC 2 Type I completed or have a clear timeline with tooling in place. At seed, they want to see that you know what SOC 2 is and have a plan.

What they're really assessing is whether your company can sell to enterprise customers. If you're building B2B SaaS and you can't answer a security questionnaire, you're leaving revenue on the table, and that affects their return. For a deeper comparison of compliance frameworks, see our guide on SOC 2 vs ISO 27001 for startups.

Penetration test reports

A recent third-party penetration test is the single most credible security artifact you can produce. It's independent validation that someone qualified has tested your application and infrastructure for vulnerabilities.

VCs look for three things in a pentest report: the scope (was it comprehensive or just a surface scan?), the findings (how many critical and high-severity issues were found?), and the remediation status (did you fix them?). A pentest that found issues and shows they were all remediated is actually better than one that found nothing, because it demonstrates a mature security process.

Incident history and response capability

"Have you ever had a security incident?" is a standard question. The answer doesn't have to be "no" to pass diligence. What matters is how you handled it. A startup that detected a breach quickly, contained it, notified affected parties, and conducted a post-mortem demonstrates operational maturity. A startup that can't answer the question at all, or that clearly hasn't thought about incident response, is a red flag.

At minimum, investors expect a documented incident response plan. It doesn't need to be a 50-page playbook. A two-page document covering detection, containment, communication, and post-incident review is sufficient for early-stage companies.

Data handling and privacy practices

Where does customer data live? Who can access it? How is it encrypted? What's your retention policy? Do you have a data processing agreement template? These questions come up in every diligence process we've seen.

The underlying concern is liability. If your startup is collecting PII, health data, financial data, or children's data, there are specific legal obligations attached. VCs want to know that you understand those obligations and have controls in place. A startup handling health data without HIPAA considerations, or processing EU citizen data without GDPR compliance, is a ticking regulatory bomb.

Encryption and infrastructure security

This is the technical layer. VCs or their security assessors will check whether you have encryption at rest and in transit, whether your cloud environment follows basic security hygiene (no public S3 buckets, no open database ports, proper IAM roles), and whether you have logging and monitoring in place.

They also look at your deployment pipeline. Is there code review? Automated security scanning in CI/CD? Separation between development, staging, and production environments? These aren't nice-to-haves. They're baseline expectations at Series A.

Access controls and identity management

Who has access to what? Is MFA enforced on critical systems? Do you have an offboarding process? Is there a password policy?

This area trips up startups more than you'd expect. We regularly find companies where every engineer has admin access to the production database, where former contractors still have active GitHub access, and where shared credentials are used for critical services. These findings in a diligence report signal operational immaturity to investors.

Red flags that kill deals

Not every security gap is a deal-killer. VCs expect early-stage companies to have some rough edges. What they don't expect is recklessness or willful ignorance. Here are the findings that, in our experience, have actually killed or significantly delayed deals.

Undisclosed breach history

If a VC discovers during diligence that you had a breach you didn't disclose, the deal is dead. Not because of the breach itself, but because of the dishonesty. Investors are betting on the team as much as the product. If the team hides material security incidents, what else are they hiding? If you've had an incident, disclose it proactively and explain how you handled it.

No security program whatsoever

There's a difference between "we're early and have gaps" and "we've never thought about security." If a Series A-stage company has no security policies, no access controls, no encryption documentation, no incident response plan, and no pentest, that signals a fundamental problem with how the founding team evaluates risk. Investors read this as a founder who will also cut corners on legal, financial controls, and governance.

Regulatory non-compliance with customer data

If you're handling data that falls under HIPAA, PCI DSS, GDPR, or state privacy laws and you have no compliance controls in place, that's not a gap you can fix in a sprint. It's a structural risk to the business. We've seen term sheets pulled when diligence revealed that a health-tech startup had zero HIPAA controls despite storing patient data. The liability exposure was too high for the fund.

Single points of failure in critical infrastructure

One person with the root password who is also the only person who knows how the deployment works. One cloud account with no backup, no disaster recovery, no documentation. These aren't just security risks; they're business continuity risks. If that person leaves, gets hit by a bus, or goes rogue, the company could lose access to its own infrastructure. VCs see this as existential risk.

Secrets in source code and version control

API keys, database credentials, and service tokens committed to Git are a consistent finding in our startup assessments, and a consistent red flag in diligence. It signals a lack of basic security hygiene that raises questions about what else might be wrong. If your Stripe secret key is in your frontend code, what else has been overlooked?

No separation between environments

Deploying directly to production from a developer laptop, using the same database for development and production, running test data mixed with real customer data. These patterns are common at the earliest stages, but by the time you're raising a Series A, VCs expect to see at least basic environment separation. It's a proxy for engineering discipline.

The security questionnaire: what to expect and how to prepare

Most VC security diligence comes in the form of a questionnaire, either proprietary to the fund or based on industry frameworks like SIG Lite, CAIQ, or a simplified version of SOC 2 trust service criteria. If you've ever filled out a customer security questionnaire, the format will be familiar.

Typical sections include:

• Governance: Security policies, risk management, security roles and responsibilities
• Access control: Authentication mechanisms, authorization models, MFA, access reviews
• Data protection: Encryption, data classification, retention, disposal, privacy
• Infrastructure: Cloud security, network segmentation, logging, monitoring
• Application security: SDLC practices, code review, vulnerability scanning, penetration testing
• Incident response: IR plan, detection capabilities, past incidents, notification procedures
• Business continuity: Backups, disaster recovery, RTO/RPO targets
• Third-party risk: Vendor management, subprocessor agreements, supply chain security

The biggest mistake founders make with these questionnaires is trying to bluff. Don't claim you have an incident response plan if you don't. Don't say you've completed a pentest if you haven't. The diligence team may ask for evidence, and getting caught overstating your security posture is worse than admitting gaps. Honesty paired with a remediation timeline is always the better strategy.

Stage-specific security expectations

What VCs expect from your security posture scales with your stage. A pre-seed company gets a different bar than a Series B company. Here's what we've seen across stages, based on our work with dozens of VC-backed startups.

Pre-seed

Security rarely comes up in pre-seed diligence. Most pre-seed investors are betting on the founders and the idea, not the infrastructure. That said, if you're building in health-tech, fintech, or edtech, even angel investors may ask basic questions about data handling.

Minimum expectations: Encryption in transit (HTTPS), no secrets in source code, MFA on cloud accounts, basic understanding of your data handling obligations. For more on what to prioritize at this stage, read our guide on security after pre-seed funding.

Seed

At seed, security starts appearing in diligence, especially from institutional seed funds. They won't expect SOC 2, but they want to see that you've thought about security and have basic controls in place.

Minimum expectations: Everything from pre-seed, plus a documented security policy, access control with role separation, an offboarding process, a privacy policy that matches your actual practices, and a plan for SOC 2 or equivalent compliance.

Series A

This is the stage where security diligence becomes standard. Most Series A investors will include a security component, and some will make specific security requirements conditions of the term sheet. This is where our startup security checklist becomes essential.

Minimum expectations: Everything from seed, plus a completed penetration test with remediated findings, SOC 2 Type I completed or in progress, a documented incident response plan, logging and monitoring on production systems, environment separation, and a vendor risk management process.

Series B and beyond

By Series B, you're expected to have a mature security program. The diligence is less about whether you have security controls and more about whether they're effective and continuously maintained.

Minimum expectations: SOC 2 Type II, annual penetration testing, vulnerability management program with SLAs, security training for employees, formal risk assessment process, disaster recovery testing, third-party risk management program, and a dedicated security function (even if it's one person or a fractional CISO).

Using security as a competitive advantage in fundraising

Most founders think of security as a cost center, something you invest in to avoid bad outcomes. That's true, but it misses the bigger picture. Security is a revenue enabler and a competitive differentiator, and you can position it that way with investors.

Here's how.

Security unlocks enterprise revenue

Every enterprise deal you can't close because you can't pass a security questionnaire is revenue your competitors are capturing. When you show investors a SOC 2 report, a clean pentest, and a track record of closing enterprise deals that require security review, you're demonstrating a competitive moat. Most startups at your stage can't do that. You can.

Security reduces downside risk

VCs are portfolio thinkers. They're evaluating the probability-weighted range of outcomes. A strong security posture reduces the probability of the worst outcomes: breaches, regulatory fines, customer churn from trust violations, and emergency spend on incident response. When you frame your security investment as risk reduction, it maps directly to how investors think about portfolio management.

Security signals operational maturity

A startup that has its security house in order sends a signal about the founding team's judgment, discipline, and ability to execute on unglamorous but essential work. Investors notice this. It's the same signal as clean financials, well-structured cap table, and solid legal documentation. It tells them the founders know how to build a real company, not just a product.

Building a security narrative for investors

You don't need to lead your pitch with security. But you should have a clear, concise security narrative ready for when it comes up in diligence. Here's a framework we recommend to our startup clients.

The three-part security narrative

1. Where you are today. Honest assessment of your current security posture. What controls are in place, what compliance certifications you have, what your most recent pentest found and how you addressed it. No exaggeration, no minimization.
2. Where you're going. Your security roadmap for the next 12 months. SOC 2 timeline, planned security hires or engagements, additional compliance certifications, product security features on the roadmap. Show that security is part of your operating plan, not an afterthought.
3. How security supports your GTM. Connect your security investment to revenue. Which enterprise deals require SOC 2? What markets require specific compliance certifications? How does your security posture compare to competitors in deals you're winning (or losing)?

When security findings changed the outcome

We can't name specific companies, but we can share patterns we've seen across our engagements. These are composite examples drawn from real situations.

The deal that almost died over a database

A Series A SaaS company was in final diligence with a top-tier fund. The fund's security team ran a basic assessment and found that the production database was accessible from the public internet on the default port with weak credentials. The term sheet was paused. The company engaged us for an emergency assessment, remediated the database exposure and twelve other findings in two weeks, and produced a clean report. The deal closed, but it delayed the round by a month and consumed the founding team's attention at a critical time. Had they run the assessment themselves before diligence, the issue would have been fixed quietly.

The startup that used security to win the deal

A seed-stage fintech company was raising its Series A in a competitive process with two other companies targeting the same market. All three had comparable metrics. The differentiator: this company already had SOC 2 Type I, a clean pentest report, and had closed three enterprise banking clients that the competitors couldn't touch because they couldn't pass the banks' security requirements. The VC chose them specifically because their security posture translated to a go-to-market advantage.

The red flag that ended a conversation

A health-tech startup was in exploratory conversations with a growth-stage fund. During an initial call, the founder mentioned they stored patient data in a multi-tenant database with no encryption at rest and no HIPAA BAA with their cloud provider. The fund passed immediately. Not because the technical issues were unfixable, but because a founding team building in health-tech that hadn't considered HIPAA represented a fundamental risk judgment problem.

The pre-diligence checklist: what to have ready

Based on everything above, here's the practical checklist. If you're planning to raise in the next 6-12 months, start working through this now. Every item you can check off reduces friction in diligence and strengthens your position.

The timeline: when to start

The honest answer is "earlier than you think." Here's a realistic timeline based on what we see with our startup clients.

• 6 months before your raise: Engage a penetration testing firm. Get the assessment done and remediate findings. This gives you time to fix issues without the pressure of an active diligence process.
• 4-5 months before: Start your SOC 2 process if you haven't already. Type I can be achieved in 3-4 months with the right tooling and focus.
• 3 months before: Draft your security policies, complete your master security questionnaire, and create your architecture documentation.
• 1 month before: Do a dry run. Have someone on your team (or an outside advisor) review your security artifacts as if they were a VC diligence team. Identify and fix any remaining gaps.

If you're already in the process and unprepared, don't panic. A targeted penetration test can be completed in 1-2 weeks. Basic security policies can be drafted in days. The gap between "nothing" and "credible security posture" is smaller than most founders assume, but it does take focused effort.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.