Introduction
Technology due diligence is one of the most complex parts of any deal process. It covers architecture, code quality, security, team capability, technical debt, infrastructure, and a range of operational risks that do not always surface in a financial or legal review.
This checklist is designed for PE deal teams, VC investors, and corporate acquirers running a buy-side tech DD process. It will not replace a proper assessment by an experienced reviewer, but it gives you a structured starting point and helps you know what to ask.
Work through it in sections. Not every item will be relevant to every deal, but anything you skip should be a conscious decision, not an oversight.
1. Architecture and Infrastructure
Codebase and System Design
- What languages, frameworks, and versions are in active use?
- Is the architecture monolithic, microservices, or hybrid? What is the rationale?
- How modular is the codebase? Can components be updated or replaced independently?
- Are there documented architectural decision records (ADRs)?
- What does the data model look like? Is it well-structured or has it grown organically without governance?
- How is the codebase versioned? Is there a clear branching strategy?
Infrastructure and Hosting
- Where is the application hosted? Cloud (AWS, GCP, Azure), on-premise, or hybrid?
- Is infrastructure defined as code (Terraform, Pulumi, CDK)?
- What are the uptime and availability requirements, and how are they met in practice?
- Is there auto-scaling configured? Has it been tested?
- What are the disaster recovery procedures? When were they last tested?
- What are the RTO (Recovery Time Objective) and RPO (Recovery Point Objective) commitments?
Third-Party Dependencies
- What third-party services and APIs does the product depend on?
- Are there any single points of failure in the dependency chain?
- Are dependency contracts in place? What are the exit provisions?
- Are open-source licences reviewed and tracked? Any GPL or AGPL components that create licensing obligations?
2. Code Quality and Technical Debt
Code Quality
- When was the last independent code review conducted?
- What automated code quality tools are in use (linting, static analysis)?
- What is the test coverage? Are tests meaningful or checkbox-driven?
- Are there documented coding standards and are they enforced?
- How is code reviewed before it reaches production?
Technical Debt
- Does the team have a documented understanding of their technical debt backlog?
- What legacy components exist, and what is the plan (or absence of plan) for them?
- Are there deprecated dependencies or end-of-life runtime versions still in production?
- Has technical debt been quantified in any way? (Story points, estimated remediation cost, etc.)
- Is there a pattern of deferred maintenance, or does the team actively manage technical health?
This is often where the real risk sits. A team that cannot articulate their technical debt probably has not managed it well.
3. Security
Application Security
- When was the last penetration test conducted, and by whom?
- Have any critical or high findings from past pentests been remediated?
- Is there a vulnerability disclosure or responsible disclosure policy?
- Is input validation and output encoding applied consistently?
- Are there protections against OWASP Top 10 vulnerabilities?
Access and Identity
- Is multi-factor authentication enforced for all internal and admin access?
- How is privileged access managed? Are there standing admin accounts?
- Is role-based access control (RBAC) in place across internal systems?
- How are API keys and secrets managed? (Environment variables, secrets manager, or worse, hardcoded?)
- Are employee offboarding procedures tested and enforced?
Compliance and Data
- What personal or sensitive data does the system process or store?
- Is the organisation compliant with GDPR or other applicable data protection regimes?
- Is data encrypted at rest and in transit?
- Has a Data Protection Impact Assessment (DPIA) been completed where required?
- What is the data retention and deletion policy?
4. Engineering Team and Capability
Team Structure
- How many engineers are there, and how are they split across disciplines (frontend, backend, data, devops)?
- What is the seniority profile? Is there over-reliance on one or two key individuals?
- Who are the key technical dependencies? What is the bus factor?
- What is the team's tenure? High turnover is often a leading indicator of broader problems.
Processes and Culture
- What development methodology is in use (agile, kanban, other)?
- How does work get prioritised? Who has authority over the technical roadmap?
- Are sprint cycles or release cadences predictable?
- How are incidents managed? Is there a documented incident response process?
- What is the relationship between engineering and product/business leadership?
Recruitment and Retention
- Are there any open roles that have been vacant for six months or more?
- What is the average time to hire for engineering roles?
- Are there any non-compete or IP assignment issues that could affect key hires leaving?
5. Product and Scalability
Product Maturity
- What is the current release cadence? How often does new functionality reach production?
- Is there a product roadmap? Is it owned and maintained, or aspirational?
- How is the product validated against user needs? Is there a feedback loop?
- What is the ratio of new feature work to maintenance and remediation?
Scalability
- Has the system been load-tested? At what scale?
- What are the performance bottlenecks, and are they understood?
- What would it take to support 2x, 5x, or 10x current user load?
- Is there capacity headroom in the current infrastructure, or is the system already under strain?
Integrations
- What integration touchpoints exist with customer or partner systems?
- Are integrations brittle (custom, undocumented) or standardised (REST, webhook, iPaaS)?
- What happens when an integration fails? Are there alerting and retry mechanisms?
6. Operational Practices
Monitoring and Observability
- Is there centralised logging? Are logs searchable and actionable?
- What metrics are monitored? Is alerting configured on meaningful thresholds, or just defaults?
- Is there application performance monitoring (APM) in place?
- Can the team identify the root cause of a production incident within a reasonable timeframe?
Deployment and CI/CD
- Is there a continuous integration pipeline? Does it run on every commit?
- Are deployments automated or manual?
- How long does a deployment take from commit to production?
- Are there staging or pre-production environments that mirror production?
- Is there a rollback mechanism?
Documentation
- Is there up-to-date technical documentation for the system?
- Are runbooks in place for common operational tasks?
- Is the onboarding documentation sufficient to bring a new engineer up to speed quickly?
7. Commercial and Contractual Technology Risks
IP Ownership
- Does the company own the IP outright, or are there third-party claims?
- Have all contractors and agencies assigned IP to the company?
- Are there any white-label or OEM relationships that affect IP ownership?
Licensing
- Are all software licences accounted for and appropriately scoped?
- Are there vendor contracts with price escalation or auto-renewal clauses?
- Are there technology dependencies tied to the founders personally?
Technology Costs
- What is the current monthly cloud spend? How does it scale with revenue?
- Are there cost anomalies or inefficiencies in the infrastructure bill?
- What are the technology cost projections at 2x and 5x scale?
How to Use This Checklist
Not every item carries equal weight. The priority you assign will depend on the deal thesis, the sector, and the specific risk profile of the target.
A few principles worth keeping in mind:
Absence of documentation is a signal. It usually means practices are not standardised. That is not always fatal, but it raises the question of what else has not been thought through.
Talk to the team, not just the CTO. How engineers describe their own codebase is often more revealing than the prepared pitch. If they are embarrassed, or if they are protective, both are worth understanding.
Ask what they would fix first. Any honest technical leader has a list. If they cannot name it, that is a problem.
Quantify where you can. Gut feel matters, but where possible, get to numbers. How many open security findings? What is the estimated remediation cost for the technical debt backlog? How many hours of downtime in the last 12 months?
When to Bring in External Help
This checklist covers the right questions. Getting reliable answers, and knowing what to do with them, often requires independent review.
If you are evaluating a complex or high-value target, a dedicated tech DD engagement will typically surface issues that are not visible in management presentations or data room documents. It also gives your IC a cleaner, more defensible view of technology risk.
TechDD provides buy-side technology due diligence for PE and VC transactions. If you are working on a deal and want an independent view of the technology stack, get in touch.
FAQ
What should a technology due diligence checklist cover?
A technology due diligence checklist should cover architecture and infrastructure, code quality and technical debt, security and compliance, engineering team capability, product scalability, operational practices, and commercial and contractual technology risks.
How do I assess technical debt during due diligence?
Ask whether the team has a documented technical debt backlog, whether debt has been quantified in any way, and whether there is a pattern of deferred maintenance. A team that cannot articulate their technical debt probably has not managed it well.
What security questions should I ask during tech DD?
Key security questions include when the last penetration test was conducted, whether critical findings have been remediated, how secrets and API keys are managed, whether MFA is enforced, and what the data retention and GDPR compliance status is.
How do you assess engineering team quality during due diligence?
Look at seniority profile, key-person dependency (bus factor), team tenure, development methodology, and how engineering relates to product and business leadership. Also ask whether there are long-vacant roles and what the average time to hire is.
When should I bring in external help for technology due diligence?
For complex or high-value targets, an independent tech DD engagement will surface issues that are not visible in management presentations or data room documents. It gives investment committees a cleaner, more defensible view of technology risk.