Tech Due Diligence Checklist: What Investors Check

01The technical due diligence process

The technical due diligence process usually runs in four steps: a document request, interviews with the technical team, hands-on review of code and infrastructure, and a written report with findings ranked by risk and the cost to fix them. The checklist below is what the hands-on review covers.

02Tech due diligence checklist: architecture and data

• Is there an up-to-date architecture diagram, and does it match what is deployed?
• How are customers separated: separate installations, or a shared database with a tenant boundary? Does that boundary fail closed? (See single tenant vs multi tenancy.)
• Are the big decisions written down with their reasons, in the order set out in SaaS platform architecture?
• Can the data model support the next two years of the roadmap without a rewrite?
• Which third-party services and APIs is the product dependent on, and what happens if one disappears?

03Security and access control

• Are tenant boundary, permissions and record scope separate layers, each tested? (Multi-tenant access control shows what that looks like.)
• Is there a single registry of permissions, or are checks scattered through the code?
• How are secrets stored, rotated and kept out of the repository?
• When was the last penetration test or security review, and were its findings fixed?
• Does the application meet a recognised baseline such as the OWASP Application Security Verification Standard?

04Code and delivery

• Is all source code in repositories the company owns, with history?
• Is there an automated test suite, does it run on every change, and does it pass?
• How long does it take from a merged change to production, and how is a bad release rolled back?
• Is open-source licensing tracked, and are dependencies up to date?
• How much of the system only one person understands?

05Operations and cost

• Who holds the cloud root accounts, and is access logged and limited?
• Are backups taken, stored separately, and restored in a drill on a schedule?
• Is there monitoring with alerts someone actually answers, and an incident history?
• What does the infrastructure cost each month, and how does that cost grow per customer?
• Does the setup follow a recognised framework such as the AWS Well-Architected pillars?

06Team and process

• Who owns architecture and delivery, and what happens if they leave?
• Is work planned and tracked, and can the team show what shipped last quarter?
• Are contractors and agencies under agreements that assign the code to the company?

07What the technical due diligence report should say

A useful technical due diligence report ranks findings by risk to the deal, estimates the cost and time to fix each one, and separates "must fix before closing" from "plan for in the first year". Findings without a cost are opinions.

If you are the company being reviewed, the cheapest preparation is a few weeks of a CTO going through this list first. That is what the CTO advisory review is for; if the work then needs doing, the Fractional CTO plans cover the fixes as well as the findings. The costs are in fractional CTO rates.