Technical due diligence: the process, checklist and report

What investors check, and why

Investors use technical due diligence to answer three questions. Does the product actually work the way the pitch says? Can the technology and the team scale with the plan this money is paying for? Could anything blow up after the deal closes? Think of a security hole, a licence problem, an ownership gap or one engineer who holds the whole system in their head. Every item on a checklist traces back to one of these three.

The emphasis shifts with the stage of the company:

• Pre-seed and seed: the team's ability to build, a sensible architecture, basic security and clean ownership of the code. Investors know the product is early, so they look for the habits that will matter later.
• Series A and later: scalability, delivery process, security practice, cloud costs and how much technical debt the next stage will have to carry.
• Acquisition: everything above, plus a full inventory of code, open source licences, contracts, data and the people who would need to stay for the product to keep working.

A useful way to read the process is that a review exists to price risk, not to look for a reason to walk away. Findings usually turn into conditions, changes to terms or the first items on the post-deal plan.

The technical due diligence process, step by step

The technical due diligence process follows the same broad sequence whether the deal is a seed round or an acquisition. It moves from scope to evidence to judgment. Agree the questions and the access, collect documents, run automated scans and read the code and architecture. Then talk to the team, review the infrastructure and security, and write a report that ranks the findings. The company normally gets to correct factual errors before the report is final. How long each step takes depends on the size of the codebase, how organized the company is and how fast it grants access. That is why the timeline is agreed during scoping rather than assumed. Each of the eight steps below produces something specific: a scope, a request list, scan results, review notes, interview notes, an infrastructure picture, a report and a plan. If a reviewer cannot tell you what each step will produce for your deal, ask before the review starts.

1. Scope and access

The investor, the company and the reviewer agree on the questions the review must answer, the systems in scope, the depth and the deadline. A confidentiality agreement comes first. Access is usually read-only: repositories, cloud consoles, monitoring tools and documentation.

2. Document request

The reviewer sends a request list: architecture diagrams, a list of systems and vendors, security policies and past penetration test reports. It also asks for incident reports, the engineering org chart and any known technical debt. Gaps in the answers are findings too.

3. Automated scans

Tools scan the code and dependencies for known vulnerabilities, secrets committed to the repository, open source licences and code quality signals. CISA recommends using its Known Exploited Vulnerabilities catalog as an input to prioritization, which helps separate a theoretical weakness from one attackers are actively using. Scan output is a starting point, never the conclusion.

4. Code and architecture review

A senior engineer reads the critical paths by hand: sign-up and login, permissions, payments, data access and anything the pitch depends on. The question is not whether the code is pretty. It is whether it is understandable, tested and safe to change.

5. Team interviews

Conversations with the CTO and engineers show how decisions are made, who knows which part of the system and how work gets from an idea to production. They also surface the known problems that never made it into a document.

6. Infrastructure and security review

The reviewer looks at how production runs: cloud accounts and who controls them, backups and restores, monitoring and alerting, access management, incident history and cloud costs.

7. Findings and report

Findings are written up with severity, evidence and a recommended fix. A draft goes to the company for factual corrections, then the final report goes to whoever commissioned it.

8. Follow-up

The report feeds the deal: conditions before closing, changes to terms or a remediation plan for the first months after the money arrives. Good reviews end with a plan the engineering team can actually execute.

Technical due diligence checklist

This technical due diligence checklist is organized by area. The table gives the short version, with the evidence a reviewer will ask for. The sections after it list the detailed questions, and you can use them as a tech due diligence checklist from either side of the deal.

Product and architecture

• An architecture diagram that matches production, not the pitch deck.
• Where each component runs, how components talk to each other and which ones are single points of failure.
• How customer data is separated in a multi-tenant system, and how that separation is enforced.
• The build-or-buy choices behind core features, and the third-party services the product cannot run without.
• Whether the capabilities claimed in the pitch, such as AI features, real-time processing or scale, exist in the code today.

Code quality and maintainability

• Languages, frameworks and versions in use, and whether any are past their end of support.
• Automated tests on the critical paths, and whether they run on every change.
• Code review before merging, and who is allowed to push straight to production.
• A written list of known debt, sorted by the types of technical debt involved and the cost of leaving each item alone.
• Large blocks of generated or copied code that nobody on the team can explain.

Security

• Authentication and authorization on every endpoint. Broken access control is first on the OWASP Top 10:2025, and it is the first thing worth testing.
• Secrets management: no keys or passwords in the repository or its history, and a way to rotate them.
• Known vulnerabilities in dependencies, with the ones in CISA's exploited list fixed first.
• The last penetration test, its findings and evidence that they were fixed. The OWASP Application Security Verification Standard gives reviewers a baseline for testing application security controls.
• Secure development habits. NIST's Secure Software Development Framework, SP 800-218, describes a core set of practices that can fit into any development process.
• Multi-factor authentication on admin and cloud accounts, and an offboarding routine that removes access when people leave.
• Past incidents, how they were found, how they were handled and what changed afterwards.
• Any compliance report the company shows customers. A SOC 2 report, for example, covers controls relevant to security, availability, processing integrity, confidentiality or privacy. A reviewer will check that its scope matches the product being sold.

Open source and intellectual property

• A software bill of materials. CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components.
• Open source licences, with attention to copyleft terms. The GNU Affero General Public License, for example, requires a modified version that users interact with over a network to offer those users its corresponding source.
• Signed intellectual property assignments from every founder, employee, contractor and agency that wrote code.
• Code brought in from a previous employer or client, and the terms of any AI coding tools used to write the product.
• The health of critical open source dependencies. The OpenSSF Scorecard runs automated checks that flag security risks in open source projects.

Infrastructure, reliability and cost

• Cloud accounts owned by the company, with root access held by more than one person and protected by multi-factor authentication.
• Infrastructure defined in code, or at least documented well enough to rebuild.
• Backups, and the date of the last restore that was actually tested.
• Monitoring, alerting, on-call arrangements and written postmortems for past outages.
• Uptime commitments in customer contracts compared with real availability.
• Cloud cost per customer and its trend. Costs that grow faster than revenue are a finding.

Data and privacy

• A data map: what personal data the product stores, where it lives and who can reach it.
• Canadian privacy law. PIPEDA applies to private-sector organizations that collect, use or disclose personal information in commercial activities, and its accountability principle covers personal information transferred to a third party for processing. Reviewers will ask for the list of processors.
• Other regimes that apply to the customer base, such as the GDPR for people in the European Union.
• Retention and deletion: how long data is kept and whether a customer's data can be removed on request.

AI features and model providers

• Which model providers the product calls, under which terms and with what customer data.
• Dependence on a single model version, and a plan for when that version is retired.
• Defences against prompt injection, which leads the OWASP Top 10 for LLM Applications 2025, and limits on unbounded consumption so one user cannot run up the bill.
• Obligations under the EU AI Act if the product serves people in the EU. Our update on EU AI Act enforcement: what startups calling model APIs must do covers the dates and duties.

Team and delivery

• Key-person risk: how many people can deploy, and how many understand production well enough to fix it at night.
• Delivery measures. DORA's research uses five: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate.
• Onboarding documents and runbooks that let a new engineer contribute without constant help.
• Reliance on contractors or agencies, and what happens to the product if that relationship ends.
• A hiring plan that matches the roadmap the money is meant to fund.

What the technical due diligence report should contain

A technical due diligence report should let a non-technical partner understand the main risks in a few minutes and let an engineer verify every finding. That means a short executive summary of the key risks and a clear statement of scope and method. Then come findings by area with severity and evidence, and a remediation plan with rough effort for each fix. It should also say plainly what was not reviewed, because a gap in scope is not the same as a clean result. Severity needs a definition the reader can apply, so "high" means the same thing on page two and page twenty. Strong reports also record what the company does well, since strengths shape the plan as much as weaknesses do. Expect the report to separate facts, such as a scan result or a configuration, from judgments, such as whether an architecture will hold at ten times the load.

A typical report runs in this order:

1. Executive summary: the few risks that matter for the deal, in plain language.
2. Scope and method: systems reviewed, access granted, tools used and interviews held.
3. Not reviewed: anything out of scope or not accessible.
4. Findings by area: each with severity, evidence, business impact and a recommended fix.
5. Strengths: what the team does well and can build on.
6. Remediation plan: fixes in order, with rough effort and who should do them.
7. Appendices: scan summaries, the software bill of materials and the document list.

Severity ratings are only useful if they map to a decision. A simple scale like this one works for most deals:

Red flags that change the terms of a deal

Most findings are routine. These are the ones that tend to move a deal, because they are expensive, slow to fix or a sign of deeper problems:

• Nobody can rebuild and deploy the product from the repository without help from one specific person.
• Secrets sit in the code or its history, and nobody has rotated them.
• Customer data can be reached without an access check, or one customer can see another's records.
• Core code was written by contractors or an agency with no signed IP assignment.
• Copyleft code is used in a way the licence does not allow for how the product is distributed or served.
• There are no backups, or no restore has ever been tested.
• Capabilities in the pitch do not exist in the code, or exist only as a demo.
• Cloud costs grow faster than revenue, with no plan to change that.
• The team cannot say what its own known technical debt is.

How founders should prepare for technical due diligence

Preparation comes down to removing surprises. Investors expect an early-stage company to have technical debt. What hurts is debt nobody mentioned, ownership gaps and security issues that a scan finds in minutes.