Technical Due Diligence Evidence Checklist
Use this register to turn technical due diligence questions into traceable evidence requests. It records what exists, who owns it, what could be verified, what remains uncertain, and why that uncertainty matters to the investment thesis.
A checklist is not a conclusion. A document can be current, obsolete, incomplete, or contradicted by the operating system. Review evidence read-only where possible, record its date and source, and distinguish “not provided” from “does not exist”. Legal, privacy, tax, and specialist security questions should be interpreted by appropriately qualified advisers.
Investor request
Start with the investment thesis, request only evidence that could affect it, and agree the materiality threshold before the data-room review. Record limitations so an unavailable item does not silently become a reassuring assumption.
Founder readiness
Run the same register before a process begins. Assign an evidence owner, remove obsolete files, document genuine gaps, and prepare a concise explanation of remediation already under way. Do not manufacture policies or backdate evidence.
Target and transaction[company / deal stage]
Investment thesis[the product, growth, margin, or integration assumptions technology must support]
Review owner and deadline[name / date]
Materiality threshold[financial, operational, regulatory, or timing threshold]
Access protocol[read-only accounts, approved data room, interview rules, confidentiality limits]
- Evidence owner, reviewer, data-room location, source date, and review date.
- Status: not requested, requested, provided, verified, superseded, unavailable, or not applicable.
- Confidence: high, medium, or low—with the evidence and limitation that justify that judgement.
- Observed fact, management statement, reviewer inference, and unresolved question kept separate.
- Investment-thesis relevance, plausible exposure, remediation owner, target date, and decision trigger.
| Question to resolve | Evidence to request | Decision relevance |
|---|---|---|
| Can the current architecture support the investment thesis and expected growth? | Current architecture diagram, system inventory, data flows, capacity tests, and 12-month product roadmap. | Tests whether growth depends on a bounded improvement or a costly structural change. |
| Where are the known constraints and failure points? | Incident history, post-mortems, error trends, performance reports, and the current technical debt register. | Shows which constraints could interrupt revenue, delivery, or the value-creation plan. |
| Question to resolve | Evidence to request | Decision relevance |
|---|---|---|
| Does the company control the code and can the team change it safely? | Read-only repository access, ownership records, branch protections, build instructions, test results, and release history. | Tests control, reproducibility, change risk, and reliance on undocumented knowledge. |
| Is delivery performance visible and repeatable? | Deployment frequency, lead time, failed deployment rate, rollback records, backlog ageing, and release approvals. | Indicates whether the roadmap assumptions are achievable with the current operating model. |
| Question to resolve | Evidence to request | Decision relevance |
|---|---|---|
| Is production operated with recoverable, observable infrastructure? | Cloud account inventory, infrastructure configuration, monitoring coverage, backup policy, restore-test evidence, and continuity plan. | Identifies interruption exposure and the cost of reaching an acceptable recovery position. |
| Who can access or change production? | Access lists, privileged roles, joiner/leaver records, change logs, secrets management, and emergency-access procedure. | Tests operational control and whether access risk is concentrated in one person or supplier. |
| Question to resolve | Evidence to request | Decision relevance |
|---|---|---|
| Which material security risks are known, tested, and owned? | Risk register, recent assessment or penetration-test scope and remediation, vulnerability trends, and incident-response exercise. | Separates verified control gaps from generic security concern and connects them to likely exposure. |
| Are core controls operating rather than merely documented? | Samples for MFA, patching, endpoint protection, logging, access review, secure development, and supplier review. | Tests whether stated controls reduce risk in practice and what remediation must enter the deal plan. |
| Question to resolve | Evidence to request | Decision relevance |
|---|---|---|
| What data is held, where does it move, and on what basis is it processed? | Data inventory, flow map, retention schedule, processing records, privacy notices, and deletion procedure. | Reveals data obligations, inaccessible stores, and constraints on product or market expansion. |
| Are processors, transfers, and customer commitments known? | Processor list, relevant agreements, transfer mechanism records, customer security terms, and open privacy requests or disputes. | Identifies contractual or operational exposure requiring specialist legal interpretation. |
| Question to resolve | Evidence to request | Decision relevance |
|---|---|---|
| What does the platform cost today and what makes that cost change? | 12–24 months of cloud, software, contractor, support, and licence spend with usage and revenue drivers. | Tests margin assumptions and distinguishes growth cost from waste or deferred maintenance. |
| Which near-term commitments or replacements are unavoidable? | Renewal calendar, minimum commitments, end-of-life systems, migration estimates, and approved or deferred investment. | Surfaces cash requirements that belong in valuation, integration, or the first 100-day plan. |
| Question to resolve | Evidence to request | Decision relevance |
|---|---|---|
| Can the current team operate and evolve the platform? | Organisation chart, role responsibilities, tenure, open positions, on-call ownership, skills map, and roadmap allocation. | Tests whether execution depends on hiring, retention, or a change in leadership capacity. |
| Where is knowledge concentrated? | Bus-factor assessment, documentation coverage, ownership by system, recent handovers, and critical-person dependency interviews. | Identifies continuity and integration exposure hidden by a simple headcount view. |
| Question to resolve | Evidence to request | Decision relevance |
|---|---|---|
| Which suppliers are operationally critical and how can those relationships change? | Supplier register, contracts, service levels, renewal and termination terms, subcontractors, and exit or migration plans. | Tests lock-in, concentration, change-of-control constraints, and replacement cost. |
| Does the company have documented rights to the technology it relies on? | Employment and contractor IP terms, code provenance, open-source inventory, licence review, domain ownership, and software assignments. | Flags ownership questions for qualified legal review before they become a transaction or integration problem. |
Question and workstream[reference the request above]
Verified evidence[source, date, location, and reviewer]
Finding[one observed fact; keep inference separate]
Status and confidence[status / high, medium, or low / reason]
Limitation[missing access, sample size, age, conflicting evidence, or scope boundary]
Thesis relevance[which investment assumption could change]
Estimated exposure[range, timing, operational effect, and calculation basis—not a generic red/amber/green score]
Action and owner[pre-close condition, price or term input, 100-day action, accept, or investigate further]
- List the evidence that was requested but unavailable and the decisions it limits.
- Separate confirmed exposure from plausible scenarios and show the calculation basis for each range.
- Map material findings to a pre-close condition, deal term, 100-day action, accepted risk, or further test.
- Name the owner, funding, deadline, and proof required to close each action.
- Convert the material findings into one short decision memo rather than forwarding the raw register.
This register supports an evidence-led review; it is not legal, financial, privacy, or security advice. See the technical due diligence review or turn the findings into a technical audit decision memo.