A technical due diligence report: structure and a template you can copy

A technical due diligence report is the written answer to one question: can this technology carry the plan the money is paying for, and if not, what will it cost to get it there. Everything in the document serves that answer, and the structure below is built so the answer arrives on page one and the evidence follows in the order a sceptical reader would ask for it.

The template is free to copy. It is the shape Reveneau uses for its own diligence reports, and the reason we publish it is that the shape matters more than the author: a firm that delivers findings in this order, with a severity scale and a cost to fix on every line, can be compared with any other firm that does the same. If the report you receive cannot be mapped onto these nine sections, ask why.

For the process that produces the report, read how to run technical due diligence. For what to ask the target in writing before the interviews, use the questionnaire. For where this sits in the wider review, start at the pillar guide.

What does a technical due diligence report contain?

A technical due diligence report contains nine sections: an executive summary, the scope and access statement, the method, findings by area, a risk register, a cost-to-fix estimate, a list of what could not be verified, recommendations, and an appendix of evidence. Vendor descriptions of the deliverable agree on the shape even where they use different words. madewithlove describes its output as "a written, qualitative report" built for investment committees and boards, with a sample that runs to "Twenty-one pages". The seven categories in Matt Van Itallie's TechCrunch prep checklist of 2022-10-26 (product roadmap, code quality, intellectual property, security, development process, engineering team contributions, DevOps) map onto the findings section below almost one to one.

The order is the point. A deal partner reads the summary. A lawyer reads the risk register and the unverified list. An operating partner reads the cost to fix. A CTO who joins after close reads the appendix. Each of them should be able to open the document, go to their section, and find it complete.

The template, section by section

Copy the headings below into a document. The notes under each say what belongs there and what does not.

1. Executive summary (one page). Open with the answer: whether the technology can support the thesis as scoped, in one sentence. Then the three to five findings that change the deal, each with its severity and its cost to fix. Then the overall repair bill as a range, with the assumptions behind it. Then the single most important thing that could not be verified. Nothing else goes on this page.

2. Scope and access. State what was in scope (products, repositories, environments, teams) and what was out. State the access received: read access to which repositories, which cloud accounts, which dashboards, and how many interviews with whom. State the dates. A reader in a year needs to know what this report could and could not have seen.

3. Method. Say how each finding was reached: direct code reading, automated scanning (name the tools), interviews, document review, or the target's own demonstration. This section is short and it is what makes the verified column in the findings honest.

4. Findings by area. One subsection per area. The five areas the rest of this guide uses are code quality, architecture and scalability, the engineering team, security and compliance, and technical debt. Add open source licences, cloud cost, and data handling as their own subsections when the deal warrants them. Each finding is a row with the same four fields, described in the next section.

5. Risk register. Every finding rated High or Critical, collected in one table, sorted by severity, with an owner on the target side, a proposed remedy, a cost, and a proposed contractual treatment (fix before close, fix within 100 days, price adjustment, warranty, or accept).

6. Cost to fix. A single table: each High or Critical finding, the engineering effort in weeks, the calendar time, whether the current team can do it while shipping, and the money. Give ranges and state the assumptions. This is the section that turns a technical review into a number the deal can use.

7. What could not be verified. A plain list of every claim the target made that the reviewers could not check, with the reason (no access, no time, no artefact exists). This list is where most post-close surprises come from, so it must be complete and it must be honest.

8. Recommendations. What to do before signing, what to write into the agreement, and what to do in the first 100 days. Turning the diligence report into the first-year plan covers the third part.

9. Appendix. Interview list, repository inventory, dependency and licence inventory, scan outputs, architecture diagrams as found, the delivery metrics pulled, and the questionnaire responses.

How should each finding be written?

Each finding is written as a row with four fields, and the same four fields on every row make the report comparable across areas and across firms. The fields are observation, verification, severity, and cost to fix.

Field	What goes in it	Example
Observation	What was seen, stated as a fact with a location	"The payments service has no automated tests; the tests directory contains one file, last changed 2024-03."
Verification	How it was confirmed: read, scanned, interviewed, or reported by the target only	"Read directly in repository X; confirmed by the lead engineer in interview 3."
Severity	A rating on the scale defined in the report	"High"
Cost to fix	Effort, elapsed time, and money, with the assumption	"6 to 8 engineer-weeks; can run alongside feature work; $X at the target's loaded cost."

The verification field is what keeps the report honest. A finding the reviewer read in the code and a finding the target described in a slide are different kinds of knowledge, and a report that mixes them without saying so is asking the reader to trust the target through the reviewer. Keep "reported by the target" as its own value and expect the deal team to read those rows differently.

Where the target has delivery data, put the numbers in the observation. DORA's four keys guide defines change lead time, deployment frequency, failed deployment recovery time and change fail rate (plus deployment rework rate) as the metrics of software delivery performance, and a target that can produce them from its own pipeline gives the reviewer something measured to write down instead of an adjective.

What severity scale should the report use?

The report should use a five-band scale with a written definition per band, and CVSS v4.0's qualitative ratings from FIRST (specification version 1.2, 2024-06-18) are a sound base: None at 0.0, Low from 0.1 to 3.9, Medium from 4.0 to 6.9, High from 7.0 to 8.9, and Critical from 9.0 to 10.0. CVSS scores are built for individual security vulnerabilities, so keep the numeric scores for those and use the bands with deal-specific definitions for everything else.

Band	Definition for a diligence finding	Typical contractual treatment
Critical	Blocks the thesis as scoped, or creates a legal or security exposure that cannot be carried past close	Fix before close, or restructure the deal
High	Materially raises the cost or delays the plan; likely to cause an incident or a hiring emergency within a year	Fix within 100 days; price or warranty adjustment
Medium	Real cost, bounded and schedulable; would appear on any competent team's roadmap	Include in the first-year plan
Low	Housekeeping; costs little and blocks nothing	Note and move on
None	Observation only, recorded for completeness	Appendix

Write the definitions into the report itself. A reader should never have to guess whether "High" in this document means the same thing as "High" in the last one. If the firm you hire uses its own scale, ask for the definitions in the same place.

How long should the report be, and who is it for?

The report should be as long as the evidence needs and no longer, with the first page complete on its own. madewithlove's published sample runs to twenty-one pages for a two-week review with up to eight interviews, which is a reasonable size for a venture or growth deal with one product. A buyout with three products will run longer, mostly in the appendix.

Write the summary for the investment committee, the register for the lawyers, the cost table for whoever owns the value creation plan, and the appendix for the engineer who will inherit the system. Each audience reads one section, and each section has to survive being read alone. That is also why every table repeats the finding's identifier: a reader who arrives at the cost table from the summary should be able to trace the number back to the observation without reading the sections in between.

What are the common mistakes in a technical due diligence report?

The common mistakes are an executive summary that describes the process instead of the answer, findings without a cost, severity without a definition, and an unverified list that is missing because the reviewer did not want to admit what was skipped.

A summary that opens with "we reviewed the codebase over two weeks" has wasted its most valuable sentence. Open with the answer. A finding without a cost is an opinion; a finding with a cost is a term sheet input. A severity with no written scale is an adjective. And a report with an empty section 7 was either given perfect access and unlimited time, or it is hiding something.

The template exists so that none of those can happen quietly. If you commission a review and the report arrives in a different shape, the page on choosing a firm covers what to ask before the next one. If you would rather have the review run to this template from the start, the investor page describes what the engagement looks like.