Technical Due Diligence for VCs: What to Review, Red Flags and the Cost to Fix

Direct answer: Technical due diligence tells an investor what they are actually buying: how the product is built and run, whether the code and its licences are sound, how exposed the company is to a security incident, what its customers will demand in compliance, and how much of it depends on one or two people. A useful report gives a verdict, ties each red flag to deal impact, estimates what it costs to fix, and sets a first 100 days plan. A report that lists observations without that link back to the deal is research, not diligence.

What technical due diligence is for

Financial diligence tells you whether the numbers are real. Legal diligence tells you whether the company owns what it says it owns. Technical diligence answers a different question: can this product and this team deliver the plan in the deck, and what will it cost to find out they cannot?

That framing matters because it decides the scope. A seed investment in a five-person company does not need an architecture review fit for an acquisition. A growth round into a company selling to banks does need to know whether its security programme will survive the next customer audit. Before anyone looks at code, agree which decisions the review informs: invest or not, price, conditions, use of proceeds, and the first priorities after close.

What to review

Architecture and infrastructure

How the product is built, hosted and scaled. Where it runs, how environments are separated, what happens when load doubles, and what single components would take the product down. The question is not whether the architecture is elegant. It is whether it will carry the growth the plan assumes without a rewrite nobody has budgeted.

Code, dependencies and licences

Code quality in the areas that matter, test coverage on the paths that make money, the age and health of dependencies, and the licences attached to them. Copyleft licences in a distributed product can create obligations the company has not planned for. Ask, too, how much of the codebase was generated with AI tools and how it was reviewed. That is not a red flag on its own. Unreviewed generated code in authentication or payment paths is.

Security posture

Access to production and who holds it, how secrets are stored, cloud configuration, testing history, and incident readiness. Look for evidence rather than statements: the last penetration test report and what was fixed afterwards, an MFA report from the identity provider, a list of production admins, the incident response plan and the last time it was exercised.

Compliance against what customers will ask for

Not what the company has, but what its next customers will demand. A company selling to US enterprises will be asked for SOC 2. One selling to European or regulated Canadian buyers may need ISO 27001, Quebec Law 25 or PIPEDA evidence. The gap between today and that requirement is a cost and a timeline risk inside the sales plan.

Team and process

How changes reach production, who reviews them, who owns what, and how much knowledge sits with one person. At an early-stage company, key-person risk is often the most serious finding, and it is easy to miss because the key person is usually the one giving the walkthrough.

Red flags that change a deal

Not every finding matters to an investment. These are the ones that tend to change price, conditions or the decision itself:

• One person holds production. A single engineer with the only admin credentials, the only knowledge of the deployment, or the personal account the cloud bill runs on.
• Customer data with no access control story. Broad production access, shared accounts, no logging of who looked at what.
• Secrets in code or in chat. Keys committed to repositories, or passed around in messages, with no rotation since.
• A compliance claim the evidence does not support. Sales material that says "SOC 2 compliant" without a report, or a report whose scope does not cover the product being sold.
• Licence obligations nobody has read. Copyleft components in a distributed product, or third-party code with no licence at all.
• An unbudgeted rewrite. The plan assumes a scale or a market the current architecture cannot reach, and the engineering roadmap does not mention it.
• Cloud cost that grows faster than revenue. Not a security issue, but a margin issue an investor should see before close. Our cloud cost audit guide covers where it usually hides.
• A past incident with no record. If the company had a breach and cannot show what happened, what was notified and what changed, assume the process that failed is still in place.

Cost to fix, and why it belongs in the report

A red flag without a cost is an argument. A red flag with a cost is a negotiation input. For each material finding, a useful report says what fixing it involves, roughly how much effort, whether it needs a hire or a contractor, and whether it blocks revenue in the meantime.

Be careful with precision. A diligence review can estimate the effort to rotate secrets and restrict production access fairly well. It cannot honestly price a full compliance programme or a re-architecture to the dollar, because the detailed gaps are not yet known. Estimates should carry a range and say what would narrow it. Treat a single confident number for a large remediation with suspicion, whoever produced it.

The same logic is why our compliance work starts with a fixed-price gap analysis and prices remediation from the findings. Diligence is a lighter version of that first step, and should be honest about the difference.

Access and its limits

Read access to the repositories and cloud accounts in scope makes the review accurate. Some targets will not grant that before signing, which is reasonable. In that case the review works from documents, interviews and a supervised walkthrough of the environment, and the report should state that limit plainly so nobody reads it later as a code audit it never was.

Agree reliance terms up front. When an investor commissions the review, the report is theirs and the terms say who else may rely on it. When the startup commissions it to prepare, the report is theirs to share or not.

Portfolio baselines after the investment

Diligence is a snapshot at one moment. Funds increasingly want the same view across the portfolio after investment, because a security incident at one company is a reputational problem for the fund and, for some limited partners, a reporting obligation.

A portfolio baseline is a short, consistent review of each company against the same areas: identity and access, secrets, cloud configuration, incident readiness, and compliance position against what that company's customers need. The value comes from consistency. The same questions across twenty companies show which ones are carrying risk that the board has not seen, and where one programme, such as a shared incident response retainer or a common policy set, would lift several at once.

Keep it light. A baseline that takes a founder a week to complete will be done once and never again. One that takes an afternoon can be repeated each year and shows trend, which is what the fund actually needs.

Questions to ask whoever does the review

• Who will actually do the work, and what have they built or broken themselves?
• Will the report give a verdict, or only observations?
• How are red flags tied to deal impact and cost to fix?
• What access do you need, and how will the report describe any limits on it?
• Who may rely on the report, and under which province's law is the engagement signed?
• Where will target data live during the review, and when is it deleted?
• Can the same review become the baseline for portfolio monitoring after close?

Our technical due diligence is from $4,500 per company. It covers architecture, code and licences, security posture, compliance gaps and team, and ends in a report with a verdict, red flags tied to deal impact, estimated cost to fix and a first 100 days plan. If you are on the other side of the table, read how to prepare your startup for technical due diligence.

Frequently asked questions

When in the deal should technical due diligence happen?

After the investment thesis is formed and before terms are final, so findings can still change price or conditions. For larger deals, a light review before the term sheet and a fuller one before close is common.

Does a SOC 2 report replace technical due diligence?

No. A SOC 2 report tells you that defined controls were designed, and for Type II operated, over a period. It says nothing about architecture, code quality, licences, scalability or key-person risk. It is a useful input, and its scope should be checked against the product being invested in.

Can the target refuse code access?

Yes, and many do before signing. The review then relies on documents, interviews and a supervised walkthrough, and the report should say so.

What does a portfolio baseline cost compared with full diligence?

Less per company, because it is a shorter, consistent review rather than a deal-specific one. Scope it per fund on a call rather than per company in isolation.