Don't Panic — Technical Due Diligence

Technical due diligence is the practice of checking what a technology asset actually is before a consequential decision makes everybody responsible for it. It appears in acquisitions, investments, software purchases, and supplier reviews. The job is not to admire the architecture diagram or issue a ceremonial code-quality score. The job is to replace claims with evidence and explain what the evidence does to the decision.

Begin with the transaction thesis, meaning the value the transaction expects to create. A buyer interested in intellectual property needs evidence about provenance, third-party components, ownership, and transferability. A buyer expecting rapid growth needs capacity, bottleneck, cost, and delivery evidence. A buyer planning integration needs interfaces, identity, data, deployment boundaries, and migration constraints. One checklist cannot decide which of these matters most, despite checklists being naturally convinced of their own importance.

The central mechanism is an evidence chain. A thesis produces a diligence question. The question identifies a claim. Documents, interviews, repository history, pipeline records, runtime observations, and incident evidence test that claim. The result becomes a finding, and the finding earns its place by changing a decision, cost assumption, pre-close requirement, or integration action.

Evidence is annoyingly specialized. A diagram describes intended architecture but may not match deployment. A repository shows source and change history but does not prove which version runs in production. An interview supplies context but remains a claim until something independent supports it. A software bill of materials identifies components and relationships; it does not wave a small wand over them and pronounce the product secure.

This is why material claims need triangulation, or testing through independent evidence paths. Compare the release process with pipeline history and a recent production change. Compare the architecture walkthrough with infrastructure definitions and runtime inventory. Compare stated knowledge ownership with interviews, contribution history, code review, incident command, and operational access. Contradictions are not courtroom drama. They are directions for the next useful question.

Scope follows risk. Inspect the revenue-critical path, privileged and exposed components, expensive infrastructure, high-change areas, recent incidents, and the interfaces named by the thesis. Record every exclusion and access limit. “The reviewed repository” is a defensible phrase. “The platform” is not, when most of the platform remained behind a door the reviewer did not open.

A finding needs an observed condition, a criterion, a consequence, an evidence-confidence statement, and a response. Keep severity separate from confidence. A potentially severe risk with weak evidence calls for more evidence, a condition, or a contingency. It does not call for a louder adjective.

Read the Intro for the complete review architecture. Use the Cheatsheet to structure evidence and findings. The Practice Reference turns a transaction thesis into a scope and evidence register. The Exercise provides a fictional acquisition where unsupported capacity, stale inventory, and concentrated operational knowledge can be handled without jeopardizing an actual deal.

The final report should say what was tested, what was found, why it matters, how certain it is, and what remains unknown. That is less glamorous than predicting the future. It is also considerably more useful.

Don't Panic — Technical Due Diligence

Relevant careers