Technical Due Diligence Checklist: What Investors and Acquirers Check
This is general information, not legal advice. Have a qualified lawyer review IP, licensing and contract questions for your specific deal.
Technical due diligence answers one question: will this technology and team support the business plan, and what will it cost to fix what does not? A solid review covers eight areas: product and architecture, code quality, security, infrastructure and operations, data and privacy, intellectual property and open-source licences, the team, and delivery practices. Use the checklist below whether you are the investor running the review or the founder preparing for it.
Key takeaways
- Ownership comes first. If the company does not clearly own its code, accounts and IP, nothing else matters until that is fixed.
- Security reviews follow known risk lists. The OWASP Top 10:2025 puts Broken Access Control first, followed by Security Misconfiguration and Software Supply Chain Failures.
- Key-person risk is a technical risk. One engineer holding all the knowledge is a valuation issue.
- Delivery metrics reveal health. DORA's metrics (change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate) show how safely a team ships.
- Candor wins. A documented list of known debt with a plan reads far better than a surprise finding.
How a technical due diligence engagement runs
- Scope. Agree what is in scope (products, repositories, infrastructure), the depth (high-level versus code-level), and the deadline.
- Data room. The company shares architecture diagrams, policies, org chart, vendor list, incident history and read-only access to repositories and cloud consoles.
- Interviews. Sessions with the CTO, lead engineers, and often product and security owners.
- Hands-on review. Code sampling, automated scans (dependencies, secrets, licences), infrastructure configuration review and, if needed, a penetration test.
- Findings. Each issue gets a severity, business impact and estimated cost or time to fix.
- Report and remediation plan. Red flags that affect the deal, items to fix before close, and items for the 100-day plan.
The technical due diligence checklist
1. Product and architecture
- [ ] Current architecture diagram (services, databases, third-party dependencies, data flows)
- [ ] Rationale for major technology choices recorded (architecture decision records)
- [ ] Scalability limits known and tested against the business plan's growth
- [ ] Single points of failure identified
- [ ] Third-party services that are critical to operations listed, with contracts and fallbacks
- [ ] Product roadmap feasibility with the current architecture
See choosing a tech stack for a startup for what reviewers expect to find in a well-reasoned stack.
2. Code quality and maintainability
- [ ] All code in company-owned repositories with history intact
- [ ] Code review required before merging to the main branch
- [ ] Automated tests exist for critical paths, and they run in CI
- [ ] Build and deploy are reproducible from documentation
- [ ] Dependency versions reasonably current; end-of-life frameworks identified
- [ ] Known technical debt documented with severity and plan (see technical debt explained for founders)
- [ ] No large blocks of copied code with unknown origin
3. Security
- [ ] Review against the OWASP Top 10:2025 categories, especially access control, misconfiguration and supply chain
- [ ] No secrets (API keys, passwords, tokens) in code or repository history
- [ ] MFA enforced on source control, cloud, email and admin tools
- [ ] Least-privilege access; former staff and contractors removed
- [ ] Dependency vulnerability alerts enabled (for example, GitHub Dependabot alerts) and triaged
- [ ] Recent penetration test or security assessment, with fixes tracked
- [ ] Incident response plan and history of past incidents
- [ ] Compliance reports where customers require them (for example, a SOC 2 report based on the AICPA Trust Services Criteria)
4. Infrastructure and operations
- [ ] Cloud accounts owned by the company, with billing in the company's name
- [ ] Infrastructure defined as code, or at least documented
- [ ] Backups automated, encrypted and restore-tested within the last quarter
- [ ] Monitoring, alerting and on-call responsibilities defined
- [ ] Uptime and incident history for the past 12 months
- [ ] Hosting costs per month and per customer understood
- [ ] Disaster recovery targets (how much data loss and downtime is acceptable) defined
5. Data and privacy
- [ ] Data inventory: what personal or sensitive data is collected, where it is stored, who can access it
- [ ] Data residency matches customer contracts and applicable laws
- [ ] Encryption in transit and at rest
- [ ] Retention and deletion processes
- [ ] Data processing agreements with vendors that handle personal data
- [ ] For health, financial or children's data: the relevant regulatory controls documented
6. Intellectual property and open source
- [ ] Signed IP assignment or work-for-hire agreements from every founder, employee and contractor who wrote code
- [ ] Domains, trademarks, app store accounts and social handles owned by the company
- [ ] Open-source licence scan completed; copyleft licences (such as GPL or AGPL) reviewed for how the code is used and distributed
- [ ] Commercial licences and API terms allow the planned use and any change of control
- [ ] AI-generated code policy and provenance understood
7. Team and organization
- [ ] Org chart with roles, tenure and location
- [ ] Key-person dependencies identified and mitigated (documentation, pairing, cross-training)
- [ ] Contractor and agency relationships, contracts and handover obligations
- [ ] Hiring plan aligned with the roadmap
- [ ] Engineering culture signals: code review, on-call fairness, documentation habits
8. Delivery practices
- [ ] Sprint or planning cadence and how priorities are set (see how to run engineering sprints in a small team)
- [ ] DORA metrics, or reasonable proxies: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate
- [ ] Release process and rollback capability
- [ ] Bug backlog size and age
- [ ] Customer-reported incidents and time to resolve
Rating findings: a simple severity table
| Severity | Meaning | Typical examples | Deal impact |
|---|---|---|---|
| Critical | Could stop the deal or require price change | Company does not own core IP; customer data exposed; key systems in a departed contractor's account | Fix before close or restructure terms |
| High | Material cost or risk within 6 months | Unpatched known vulnerabilities; no tested backups; single engineer holds all knowledge | Fix before close or escrow/holdback |
| Medium | Slows the roadmap | Outdated framework versions; thin test coverage on key paths | 100-day plan |
| Low | Normal hygiene | Inconsistent code style; incomplete docs | Backlog |
A minimal technical data room
Put these in one shared folder before reviewers ask. It signals maturity and saves days:
- Architecture diagram and a two-page system overview
- List of repositories, with owners and what each contains
- Cloud accounts, regions and a summary of monthly infrastructure costs
- Third-party vendors and APIs, with contracts or terms links
- Security policies, MFA status, last penetration test summary and fix status
- Incident log for the past 12 months with root causes
- Backup policy and the date and result of the last restore test
- Open-source licence scan output and dependency audit
- Signed IP assignment agreements for all code contributors
- Org chart, contractor list and the technical debt register
What founders should do 90 days before fundraising or a sale
- Run a self-assessment using this checklist and be honest about gaps.
- Fix ownership issues first: move repositories, cloud accounts, domains and app store listings to company-controlled accounts; collect missing IP assignments.
- Scan and clean: dependencies, licences, and secrets in repository history.
- Turn on MFA everywhere and remove stale access.
- Test a restore from backup and write down how long it took.
- Document the architecture with one diagram and a two-page overview.
- Write the debt register: known issues, impact and plan.
- Prepare the data room so reviewers spend time on substance, not access requests.
From experience: Across consulting work with founders in the US, UAE and Malaysia, the findings that cause real friction are rarely about clever code. They are about who owns what: a repository under a freelancer's personal account, a domain registered by a former agency, or cloud billing on a founder's personal card. These take days to fix calmly and weeks to fix under deal pressure.
Questions reviewers will ask the CTO
- What would break first if usage grew ten times next quarter?
- What is the riskiest part of the system, and why has it not been fixed?
- How do you know when production is broken, and how fast do you respond?
- Who could rebuild the deployment pipeline if you were unavailable for a month?
- Which vendors could hurt you most by changing price or terms?
- What would you rewrite with six months and no feature pressure?
Prepare clear, specific answers. Vague answers create more questions.
Next steps
- Download or copy the checklist above into a shared document and assign an owner to each section.
- Fix ownership and access issues this week; they are the cheapest red flags to remove.
- Run automated scans for dependencies, licences and secrets, and record results.
- Write a one-page technical debt register with severity and cost to fix.
- If you want an independent review before investors run theirs, see our technical due diligence service.
Sources
- OWASP Top 10:2025: https://owasp.org/Top10/2025/
- DORA's software delivery performance metrics: https://dora.dev/guides/dora-metrics-four-keys/
- GitHub Docs, About Dependabot alerts: https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts
- AICPA & CIMA, SOC 2 resources: https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2
- GNU licences FAQ (GPL and AGPL): https://www.gnu.org/licenses/gpl-faq.html
Frequently asked questions
What is technical due diligence?
Technical due diligence is a structured review of a company's technology before an investment, acquisition or major partnership. It examines architecture, code quality, security, scalability, intellectual property, open-source licences, the engineering team and delivery practices. The goal is to find risks that affect valuation or integration, and to estimate what it will cost to fix them.
How long does technical due diligence take?
For an early-stage startup, a focused review often takes one to three weeks, depending on codebase size, access and how organized the company's documentation is. Larger acquisitions take longer and may involve several specialists. Preparing a data room with diagrams, policies and access in advance can shorten the process considerably.
What are the biggest red flags in technical due diligence?
Common serious findings include code or accounts owned by a contractor rather than the company, missing IP assignment agreements, copyleft licence conflicts, hardcoded secrets in the repository, no backups or untested restores, a single engineer who understands critical systems, and known security vulnerabilities left unpatched. Most are fixable if found early.
How should a startup prepare for technical due diligence?
Confirm the company owns all code, domains and cloud accounts; collect signed IP assignment agreements from every contributor; run a dependency and licence scan; remove secrets from code; document the architecture; enable MFA everywhere; and write down known technical debt with a plan. Being candid about weaknesses builds more trust than hiding them.
Who performs technical due diligence?
Investors and acquirers usually hire an independent technical advisor, a specialist firm or an experienced CTO to perform it, sometimes alongside security testers and IP lawyers. Startups can also commission a 'pre-diligence' review on themselves before fundraising, so they can fix issues on their own timeline rather than under deal pressure.