What a technical due diligence report actually contains

The examination takes a fortnight. The document outlives it by years, gets forwarded to people who were not in the process, and is read during a negotiation by someone looking for a reason to move the price.

That is the actual specification for this artifact, and it is why the structure matters more than the prose.

The exercise that produces it is described on the technical due diligence page. This is about the document.

Three readers who need different things

The decision maker reads the first page and nothing else unless something alarms them. They need to know whether to proceed, at what price, with what conditions.

The technical reader on the other side will check the findings against what they know. If anything is wrong, everything becomes suspect, so accuracy at this level protects the whole document.

The lawyer is looking for anything that becomes a warranty, a condition precedent, or a disclosure. They need findings stated precisely enough to reference.

A report written for only one of these fails the other two. The structure below serves all three by separating them.

The four sections

Findings that would change the decision. Usually three to seven items. Each one: what was found, how it was established, what it would cost to remedy, and what happens if it is not. If there are twenty, they have not been prioritised.

Findings that become conditions. Things that do not change whether you proceed but should be fixed, ideally before completion — account ownership, expiring certificates, a licence that needs a decision.

Context. What the system is, how it is built, what shape the team is in. This is what makes the document useful in eighteen months to somebody who was not there.

Method and limits. What was examined, what was not, what could not be verified and why. This section is the one most often omitted and the one that determines whether the report can be trusted.

The convention that matters most

Every statement is marked as verified or reported.

Verified means someone on the review side established it directly: the build was run, the backup was restored, the licence file was read. Reported means the company said so and it was not independently checked.

Both belong in a report. Conflating them is what turns a review into theatre, because a reader cannot tell the difference between a fact and a claim, and will assume the flattering interpretation.

This convention also protects the reviewer. A finding marked reported that later turns out to be false is a finding correctly recorded. The same finding stated flatly is a mistake with your name on it.

What does not belong

A redrawn architecture diagram the company already had. A summary of the interviews. Style observations about the code. Anything phrased as a grade.

The test for including something: would a reader do anything differently because of it. If not, it is padding, and padding trains readers to skim the parts that matter.

Length

Shorter than expected. Ten to twenty pages covers most companies, with the first page standing alone.

Long reports are usually a sign that prioritisation was skipped — everything observed was written down and the reader was left to work out what matters. That is the reviewer’s job, delegated back.

Who owns it afterwards

The report is commissioned by one party and read by several, and it is worth agreeing in advance who may see it.

The company being reviewed usually gets the technical findings and sometimes not the commercial framing. Investors circulate it internally. If the deal does not complete, the document still exists, describing weaknesses in a company that remains in the market.

Two conventions help. Keep the valuation commentary out of the technical report and into a separate note, so the technical document can be shared without sharing the negotiating position. And write every finding as though the subject’s engineering team will read it, because they frequently do — which improves the accuracy of the language and removes the temptation toward rhetorical flourish that would not survive contact with the people who built the thing.

What the document cannot do

It cannot make the decision. It can price a risk and state a confidence level; whether that risk is acceptable depends on the transaction, the alternatives and the appetite of the people involved, none of which is a technical question.

It also cannot cover what was not accessible. Where access was limited, the limits section should say so plainly rather than leaving an absence that reads like a clean bill of health. An unexamined system and a system found sound look identical in a report that omits its own boundaries.

Related reading: the diligence process covers the stages that feed each section, the checklist covers what verification actually involves, and IT due diligence covers the findings that most often end up in the conditions section.