Security checklist before a funding round

By Kike Gandia · Co-Founder & CEO, OSCP

Preparing for security due diligence isn't about improvising documents the week before closing: it's a short, concrete list of things to do 2 months ahead of time. This checklist summarizes, in priority order, what needs to be ready before you sit down with the investor's due diligence team.

What needs to be ready 6-8 weeks ahead

1. A recent product pentest (last 12 months), with critical findings already remediated and retest evidence. 2. A documented information security policy, even a 3-4 page one. 3. An access management record: who has access to what systems, and why. 4. A basic incident response plan: who does what in the first 24 hours of an incident.

What helps but isn't essential at early stages

A vendor inventory and what data is shared with each one; a data retention and deletion policy; evidence of anti-phishing training for the team; and a one-page executive summary translating all of the above into non-technical language for the investment committee.

Common mistakes that delay closing

Presenting a pentest more than 18 months old (investors consider it stale), having no access management documentation even if the technical system is well designed, or improvising answers about past incidents instead of having an objective record, even a brief one.

How to prioritize if time is tight

If you can only do one thing, make it the pentest: it takes longest to schedule and carries the most weight in the assessment. The rest of the documentation (policies, records) can be drafted internally in days if you already know what practices you follow, even if they aren't written down yet.

Who produces each piece, and what makes it useless

The checklist almost always stalls for the same reason: nobody owns each piece. This table closes that gap.

What an experienced analyst reads is the coherence between pieces: if the access record does not mention the tool the policy talks about, the conclusion is not that a document is missing, but that none of them describes how you actually work.

What gets handed over, and in what form

There is one question almost nobody asks until the moment arrives: do you hand over the full pentest report? It depends. Technical findings with reproduction steps are sensitive, and sharing them in a data room several parties can access is not always prudent. The usual alternative is an attestation letter from the provider — scope, dates, methodology, number of findings by severity and remediation status, without the exploitable detail — keeping the full report for review under NDA if the investor specifically asks. Agree with the provider that they will issue that letter before commissioning the work: not all of them include it by default, and asking afterwards stretches the timeline exactly when there is none to spare.

FAQ

Do I need to hire someone external for this checklist?

The pentest does require a specialized provider. Policy and process documentation can be drafted internally, though external support usually speeds up the process and avoids formatting mistakes that due diligence analysts already recognize.

Does this checklist also work for a Series B or C?

This is the minimum baseline. At later stages, investors usually add requirements like SOC 2 or ISO 27001, which are larger-scope projects beyond this initial checklist.

What if my startup is very early and has none of this?

That's common at pre-seed or seed stage. Start with the pentest and the security policy: they're the two pieces asked about first and give the best maturity signal for the least effort.

What if the investor is closing in two weeks, not 6-8?

The pentest is still the critical piece and the one with the least slack, but a project narrowed to the core product with a dedicated team can start within days. Our express pentesting and audits guide explains what can genuinely be sped up and what shouldn't be compressed.

What do they ask in the technical due diligence call?

Almost always the same four things, and none of them needs rehearsing if the team works with discipline: who has production access and how it is granted or revoked; what happens when someone leaves; how a code change reaches production and who reviews it; and what you would do in the first hour of a breach. What the analyst is assessing is not the sophistication of the answer, but whether the person answers with facts or with intentions.

Does it matter who runs the pentest?

Methodology and traceability matter; the brand does not. What gets examined is whether the report states the exact scope, the dates, the methodology followed, reproducible evidence per finding, and remediation status verified in a retest. A report generated mostly by an automated scanner is recognized immediately — generic findings, no business context, no proof of exploitation — and subtracts credibility rather than adding it.

Do all findings need fixing before the round?

No, and trying usually delays closing without adding anything. What is expected is that criticals and highs affecting customer data or product availability are closed, and the rest captured in a plan with an owner and a date. A remediation plan with realistic dates reads as management; an empty findings list reads as a shallow audit.

Where is all of this kept during the process?

In the data room, alongside the rest of the documentation, but it is worth separating access levels: policies and the executive summary can be open to the whole committee, while technical vulnerability detail is shared on a restricted basis with a record of who downloaded it. Reviewing the data room's own permissions is, incidentally, one of those things a security analyst checks in passing and comments on.

Related service

cybersecurity for startups

Related content

• Security due diligence for investors
• Security checklist before launching a SaaS startup
• SOC 2 for startups: practical guide
• Express penetration testing: what can be sped up

Sources

• NIST SP 800-115 — the product pentest methodology, the central piece of this checklist
• AICPA — SOC 2, mentioned in the checklist as a common requirement at later funding stages
• ISO/IEC 27001:2022 — mentioned in the checklist as a common requirement at later funding stages

Prepare my security checklist