Tech Due Diligence Checklist: 50 Questions Every PE Buyer Should Ask

The acquisition looks clean on paper. The commercial due diligence is positive, the financials reconcile, and the management team presents well. Then, somewhere in the first quarter post-close, the technical surprises start arriving. A mountain of undocumented technical debt that doubles the integration timeline. A single engineer who holds all the production knowledge — and hands in their notice on Day 3. An open-source licence buried in the core product that creates copyleft obligations nobody disclosed. Each of these is real, each has happened on deals I have worked on, and each was discoverable before signing heads of terms.

Technical due diligence is not a formality. It is the process that determines whether the technology you are acquiring is an asset or a liability — and whether the price reflects reality. Yet most PE buyers either skip it entirely, delegate it to the management team being acquired (who have every incentive to minimise issues), or commission a surface-level review that checks boxes without uncovering material risks.

This tech due diligence checklist is the 50-question framework TechLevity uses across PE engagements in the UK and EU. It covers seven categories: technology stack and architecture, security and compliance, technical debt and code quality, team and key-person dependency, infrastructure and DevOps, intellectual property and licensing, and integration and migration risk. Every question is designed to surface a specific category of deal risk — the kind that does not appear in a financial model but determines whether the acquisition thesis survives contact with reality.

If you are evaluating a technology acquisition, use this checklist before signing heads of terms. If you have already signed, use it to structure your pre-close verification. If you are post-close and discovering surprises, use it to scope the remediation.

How to Use This Checklist

Each question has a Yes or No answer. Flag every "No" or "Don't know" as a red flag requiring independent verification — not management self-attestation. A management team presenting their own technology for sale is not a reliable source of technical risk assessment, any more than a vendor would be a reliable source of product criticism.

Colour-band your findings using the scoring framework in the final section of this checklist. We recommend the assessment is conducted by someone independent of the deal team — ideally a technical assessor who has no commercial interest in the transaction completing.

Technology Stack & Architecture

1. Are all production frameworks and languages on actively maintained LTS versions?

Unsupported frameworks introduce unpatched CVEs that the acquirer inherits on Day 1.

1. Have all direct dependencies been reviewed for end-of-life or abandoned status in the past 12 months?

Abandoned dependencies are invisible liabilities until they break in production or introduce a supply-chain vulnerability.

1. Is the production environment cloud-hosted with documented architecture diagrams?

On-premise or undocumented hosting significantly increases integration complexity and migration cost.

1. Is the system multi-tenant, and if so, is tenant data isolation formally documented and tested?

Multi-tenancy without verified isolation is a data breach waiting to happen — and a regulatory liability post-acquisition.

1. Has the system been load-tested to 3× current peak traffic within the past 12 months?

Growth assumptions in the deal model are meaningless if the platform cannot handle the projected load.

1. Is there a complete, up-to-date API specification (OpenAPI or equivalent) for all external-facing endpoints?

Undocumented APIs are a hidden integration cost — you cannot plan a migration around endpoints you do not know exist.

1. Are all third-party SaaS integrations inventoried with contractual continuity confirmed?

Change-of-control clauses in vendor contracts can terminate critical integrations on close.

1. Is there a defined architecture decision record (ADR) process or equivalent?

ADRs indicate engineering maturity; their absence suggests decisions live in people's heads — a key-person risk.

Security & Compliance

1. Has an independent penetration test been conducted within the past 18 months, with findings documented and remediated?

Self-assessed security is not security. Independent pen-test reports are the minimum evidentiary standard.

1. Does the company hold a current SOC 2 Type II report, ISO 27001 certification, or equivalent?

Certification gaps post-acquisition can block enterprise sales and trigger contract renegotiations with existing customers.

1. Has a GDPR Data Protection Impact Assessment (DPIA) been completed for AI features and high-risk data processing activities?

Required under GDPR for high-risk processing; our AI governance programme can support the assessment.

1. Is there a documented history of data breaches or security incidents, and were regulatory notifications made as required?

Undisclosed breaches with outstanding regulatory notification obligations are a deal-breaker — the liability transfers on close.

1. Are secrets (API keys, credentials, certificates) managed via a dedicated secrets manager — not hardcoded in source or stored in environment files?

Hardcoded secrets in source control are a breach vector that requires immediate remediation and full credential rotation.

1. Is role-based access control (RBAC) implemented with least-privilege principles across all production systems?

Shared admin credentials or overly permissive access is a compliance failure and an insider-threat surface.

1. Have third-party vendors with data access been reviewed for security posture in the past 12 months?

Supply-chain risk extends to every vendor with access to production data — their breach is your breach.

1. Is there a tested incident response plan with defined RTO and escalation paths?

An untested incident response plan is functionally equivalent to having no plan — the first real incident will prove it.

Technical Debt & Code Quality

1. Has the engineering team produced a technical debt backlog with estimated remediation cost expressed as a percentage of annual engineering budget?

If engineering cannot quantify their debt, the acquirer cannot price it — and unpriced debt becomes a post-close surprise.

1. Does the codebase have automated test coverage ≥60% on business-critical paths?

Low test coverage on critical paths means every integration change carries unquantified regression risk.

1. Is the deployment frequency ≥1 per week, with evidence of automated deployment pipelines?

Infrequent deployment indicates manual processes, fear of breakage, or both — each adds cost to integration.

1. Is the change failure rate (percentage of deployments causing incidents) documented and below 15%?

A high change failure rate signals fragile architecture or insufficient testing — both are expensive to remediate.

1. Is the mean time to recovery (MTTR) from production incidents under 4 hours, with evidence?

MTTR above 4 hours on a revenue-generating system represents direct financial exposure the deal model should account for.

1. Is there a formal code review process requiring at least one independent reviewer before merge to main?

No code review means no quality gate — a single developer can introduce defects or security vulnerabilities unchecked.

1. Is static analysis tooling (SAST) integrated into the CI pipeline, with critical findings blocking deployment?

SAST in CI is a baseline expectation for any production system handling customer data.

Team & Key-Person Dependency

This section is where most integrations fail. Technology can be refactored, debt can be remediated, but losing the people who understand the system is an unrecoverable event on a compressed timeline.

1. Is the system bus factor ≥3 — meaning at least 3 engineers have sufficient knowledge to maintain each production system without the others?

A bus factor of 1 on any mission-critical system is a deal-breaker. A bus factor of 2 is a material risk requiring a retention plan.

1. Is production architecture and operational runbook documentation complete enough for an engineer joining Day 1 to respond to a production incident without asking another team member?

Documentation that requires tribal knowledge to interpret is not documentation — it is a key-person dependency with extra steps.

1. Is there a documented knowledge transfer plan for the 5 engineers rated highest knowledge risk?

Knowledge transfer that is not scheduled and tracked will not happen — especially under the operational pressure of an integration.

1. What percentage of the engineering team are contractors or freelancers — and are their contracts assignable post-acquisition?

Non-assignable contractor agreements can terminate on change of control, creating an immediate capacity gap.

1. For the 5 engineers rated highest flight risk, is there a signed retention plan covering at least 12 months post-close?

Retention plans must be signed pre-close; post-close retention conversations happen under duress and produce worse outcomes.

1. Is the on-call rotation staffed by ≥3 engineers who have each handled a production incident independently?

A thin on-call rotation means one resignation creates a 24/7 operational gap with no fallback.

1. Is there a documented succession plan for the CTO or equivalent technical lead?

CTO departure without succession planning is the single highest-impact personnel risk in a technology acquisition.

TechLevity provides M&A technology integration programmes and fractional CTO support specifically designed to mitigate key-person dependency during acquisition transitions.

Infrastructure & DevOps

1. Is there documented evidence of achieving the committed uptime SLA over the past 12 months?

SLA claims without evidence are marketing, not engineering — request the raw uptime data.

1. Is monitoring and alerting configured to detect and notify for all critical system failures within 5 minutes?

If the team learns about outages from customer complaints, the monitoring is inadequate.

1. Has a disaster recovery (DR) plan been tested within the past 12 months, with documented RTO and RPO?

An untested DR plan is a hypothesis, not a capability. The first test should not be the real disaster.

1. Is there a business continuity plan (BCP) covering a loss of cloud region or primary data centre?

Single-region deployments without a BCP represent existential risk to revenue continuity.

1. Is the CI/CD pipeline fully automated from code commit to production deployment, with no manual steps?

Manual deployment steps are error-prone, undocumented, and concentrated in the hands of whichever engineer last configured them.

1. Is infrastructure provisioned and managed as code (Terraform, Pulumi, CDK, or equivalent) with version-controlled state?

Click-ops infrastructure cannot be audited, reproduced, or migrated — it is a key-person dependency on whoever clicked the buttons.

1. Is the cloud infrastructure cost trajectory documented and justified — specifically, is the cost growth rate ≤ revenue growth rate?

Infrastructure costs growing faster than revenue is a margin compression problem that worsens at scale.

Intellectual Property & Licensing

1. Has legal confirmed that all IP created by employees, contractors, and founders is assigned to the company via signed agreements?

Unsigned IP assignment agreements mean the acquirer may not own the code it is paying for.

1. Have all open-source components been reviewed for licence compliance — specifically, is there a GPL, AGPL, or SSPL-licenced component in the core product that could create copyleft obligations?

GPL contamination in a proprietary product can force disclosure of source code or require a costly rewrite to remove the dependency.

1. Are all material third-party integration contracts assignable or terminable without penalty in the event of a change of control?

Non-assignable contracts may require renegotiation at unfavourable terms, or force an unplanned vendor migration.

1. Does the company have documented data portability — can customer data be exported in a standard format within 30 days of a request?

Data portability is a GDPR requirement and a practical prerequisite for any platform migration.

1. Are all product trademarks registered in the relevant jurisdictions, and are the domain names held by the company (not the founder personally)?

Founder-held domains and unregistered trademarks create post-close leverage and ownership disputes.

1. Are there any open-source projects or research outputs that have been published under a licence that conflicts with the commercial product's IP position?

Published research or open-source code under permissive licences may have inadvertently disclosed proprietary algorithms.

Integration & Migration Risk

1. Is the full API surface area documented — specifically, are there undocumented internal APIs used by other systems that would break if the endpoint changes?

Undocumented internal APIs are the most common source of cascading failures during integration migrations.

1. Has a data migration complexity assessment been conducted, with an estimate of time and cost to migrate customer data to the acquirer's platform or to a unified schema?

Data migration is consistently the most underestimated cost in technology acquisitions — independent assessment is essential.

1. Has an independent party estimated the full integration timeline — not the management team's estimate?

Management teams underestimate integration timelines by an average of 40–60% — independent assessment corrects for optimism bias.

1. Are there single-tenant customer deployments that would require individual migration plans outside the standard programme?

Single-tenant deployments multiply migration complexity — each requires its own timeline, testing, and rollback plan.

1. Is there a documented path to consolidate identity and SSO with the acquirer's systems without requiring customers to re-authenticate?

Forcing customers to re-authenticate during migration creates churn risk at the worst possible moment.

1. Has vendor lock-in been assessed — specifically, are there proprietary cloud services (e.g. AWS Bedrock, Azure OpenAI) that would require significant re-architecture to migrate?

Proprietary cloud service dependencies can add 6–12 months to an integration timeline if re-architecture is required.

1. Is there a documented plan to retain the engineers who hold integration-critical knowledge for a minimum of 12 months post-close?

Integration knowledge is perishable — if the engineers who understand both systems leave, the integration stalls regardless of the plan.

How to Score the Findings

Band each answer using the following red/amber/green framework. This scoring is designed to produce a summary that goes directly into your Investment Committee presentation.

• Green: "Yes" with documented evidence available on request.
• Amber: "Yes" but evidence is incomplete or self-attested by management.
• Red: "No" or "I don't know" — requires independent verification or price adjustment.

Deal-Breakers

Any single Red on the following is a deal-breaker requiring resolution before close: GPL contamination in the core product, bus factor of 1 on any mission-critical system, undisclosed data breach with regulatory notification outstanding, or IP not formally assigned to the company.

Price-Adjusters

Three or more Ambers in a single category signals systemic weakness: technical debt remediation cost, integration timeline overrun risk, or key-person retention budget. Each should be costed and reflected in the purchase price or earn-out structure.

When to Walk Away

Walk away if you identify three or more deal-breakers, or if the management team is unable to answer 20% or more of the questions on this checklist. An inability to answer is itself a finding — it indicates that the organisation lacks the engineering maturity to support the acquisition thesis.

When to Renegotiate

Renegotiate when you identify 1–2 deal-breakers with a clear remediation path. Bake the remediation cost into the 100-day plan and reflect it in the price. A well-understood risk is manageable; an unquantified risk is not.

Once you have completed the technical due diligence, the next step is planning the integration. Our 100-day M&A integration playbook covers how to structure the programme from Day 0 through to platform consolidation.

TechLevity runs independent technical due diligence for PE-backed acquirers across the UK and EU. We produce a structured findings report — red/amber/green banded, with estimated remediation costs — that is designed to go directly into your Investment Committee presentation.

To discuss your acquisition, book a 30-minute technical due diligence briefing.