A technical due diligence questionnaire

A technical due diligence questionnaire is a written list of questions sent to the target company before any interview, and its job is to collect facts and artefacts so that the interview time can go to judgement. A good one asks for things that can be opened: a repository, a dashboard, a policy document, an invoice. A weak one asks for descriptions, and gets slide decks.

The questionnaire below has 48 questions in eight areas. Each question is followed by the reason it is asked. Reveneau sends the questions with the reasons attached, because a target that knows why a question matters gives a shorter and more honest answer, and because the reason is what tells the reviewer whether the answer met the question or stepped around it. Use it whole, or cut it to the areas your deal depends on.

This page complements the checklist, which is what the reviewer checks, and the report template, which is where the answers end up. The pillar guide explains how the three fit together.

Why does an investor need a technical questionnaire at all?

An investor needs a technical questionnaire because the standard diligence guidance investors inherit has almost nothing technical in it. The Angel Capital Association's Best Practice Guidance for Angel Groups: Due Diligence (2007) covers management, market, IP viability, deal structure and financial assumptions, and has no section on software, code or engineering. The UK Business Angels Association's The due diligence process (2020) does have a technology section of eight questions, and all eight are about positioning and IP: whether the technology is stand-alone, whether it needs licensing in, whether it is a platform, whether it can be protected, whether it is incremental, whether it is ready for market, and what the trends are. None asks how the software is built, tested, deployed or secured.

Matt Van Itallie's TechCrunch checklist of 2022-10-26 is the closest published equivalent, and it is written for the founder side, with seven categories: product roadmap, code quality, intellectual property, security, development process, engineering team contributions, and DevOps. The questionnaire below covers the same ground from the investor's side and adds two areas that checklist does not cover: cloud cost and AI-written code.

How should the questionnaire be sent and answered?

Send the questionnaire as a document the target can answer inline, at least a week before the first interview, with a request that every answer name an artefact and grant read access to it. Ask for the name of the person answering each area. Say in the covering note that "we do not have that" is an acceptable answer and that a described artefact that does not exist is the thing the review is designed to find.

When the answers come back, sort them into three piles: answers with an artefact you can open, answers with a description only, and questions left blank. The interviews start from the second and third piles. The first pile goes to verification, which is where the review's real work is; how to run technical due diligence covers that step.

The questionnaire

A. Codebase and code quality

1. List every repository, its primary language, its approximate size, and the product or service it belongs to. Why: the inventory sets the scope of the code review and shows whether the company knows what it owns.
2. Which repositories are in active development and which have not changed in twelve months? Why: dormant code that production depends on is a maintenance liability nobody is watching.
3. What automated tests exist, what do they cover, and how long does the full suite take to run? Why: the answer decides whether the software is safe to change at the pace the plan assumes.
4. When did the test suite last fail on the main branch, and what happened? Why: a suite that never fails is either excellent or ignored.
5. Describe the code review process. Is a review required to merge, and who can override it? Why: the process reveals whether quality depends on rules or on individuals.
6. Which third-party services and APIs does the product depend on, and which have no fallback? Why: an external dependency without a fallback is an outage that the company cannot fix.

B. Architecture and scalability

7. Provide the current architecture diagram and the date it was last updated. Why: a diagram older than a year describes a system that no longer exists.
8. What is the largest load the system has handled in production, and when? Why: measured load is the only evidence of capacity; a design that has never been tested at scale is a hypothesis.
9. Which component would fail first at ten times current usage, and what would it take to fix? Why: a team that knows the answer has thought about scale; a team that does not has not.
10. List every production incident in the last twelve months with its duration and root cause. Why: the incident history is the true record of reliability, and its absence is a finding.
11. What single points of failure exist in the infrastructure, including accounts, keys and people? Why: single points of failure are where the cost to fix concentrates.
12. What is the disaster recovery plan, when was it last tested, and what was the result? Why: an untested recovery plan is a document, and a tested one is a capability.

C. Engineering team and process

13. List every engineer with role, start date, location, employment type and the systems they own. Why: ownership by name is how key-person risk is found.
14. Which systems have only one person who can change them safely? Why: this is the most expensive answer in the questionnaire, and it is cheaper to hear it now.
15. What was engineering attrition over the last twenty-four months, and who left? Why: attrition is the leading indicator of a team that cannot carry the plan.
16. Provide deployment frequency, change lead time, change fail rate and time to recover for the last six months. Why: DORA's four keys are measured delivery performance, and a team that can produce them has a pipeline that produces them.
17. Describe how work is planned, estimated and prioritised, and who decides. Why: the process shows whether the roadmap in the deck is connected to the team that has to build it.
18. What share of engineering time in the last two quarters went to new features, maintenance and incident response? Why: the split is the honest measure of technical debt's interest payments.

D. Security and compliance

19. When was the last external penetration test, who ran it, and provide the report and the remediation status. Why: a security claim without a third-party report is a self-assessment.
20. How are secrets, keys and credentials stored, rotated and revoked when someone leaves? Why: credential handling is the first thing an attacker and a reviewer both look at.
21. Who has production access, and how is it granted, reviewed and removed? Why: access lists grow and are rarely pruned; the list is a finding in itself.
22. What security certifications or attestations does the company hold, and provide the current reports. Why: a certification named in a deck and a certification with a current report are different claims.
23. List every security incident or breach in the last three years and the notifications made. Why: the legal exposure from a breach outlives the incident.
24. Which regulations apply to the data the product handles, and how is compliance evidenced? Why: the answer decides whether security and compliance is a technical review or a liability review.

E. Open source and intellectual property

25. Provide an inventory of all open source components with their licences, in SPDX identifiers if possible. Why: SPDX identifiers are the standard names for licences, and an inventory in them can be checked by a tool.
26. Is there a written open source policy, and who approves the use of copyleft-licensed code? Why: Morgan Lewis's June 2026 note lists a written policy and copyleft approval among the areas buyers ask about.
27. When was the last licence scan run, with what tool, and what did it find? Why: the same note observes that scans often find issues that have to be fixed before closing.
28. Does the company contribute to open source projects, and under what approval process? Why: contributions can carry proprietary code out of the company.
29. Which parts of the codebase were written by contractors, agencies or former employees, and do assignment agreements exist for each? Why: code the company does not own cannot be sold.
30. Which parts of the codebase were generated by AI tools, which tools, and under what review process? Why: AI-written code raises its own provenance and security questions, covered in diligence on an AI-written codebase.

F. Infrastructure and cloud cost

31. Provide the last twelve months of cloud invoices by account and by service. Why: the bill is the only unarguable record of what the system costs to run.
32. What commitments (savings plans, reserved instances, committed use discounts) are in place, with their terms and end dates? Why: commitments are contracts the buyer inherits, and their expiry changes the bill.
33. What is cloud cost per customer or per unit of usage, and how has it moved over twelve months? Why: unit cost rising faster than revenue is a margin problem the deck will not show.
34. Which resources have been identified as idle or unused, and what has been done about them? Why: an answer of "none" means nobody has looked.
35. How is infrastructure defined and deployed, and could the environment be rebuilt from the repository? Why: infrastructure that exists only in a console is infrastructure only one person understands.
36. What monitoring and alerting exists, and who is paged when it fires? Why: the answer tells you whether incidents are found by the team or by customers.

G. Data

37. What personal data does the product store, where, and under which lawful basis? Why: data is where regulatory exposure lives.
38. How are backups taken, where are they stored, and when was a restore last tested? Why: a backup that has never been restored is a hope.
39. Which data does the product depend on that the company does not own or cannot re-obtain? Why: a data dependency without a contract is a dependency that can be withdrawn.
40. How is customer data separated between tenants, and has that separation ever failed? Why: a tenancy failure is a breach with every customer as a victim.

H. Product and roadmap

41. Provide the twelve-month roadmap and the engineering estimate for each item. Why: the gap between the roadmap and the estimates is the gap between the deck and reality.
42. Which roadmap items depend on work that has not started, including rewrites or migrations? Why: a hidden prerequisite is a hidden year.
43. What has been promised to customers in writing that is not yet built? Why: contractual commitments are engineering work with a legal deadline.
44. What is the largest technical bet the company is making in the next year, and what is the fallback? Why: the answer shows whether the team has thought about being wrong.
45. Which features account for most usage, and which would be removed if resources were cut? Why: the answer reveals whether the team knows where the value is.
46. How does product feedback reach engineering, and give a recent example that changed a decision. Why: a process with no example is a diagram.
47. What has the team said it would fix in the last two years that remains unfixed, and why? Why: the list of deferred repairs is the technical debt register written in the team's own words.
48. If you could change one architectural decision, which one and what would it cost? Why: engineers always have an answer, and it is usually the most important finding in the review.

What makes a questionnaire answer good, and what makes it a finding?

A good answer names an artefact and grants access to it. A finding is an answer that describes an artefact that turns out not to exist, that contradicts another answer, or that is missing without a reason.

Three patterns are worth watching for. The first is the described process with no example: "we do code review" with no pull request to open. The second is the certificate without the report: a security attestation named in a deck with no current document behind it. The third is the round number: a test coverage figure, a uptime figure, or a cost figure that nobody measured. Technical due diligence red flags covers what to do when several of these appear together.

The questionnaire is the cheapest part of the review and the part most often skipped. Sent a week early, it turns the first interview from a fact-finding session into a conversation about what the facts mean, and it gives the reviewer a written record to hold the target to when the report is challenged.