Technical due diligence checklist for startups: code, security and the team

Technical due diligence is the part of due diligence that asks whether the technology does what the company says, whether the company owns it, and what it will cost to keep it running and growing. It sits beside legal and financial diligence and feeds into both: an open source licence problem becomes a legal issue, and a cloud bill that grows faster than revenue becomes a financial one.

For founders the useful framing is simple. The reviewer is trying to answer three questions: can this product scale to the plan in the deck, are there hidden liabilities in the code or the data, and can the team deliver without one or two people who might leave. Everything on the checklist below supports one of those three.

Who runs technical due diligence, and how deep does it go?

The reviewer and the depth change with the stage and the type of deal. The pattern below is common in US venture and M&A deals, but every investor sets its own process.

For a full M&A context, our guide on preparing your startup for acquisition due diligence covers the other workstreams and the deal terms findings turn into.

What should the technical part of the data room contain?

Put the technical files in one numbered folder with sub-folders that match the reviewer’s request list. Our startup data room checklist has 25 items across the product and technology, intellectual property, and security and privacy folders, each marked with the stage at which investors start to ask for it.

The checklist, area by area

Each list below names the documents and answers a reviewer will expect. Not every startup needs every item; a seed company with five engineers can answer many of them in a short written note rather than a formal policy.

1. Architecture and scalability

Reviewers do not expect a seed-stage product to be built for millions of users. They expect the team to know where it will break and what the fix costs. A short “known limits” note written by the CTO answers half of this section.

2. Code quality and engineering process

Ugly code is rarely a deal issue. A reviewer reads it as a cost: so many engineer-months to refactor before the next stage. Missing tests, no code review and manual deploys read as a process risk, because they predict outages and slow delivery after the money arrives.

3. Open source licences

Almost every product contains open source code. The question is which licences, and whether you meet their conditions. A software bill of materials (SBOM) lists every component and version; the two common formats are SPDX and CycloneDX, and CISA’s SBOM resources explain both. A software composition analysis tool can produce one and flag licences and known vulnerabilities.

The Open Source Initiative keeps the texts of approved licences. Whether a specific use triggers a copyleft obligation is a legal question, so have counsel review anything the scan marks as strong or network copyleft before the room opens.

4. Security and compliance

Security diligence starts with documents and ends with questions. The documents tell the reviewer which framework you follow; the questions check that it is real.

SOC 2 reports are issued by CPA firms under the AICPA’s Trust Services Criteria. Many startups have neither SOC 2 nor ISO 27001 at Series A; a reviewer then looks for a plan with dates and the basic controls already in place.

5. Infrastructure, reliability and cost

Cost is the part founders most often skip. If hosting grows faster than revenue, the reviewer will flag gross margin as a risk, and the financial diligence team will pick it up. Showing cost per customer falling as you grow is one of the clearest signals of a sound architecture.

6. Data, privacy and AI

AI products draw extra questions. Reviewers want to know whether the company could lose access to a model it depends on, whether customer data trains shared models in breach of a contract, and whether training data came with the rights the product needs. Clear written answers turn these from open risks into closed questions.

7. The engineering team

How should you share source code with a reviewer?

Most companies never hand over a full copy of their code before signing. Documents go in the data room; the code itself is shown in controlled ways, and the level of access rises as the deal gets closer.

The common options, from least to most access:

1. Walkthrough. The CTO shares a screen and answers questions while showing the code.
2. Read-only session. A reviewer gets time-limited read access to selected repositories, often under a separate NDA.
3. Automated scan by a third party. A neutral firm runs licence and vulnerability scans and reports results to both sides without passing on the code.
4. Clean room review. Named reviewers from a competing buyer see code under strict rules, close to signing.

Security reports deserve the same care. A pen test report lists weaknesses; once fixed it is fine to share, but share it view-only with watermarks so copies can be traced. The security review page covers how to answer questionnaires from customers and investors with the same document set.

Which findings are red flags, and which are normal?

Reviewers sort findings by severity. Founders often worry about the wrong ones. This table shows how the same reviewer tends to read common findings.

How do you prepare in 30 days?

If a term sheet or an LOI is close, a month is enough to get the technical folder into shape. The order matters: ownership problems first, because they take the longest and cost the most if found later.

Then check where the rest of the room stands. The readiness score below weights the nine document sets investors and buyers check first; IP assignments and security documents are two of them.

The use-case pages go further on each part: technical due diligence for the full folder index and the rooms that rank best for it, and IP due diligence for patents, assignments and licences.