Technical due diligence (TDD) is an independent review of a company's technology, engineering practices and security, usually done before an acquisition or investment. It asks whether the product works as claimed, can scale, is secure and legally clean, and whether the team can keep building it.
Who does it and why?
The buyer or investor, often with outside engineers, examines what they would own. The aim is to find costs and risks that do not show in a pitch: hidden rewrites, unpatched systems, licence problems, key person dependence. Findings usually change the price, the terms or the post-deal plan, rather than ending the deal.
There is no single legal standard for TDD. Scope is agreed per deal, so treat the lists below as common practice, not a requirement.
What areas do reviewers cover?
Architecture and code. How the system is built, how components depend on each other, how hard it is to change. Reviewers sample code for quality, tests and documentation.
Infrastructure and operations. Hosting, deployment, monitoring, backups, disaster recovery, uptime history and incident records.
Security. Access control, secrets handling, vulnerability management, past incidents, and how the team applies secure development practice. NIST's Secure Software Development Framework (SP 800-218) is a common reference for what good looks like.
Software supply chain and licences. What third party and open source components are used, whether they are current and whether their licences fit the business model. A software bill of materials makes this faster. The NTIA describes the SBOM as a nested inventory of the components that make up software, and published minimum elements for what one should contain.
Data and privacy. What personal data is held, where, under what legal basis, and how it is protected.
People and process. Team structure, hiring, how work is planned, dependence on a few individuals, contractor use.
Product and roadmap. Technical debt, planned work and whether the roadmap is realistic for the team's size.
A constructed example
A buyer reviews a software company with ten engineers. The code is tidy and the product works. But the review finds that one engineer holds the only copy of the deployment scripts, the main database has no tested restore, and an inventory of dependencies shows a framework version that stopped receiving security fixes two years ago. The deal proceeds, with a retention plan for the engineer, a restore test as a closing condition, and a funded upgrade in the first six months.
None of the findings was fatal. All were useful to know before signing.
How should a seller prepare?
Good preparation shortens the process and builds trust.
- Inventory your assets. Systems, repositories, cloud accounts, domains, vendors.
- Produce a dependency list for each product, with versions and licences, and check for known vulnerabilities.
- Collect security evidence. Policies, recent test results, access reviews, incident log.
- Document the architecture in a few diagrams and a one page summary.
- Prove recovery. Run a restore from backup and keep the record.
- Reduce single points of failure. Share knowledge, store secrets in a shared manager, document deployment.
- Be candid. Prepare a short list of known weaknesses with plans. Reviewers find them anyway, and openness helps.
What are common red flags?
A few patterns recur. No one can say which versions of key components are running. Production access is shared through a single login. There is no record of a successful restore. Security fixes wait months. Customer data sits in test environments. Any one can be fixed, but a cluster of them suggests the team lacks time or ownership, which is a finding about the organization, not just the code.
How should a buyer scope it?
Ask what matters most for the deal thesis. If you are buying for the customer base, focus on stability and security. If you are buying for the technology, go deeper on architecture and intellectual property. Set a time box, agree who sees the code under confidentiality, and decide which findings change price versus integration work.
Quick check
How long does technical due diligence take?
It depends on size and scope, from days for a small product to several weeks for a large one. Agree a time box up front.
What is the single most useful document to have ready?
A current dependency inventory (SBOM) alongside an architecture summary. Together they answer many questions quickly.
Sources
- NTIA, Software Bill of Materials
- NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
- OWASP SAMM
Last reviewed: 18 October 2026.
