Technical due diligence
What a due diligence report looks like
The report a buyer's technical reviewer hands to the deal team. Thirteen findings on a fictional multi-tenant SaaS, tiered by treatment: four that warrant attention before close, five that are warranty, escrow or disclosure candidates, three for the post-close backlog, and one IP question escalated to counsel. The tenant boundary was tested by recording one tenant's traffic and replaying it as another, which gives a pass or fail per route. The target is fictional and every finding invented.
Buy-side · Multi-tenant B2B SaaS · NestJS / Next.js / PostgreSQL / AWS
The method behind this report-
What each finding means for the deal
Tier 1 is a material pre-close issue, Tier 2 a warranty, escrow or disclosure candidate, Tier 3 a post-close backlog item. The report names the lever and leaves the outcome to the buyer and counsel. One item, the IP ownership of a core module, sits outside the tiers because no engineering estimate would be honest.
-
A confidence level on every finding
Verified, Observed, Inferred or Unverified, stated per finding and split where one word would mislead: a dependency's presence is Verified against the lockfile while its exploitability stays Unverified. The restore finding is the clearest case. Backup existence is Observed; backup effectiveness is Unverified.
-
What was not reviewed
The scope section lists what the review did not do: no full source audit, no penetration testing beyond proving access, nothing commercial or financial. The isolation result needed only a staging URL and two tenant accounts. Routes those accounts could not reach are listed as open items, not as passes.
From the report, section 3
Tenant Isolation Verification
- Routes discovered
- 47
- Routes exercised
- 38
- Tenant-scoped routes
- 24
- Differential tests
- 112
- Cross-tenant failures
- 3
- Coverage
- 81%
- Result
- FAILED
What a due diligence report looks like
Fictional sample · 9 pages
Isolation must be tested by behaviour, not by presence of guards.