tech_due_diligence v1.0.0

name: "tech_due_diligence" description: "Run technical due diligence on a company or product before an acquisition or major investment: translate the deal thesis into testable claims, review codebase and architecture, infrastructure and security posture, data and IP ownership, and team and key-person risk, then score every finding by deal impact in a report a deal team can price. Use when evaluating a software target, preparing a diligence request list, reviewing a data room, or writing up findings before signing." metadata: { "includeInPrompt": true }

Tech Due Diligence

Purpose

Price the technical risk in a deal before signing, instead of discovering it after close. The work is not a general audit. Every check exists to test a claim the deal depends on: the seller owns the code, the platform can carry the growth plan, the data can be used lawfully, the security posture will not become the buyer problem on day one, and the people who understand the system will still be there.

The output is a findings report where each finding names the claim checked, the evidence inspected, an evidence grade, a score built from impact and exposure, and a remediation estimate in weeks and dollars. That format lets a deal team turn a technical finding into a closing condition, a price adjustment, an escrow, or a funded post-close plan.

Workflow

1. Turn the deal thesis into testable claims. Write five to ten claims in plain sentences, for example "the platform handles ten times current load without a rewrite" or "the seller owns all product code." Each claim gets an owner, a workstream, and the evidence that would settle it. If a claim cannot be tested in the window, say so at the start, not in the final report as a surprise.

1. Send the evidence request before any interviews. Use references/evidence-request-list.md. Ask for artifacts, not summaries: architecture diagrams, read only repo access, CI and deploy records, cloud billing, pen test reports, incident logs, vendor contracts, IP assignments, and a software bill of materials. Log what arrives, what is promised, and what is refused or missing. Missing evidence is recorded, never filled in from testimony.

1. Run the eight workstreams in parallel where staffing allows: architecture, code, security, infrastructure, data, IP, team, and product and vendors. In each one, compare three views of the same system: what the documents say, what the artifacts show, and what the interviews claim. A contradiction between any two is a finding candidate.

1. Review the codebase and architecture against the load and integration claims. Sample the revenue critical paths first: auth, billing, data mutation, and the integrations the deal thesis names. Check test practice on those paths, dependency age and support status, deploy and rollback mechanics, and where a single service, database, or vendor caps growth. Do not report a global coverage number as if it described the critical paths.

1. Assess infrastructure and security with named frameworks, not vibes. Map the posture to the six NIST Cybersecurity Framework 2.0 functions: Govern, Identify, Protect, Detect, Respond, and Recover, and ask for the artifact behind each function. Sample application risk against the OWASP Top 10 2021 categories, starting with A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, A05 Security Misconfiguration, A06 Vulnerable and Outdated Components, and A07 Identification and Authentication Failures. Read the most recent penetration test in full, including what was not fixed. If a SOC 2 report is offered, check its type, its scope, and its exceptions: Type I covers design at a point in time, Type II covers whether controls operated over a period.

1. Check data and IP ownership as legal facts backed by paper. For data: what exists, where it lives, why it is kept, how long it is retained, which subprocessors touch it, and how export and deletion work for a departing customer. For IP: a signed assignment from every employee, contractor, agency, and founder who wrote code. For open source: a current SBOM in SPDX or CycloneDX format carrying the NTIA minimum fields per component (supplier name, component name, version, unique identifier, dependency relationship, SBOM author, timestamp), then a licence pass with special attention to strong copyleft in anything distributed, components with no licence, and custom licence terms.

1. Map team and key person risk from records, not introductions. Build a knowledge map: for each core system, who can deploy it, debug it, and change it safely. Any system with one name in all three columns is a finding. Cross-check with deploy history, on-call rotas, and code review records. Record retention risk only where evidence supports it, and grade it honestly.

1. Interview after reading the documents, in the order in references/interview-and-scoring-guide.md: technical lead, senior engineers without their manager, security owner, product lead, then founder or CEO last with the sharpest contradictions in hand.

1. Score every material finding and build the report with the tool. Put findings in a CSV with the columns the tool documents, then run it:

python3 bin/score_findings.py findings.csv --out report.md

Score is impact (1 to 5) times exposure (1 to 5). Bands: 20 to 25 Blocker, 12 to 19 Deal term, 6 to 11 Post-close, 1 to 5 Monitor. Grade evidence A (inspected directly) through D (unverified). The tool flags Blocker and Deal term findings graded C or D as low confidence, and totals remediation weeks and cost by band. The worked example in references/worked-example.csv produces references/worked-report.md: one Blocker, four Deal term findings, 33 remediation weeks, and $330,000 total estimated cost for a fictional target.

1. Close with deal language, not just findings. For each Blocker, name the closing condition and the artifact that proves the fix. For each Deal term finding, name the price adjustment, escrow, warranty, or indemnity it supports, tied to its remediation estimate. For Post-close findings, name the owner and the date in the first 90 day plan. State the loaded engineering rate used for cost estimates in the report.

Output Contract

Every engagement ships one findings report containing:

• Deal thesis and the claim list, with each claim marked verified, contradicted, or unverified, and its evidence grade.
• Evidence log: what was requested, what was received and inspected, what was missing, and what was refused.
• Findings table from bin/score_findings.py: ID, title, workstream, impact, exposure, score, band, evidence grade, remediation weeks, and cost.
• Detail per finding: claim checked, evidence inspected, and the exact request that would settle any grade C or D item.
• Band totals for remediation weeks and cost, plus a verdict line: proceed, proceed with terms, or conditional with Blockers named.
• Deal recommendations: closing conditions, price or escrow items, and the funded post-close list with owners and dates.
• Open questions section listing every unverified claim as a question, never as a finding of fact.
• A short limits note: what was out of scope, what could not be tested in the window, and what a full audit or penetration test would still need to cover.

Operating Rules

1. Evidence beats testimony. A claim with no artifact behind it is grade C at best, and a claim whose artifact was never produced is grade D. Write both as unverified, not as true or false.
2. Never invent numbers. Remediation estimates come from the people who would do the work, costed at a stated rate. Market figures, breach statistics, and benchmark bands that you cannot source do not go in the report.
3. Keep the worst findings visible. Do not average scores into a single health number that dilutes a Blocker with minor passes.
4. A certification is an input, not the review. Read its scope and exceptions, then still sample the code, the access list, and the incident log yourself.
5. Stay inside diligence scope. You are pricing risk inside a deal window, under NDA, with read only access unless the engagement says otherwise. Do not run intrusive tests, access personal data beyond what the review needs, or contact the target customers or staff outside the agreed sessions.
6. Separate fact, inference, and opinion in the report. Facts cite evidence. Inferences say what they rest on. Opinions are labelled as judgement. A grade D item appears only as an open question.
7. Flag legal questions for counsel instead of deciding them. Licence obligations, assignment validity, and data protection duties get a technical finding plus a referral, not a legal conclusion.
8. Protect the material. Findings, code samples, and reports stay in the deal data room or the buyer system the engagement names. Nothing from a target review goes into public posts, examples, or other engagements, even anonymised, without written permission.