What Technical Due Diligence Actually Involves
Technical due diligence is a systematic assessment of a company's technology assets, risks, and capabilities conducted before an investment, acquisition, or merger. A thorough technical DD examines six domains: code quality and architecture, security posture, scalability and performance, engineering team and processes, intellectual property, and technical debt quantification. This guide gives you the complete checklist used by serious investors — and how to prepare if you're the company being examined.
According to Forrester Research, 35% of acquisitions fail to deliver expected value due to technology integration challenges — many of which would have been visible in a proper technical due diligence. The cost of missing a critical technical risk at deal stage is orders of magnitude higher than the cost of the DD itself.
The Six Domains of Technical Due Diligence
Domain 1: Code Quality and Architecture
What investors examine:
- Code complexity — Cyclomatic complexity, code duplication, and dependency graph analysis. Tools: SonarQube, CodeClimate, or manual review for sample modules.
- Test coverage — Unit test coverage percentage (industry expectation: 70%+ for critical paths), integration tests, and end-to-end test suites. More importantly: are tests meaningful or are they testing trivial code to inflate coverage numbers?
- Architecture documentation — Are there Architecture Decision Records (ADRs)? Is the system design documented? Can the team explain why key decisions were made?
- Dependency health — Are dependencies up to date? Are there abandoned packages or known vulnerable libraries? Tools: npm audit, Snyk, Dependabot alerts.
- Build and deployment consistency — Can the build be reproduced reliably? Are environments consistent? Is there environment drift between dev, staging, and production?
Red flags: No test coverage, spaghetti architecture with no clear service boundaries, major version dependencies 2+ years behind current, no documentation of key architectural decisions.
Domain 2: Security Posture
This domain has become the highest-risk area in modern technical DD. One critical vulnerability or data breach post-acquisition can exceed the entire deal value.
- Authentication and authorisation — How is user authentication implemented? Is there MFA? Is authorisation enforced consistently across all API endpoints?
- Data encryption — Is data encrypted at rest and in transit? What encryption standards are used? Where are encryption keys stored?
- Secret management — Are secrets (API keys, database passwords, certificates) stored in code repositories or environment variables? What's the rotation policy?
- GDPR and data privacy compliance — For European companies, this is non-negotiable. Does the system correctly handle data subject rights (access, deletion, portability)? Where is customer data stored geographically?
- Vulnerability history — Have there been past security incidents? How were they handled? Are CVEs tracked and patched systematically?
- Penetration testing history — When was the last third-party penetration test? What were the findings and have they been remediated?
Red flags: Hardcoded secrets in Git history (even if removed — they've been exposed), no encryption at rest for customer data, GDPR violations that expose the acquiring entity to fines, no security testing in CI pipeline.
Domain 3: Scalability and Performance
- Current capacity — What is the current transaction volume? What's the theoretical ceiling of the current architecture?
- Performance benchmarks — Do performance benchmarks exist? What are the P50/P95/P99 response times for critical user journeys?
- Scalability path — How does the system scale under 5x, 10x, 50x current load? Is it horizontally scalable or constrained by a single-instance database or service?
- Database architecture — Is the database a scaling bottleneck? Are queries optimised? Is there appropriate indexing?
- Infrastructure headroom — Are systems running near capacity? What's the infrastructure cost growth model relative to revenue growth?
Domain 4: Engineering Team and Processes
Technology is built and maintained by people. The team assessment is often as important as the code assessment:
- Team size and composition — How many engineers? What's the seniority distribution? Are there critical single points of failure — people who hold key knowledge?
- Retention risk — What's the historical attrition rate? Are key engineers locked in post-acquisition? What are retention mechanisms?
- Engineering velocity — Deployment frequency, PR cycle time, sprint velocity. Are these tracked? Are they improving?
- On-call and incident management — How are production incidents handled? Is there an on-call rota? Are post-mortems conducted?
- Documentation culture — Is institutional knowledge written down or living only in people's heads?
Domain 5: Intellectual Property
- IP ownership — Does the company own the IP in its software, or do founders/contractors retain ownership? Have all contributors signed IP assignment agreements?
- Open source licensing — Are any GPL-licensed dependencies embedded in the product in ways that could require source disclosure? GPL, AGPL, and copyleft licences need careful review.
- Patent landscape — Are there patents? Could competitor patents constrain the product roadmap?
- Data assets — For AI/ML companies, is the training data owned, licensed, or scraped? What are the usage rights?
Domain 6: Technical Debt Quantification
The question isn't whether there's technical debt — all software has it. The question is: how much, where is it, and what does it cost to service?
- Known debt backlog — Is there a maintained list of known technical debt items? Is it prioritised?
- Annual maintenance overhead — What percentage of engineering capacity goes to maintenance vs new features?
- Remediation cost estimate — What would it cost to address the most critical debt items? This becomes a deal negotiation input.
- Debt growth rate — Is the debt stable, decreasing, or accumulating? A team with no capacity to address debt will compound the problem.
Technical Due Diligence Timeline
A typical technical DD engagement runs:
- Initial document review: 3–5 days (architecture docs, security policies, team org chart)
- Code review and automated analysis: 5–10 days
- Technical interviews with engineering leadership: 2–3 days
- Infrastructure and security assessment: 3–5 days
- Report preparation and findings presentation: 2–3 days
- Total elapsed time: 2–4 weeks for most SaaS companies
How to Prepare for Technical Due Diligence
If you're anticipating an investment or acquisition process, start preparing 6–12 months in advance:
Quick Wins (1–4 Weeks)
- Rotate and remove any exposed credentials from repositories and fix Git history if needed
- Run Dependabot or Snyk and remediate critical and high-severity vulnerabilities
- Document your architecture — even a simple diagram and one-page description of each service
- Create runbooks for your most critical operational processes
Medium-Term Improvements (1–6 Months)
- Implement SAST scanning in your CI pipeline (SonarQube, Semgrep, or CodeQL)
- Write tests for your highest-risk code paths to lift coverage
- Establish Architecture Decision Records for key decisions
- Commission a third-party penetration test and remediate findings
Strategic Preparation (6–12 Months)
- Address your highest-severity technical debt items proactively
- Build and document your engineering processes and on-call practices
- Ensure IP assignment agreements are in place for all contributors
- Establish GDPR compliance documentation if you serve EU customers
Our technical due diligence service works both sides: we help acquirers understand what they're buying, and we help companies prepare for investor scrutiny. If you discover significant technical debt during preparation, our legacy modernization service can address the most critical issues before the deal process begins.
Deal Negotiation: Using Technical Findings
Technical DD findings feed into deal structure in three ways:
- Price adjustment — Significant technical debt or security remediation costs are quantified and reflected in the purchase price.
- Escrow and holdback — Funds held pending resolution of specific technical risks (e.g., GDPR compliance gaps).
- Representations and warranties — Technical findings inform the reps and warranties in the deal agreement, including what happens if undisclosed technical issues emerge post-close.
