Technical due diligence checklist: how to prepare before investors look

The short answer

• Technical due diligence is an independent assessment of a company’s technology, team and technical risk, commissioned by an investor or acquirer before a transaction.
• Reviewers want four answers: does the technology do what you claim, can it support the plan, what will it cost to maintain and fix, and is there anything that blocks the deal.
• Prepare across ten areas, from architecture and code to licensing, security and key-person risk, and organise the evidence in a data room before you are asked.
• Fix the red flags that are cheap to fix. Disclose the rest with a plan. Surprises damage trust more than findings do.

What technical due diligence is

Technical due diligence is the technology part of the wider due diligence an investor or acquirer carries out before committing money. It is usually performed by an independent reviewer, either the investor’s own technical staff or an outside firm, and it ends in a report that rates findings by their impact on the investment.

It typically happens before a significant funding round, an acquisition, or a merger, and its scope scales with the size of the deal. In a smaller round it may be a few conversations and a look at the architecture. In an acquisition it can include code scanning, detailed interviews with the engineering team and a review of every material contract. Comtau’s page on technical due diligence for investors and acquirers describes the process from the reviewer’s side; this guide is written for the company being reviewed.

What reviewers are trying to learn

Every question in a technical review serves one of four underlying questions. If you prepare answers to these, the detailed questions become much easier.

1. Does the technology do what the company says it does? Claims in the pitch, about scale, automation, AI, security or integrations, will be checked against the system.
2. Can it support the business plan? If the plan assumes ten times the customers or a new market, the reviewer will ask what has to change in the system and the team to get there.
3. What will it cost to maintain and improve? Technical debt, ageing components and missing practices become line items in the investor’s model.
4. Is there anything that could block or reprice the deal? Ownership of the code, licence obligations, security weaknesses, and dependence on individuals or vendors fall here.

The ten-area checklist

The areas below cover what most technical reviews examine. Not every item applies to every company; the point is to know your answer before the reviewer asks.

Technical due diligence preparation checklist

Checklist

1. Architecture and scalability

• A current architecture diagram that matches production
• An explanation of how the system would scale to the business plan
• Known bottlenecks and the plan for each

2. Code quality and technical debt

• Repository access ready for the reviewer
• Test coverage and how tests run in the pipeline
• A short register of known technical debt and its priority

3. Infrastructure and operations

• Hosting, environments and how they are provisioned
• Monitoring, alerting and on-call arrangements
• Backups, and evidence that restores have been tested

4. Security

• How access to production and critical accounts is controlled
• How secrets are stored, and confirmation none are in the code
• Recent security testing, findings and their status

5. Data and privacy

• What personal data you hold, where and why
• Data processing agreements with key vendors
• How customer data is separated and deleted on request

6. IP and open-source licensing

• Proof that the company owns its code, including work by contractors
• An inventory of open-source dependencies and their licences
• Any copyleft licences and how their obligations are met

7. Team and key-person risk

• An organisation chart with roles and tenure
• Areas only one person understands, and the plan to share that knowledge
• Contractors and agencies, and what they own

8. Delivery process

• How work moves from idea to production
• Release frequency and how failures are handled
• How incidents are reviewed and followed up

9. Roadmap and technical plan

• The technology roadmap and how it supports the business plan
• Planned hires and why they are needed
• Major technical investments expected in the next 12 to 24 months

10. Third-party and AI dependencies

• Critical vendors, their contracts and what happens if one fails
• Any AI models or services used, and how outputs are checked
• Costs that rise with usage, and how they scale

Building the data room

A well-organised data room shortens the review and signals that the company understands its own technology. Structure it so that a reviewer can find each area of the checklist without asking.

Folder	Contents	Notes
01 Overview	One-page technology summary, architecture diagram, glossary	Write the summary for a non-specialist investor as well as the reviewer
02 Architecture	Component descriptions, data flows, significant decision records	Diagrams must match production, not the target design
03 Code and quality	Repository list, test and pipeline description, technical debt register	Grant repository access only under the agreed terms
04 Infrastructure	Hosting, environments, monitoring, backup and restore evidence	Include the date of the last restore test
05 Security and privacy	Access policy, security test reports, data inventory, key processing agreements	Share sensitive reports only once confidentiality terms are in place
06 IP and licences	IP assignment evidence, open-source licence inventory	Coordinate with your legal advisers
07 Team	Organisation chart, roles, contractors, hiring plan	Follow your legal advice on sharing personal data
08 Plan	Technology roadmap, budget assumptions, major planned investments	Must agree with the business plan in the main data room

Red flags reviewers look for

Some findings are routine: every system has technical debt and gaps in documentation. Others can change the valuation, the deal terms or whether the deal happens. The second kind are the ones to look for first in your own company.

• Unclear ownership of the code, for example work by contractors or agencies without a written assignment of intellectual property.
• Licence obligations not met, such as copyleft-licensed code in a distributed product without the required compliance steps.
• Secrets in the code repository, such as passwords or access keys committed to version control.
• One person holding the keys, with sole access to production, the cloud account, the domain or critical vendor accounts.
• Backups that have never been restored, so nobody knows whether recovery would work.
• Claims the system does not support, such as automation that is partly manual, or scale that has never been tested.
• Unknown or unreviewed access to production, including former employees or contractors who still have it.
• A core component nobody can change safely, usually written by someone who has left.

For each red flag you find, decide whether to fix it before the review or disclose it with a remediation plan. Access, secrets and ownership paperwork are often quick to fix. Architectural issues usually are not, and an honest plan with owners and dates is worth more to a reviewer than a hurried change.

A preparation timeline

How much you can do depends on how much notice you have. Use whichever plan matches your situation.

Preparing for technical due diligence

Timeline

1. With three months or moreRun an internal review against the checklist, fix quick red flags, start knowledge sharing on key-person areas and begin the data room.
2. With about a monthComplete the data room, write the one-page technology summary, document the technical debt register and agree who answers which questions.
3. With a week or twoFix access and secrets issues, confirm the architecture diagram matches production, and brief the engineers who will be interviewed.
4. During the reviewAnswer in writing through one point of contact, track every question and keep answers consistent.
5. After the reportTurn the findings into a remediation plan with owners, and build them into the post-transaction roadmap.

Running the review

• Use one point of contact. Usually the CTO or most senior engineer, supported by the founder. Questions spread across many people produce inconsistent answers.
• Answer in writing where you can. Written answers are easier to keep consistent and to reuse in later rounds.
• Do not over-claim. If the answer is “we have not tested that”, say so and explain what you would do. Reviewers distinguish between gaps and misrepresentation.
• Prepare engineers for interviews. Not with scripts, but with the context: what the reviewer is trying to learn and which areas they will ask about.
• Keep a question log. Record every question, who answered and when. It shows patterns in the reviewer’s concerns and stops questions getting lost.

After the review

The report is also a free external assessment of your technology. Turn its findings into a plan: which items to address now, which to schedule and which to accept with a reason. If the transaction goes ahead, those items become part of the first months of work after closing, and they belong on the technology roadmap. Technical debt findings in particular are easier to act on with a clear method for reducing technical debt without stopping delivery.

If you want an independent view before investors form theirs, a fixed-scope software architecture review covers the system’s shape and risks, and is a practical rehearsal for the real review.