A technical due diligence checklist for M&A and investment deals, organized by category. Not every item applies to every deal — a pre-seed acqui-hire and a growth-stage platform acquisition need different depth — but this is the full set worth scoping in or explicitly scoping out before an engagement starts.
Security exposure
- Known-vulnerable dependencies with available fixes, and whether any are internet-facing.
- Hardcoded secrets or API keys committed to the repository, including in old commit history.
- Authentication and authorization patterns — session handling, access control on multi-tenant data, admin-panel exposure.
- Whether the same class of vulnerability recurs across many endpoints, which signals a process gap rather than an isolated bug.
Dependency and license risk
- Direct and transitive dependencies under copyleft licenses (GPL, AGPL) inside a proprietary codebase.
- Abandoned or unmaintained dependencies with no recent releases or security patches.
- Version pinning and lockfile discipline — whether builds are reproducible or drift silently.
- Any vendored or copy-pasted third-party code without a clear license.
Technical debt and code health
- Test-coverage estimate on the paths that touch money, auth, and data integrity specifically — not just an aggregate percentage.
- Dead code: files nothing imports and that aren't entry points.
- Duplicate or copy-pasted logic implementing the same business rule in more than one place.
- Whether a CI pipeline actually runs tests and blocks merges on failure, or exists but isn't enforced.
Architecture consistency
- Whether the current architecture can plausibly support the growth plan in the deal thesis, or needs a rewrite to get there.
- Circular dependencies and unclear service boundaries in a monolith or microservice split.
- Database schema design — normalization, indexing, and whether migrations are reversible.
- Single points of failure: one database, one region, one undocumented cron job everything depends on.
Talent concentration (bus-factor) risk
- Commit and code-ownership distribution across the team, not just headcount.
- Whether the person with the most institutional knowledge is contractually committed to stay post-close.
- Documentation quality for the systems the most concentrated owner maintains.
- Recent or pending departures on the core engineering team.
Operational readiness
- Monitoring, alerting, and incident-response practices — is anyone paged when something breaks.
- Backup and disaster-recovery testing, not just backup existence.
- Infrastructure-as-code coverage versus manually configured, undocumented production infrastructure.
- Cost structure of the current infrastructure relative to the growth plan's projected scale.
What a remediation estimate should include
- Engineer-days to remediate each material finding, not just a severity label.
- A dollar range built from that estimate, usable directly in a valuation adjustment.
- A distinction between findings that block closing and findings that are normal post-close cleanup.
See how Audit Bench Ai runs this checklist as an automated engagement →