What are the key components of a technology due diligence checklist?

Eight areas cover it: architecture and code quality, cloud spend and unit economics, security and compliance, team and key-person risk, vendor lock-in and third-party dependencies, product delivery and roadmap, data and analytics, and reliability and recovery. The checklist on this page asks 40 questions across those eight, sorts every answer into held up, unclear, or red flag, and ends in a verdict you can print for the data room. Free, in the browser, no email required.

What is a due diligence checklist?

A structured list of the questions a buyer must answer before a deal closes, designed so nothing important survives on charm. A good one does two jobs: it forces every claim in the deck to be tested against evidence, and it turns what cannot be verified into a written follow-up list instead of a shrug. This one covers the technology side of an acquisition; commercial, financial, and legal diligence carry their own lists alongside it.

Resource · Technical Due Diligence

The Technical Due Diligence checklist.

For private equity partners, corp dev teams, and operating partners: the forty questions to put to a target's CTO, run right here in the browser. Sort every answer into one of three piles as it lands. Red flags become your escalation list, unclears become the follow-up email, held-ups build the verdict. Nothing is gated, and the whole page prints to PDF for the data room.

Start the checklist

How to run it

Specific questions surface specific problems.

Work through each section with the target's CTO, VP Engineering, or technical founder, and sort each answer: held up, unclear, or red flag. Engineering leaders trained to sell their own competence answer generic questions with generic reassurance, which is why this is a checklist, not an open-ended interview.

The score is the held-up count out of forty, and your verdict assembles in the rail as you go. Anything under twenty-four held up is a serious concern. Notes ride along on any answer, and each target you run is saved separately in this browser.

This is the technical side. IP assignment, DPAs, and licensing audits sit with legal diligence, so flag anything you hear about them and hand it across rather than trying to resolve it here.

It also pairs with the rest of the suite: the Tech-Risk Scorecard lets a target self-score, this checklist evidences those answers in the room, and the Technical Due Diligence verifies them independently. To see what that verification produces, the sample due diligence report shows a full memo end to end.

↑↓ move · 1 held up · 2 unclear · 3 red flag · N note

Architecture and code quality

0 / 5

Listen for: Undocumented architecture with a single engineer who "knows how it works", test coverage below 30% on revenue paths, critical vulnerabilities open more than 90 days, core stack on an end-of-life version.

1.1

Note:

1.2

Note:

1.3

Note:

1.4

Note:

1.5

Note:

Cloud spend and unit economics

0 / 5

Listen for: Cloud spend above 12% of revenue for SaaS, no cost-optimisation review in the last year, cost per customer flat or rising despite scale, everything on on-demand pricing.

2.1

Note:

2.2

Note:

2.3

Note:

2.4

Note:

2.5

Note:

Security and compliance

0 / 5

Listen for: Certifications lapsed or perpetually "in progress", no pen test in the last year, customer data unencrypted at rest, a retention policy of "keep everything forever", incidents with no disclosure trail.

3.1

Note:

3.2

Note:

3.3

Note:

3.4

Note:

3.5

Note:

Team and key-person risk

0 / 5

Listen for: Bus factor of one or two on any core system, attrition materially above sector average, senior roles open more than six months, fewer than three people qualified for primary on-call.

4.1

Note:

4.2

Note:

4.3

Note:

4.4

Note:

4.5

Note:

Vendor lock-in and third-party dependencies

0 / 5

Listen for: A single vendor above 25% of tech opex, renewals due inside 12 months at a step-up, unmaintained open source in a critical path, copyleft licences (GPL/AGPL) in a shipped product, exclusivity clauses that survive a sale, no fallback for critical APIs.

5.1

Note:

5.2

Note:

5.3

Note:

5.4

Note:

5.5

Note:

Product delivery and roadmap

0 / 5

Listen for: A roadmap that is a wishlist rather than a plan, more than 30% of items slipping materially, maintenance ratio below 20% or above 70%, product and commercial plans built in isolation.

6.1

Note:

6.2

Note:

6.3

Note:

6.4

Note:

6.5

Note:

Data and analytics

0 / 5

Listen for: Board numbers reconstructed manually each month, analytics that needs an engineer for basic commercial questions, "AI features" that are actually manual, subject access requests taking more than 30 days.

7.1

Note:

7.2

Note:

7.3

Note:

7.4

Note:

7.5

Note:

Reliability and recovery

0 / 5

Listen for: Uptime nobody can state, a worst-outage story with no postmortem, backups that have never been restored, customers as the monitoring system, a recovery plan that exists only as an intention.

8.1

Note:

8.2

Note:

8.3

Note:

8.4

Note:

8.5

Note:

Escalate immediately

The five deal-changer red flags.

If any of these surfaced at any point, tick it. One is enough to warrant a fuller technical review before any further commercial commitment, whatever the totals say.

Undocumented architecture with a single engineer who understands the platform.The single largest key-person risk we see. Cloud spend above 15% of revenue with no explanation.Two tiers: above 12% of revenue is worth a dig, above 15% with no explanation is a deal-changer. Almost always over-engineering or missed optimisation, often both. A compliance framework customers require that the target does not have.Retrofitting compliance is 6-12 months of work that is not on the roadmap. A vendor renewal in the next 12 months at a material step-up.This hits EBITDA under new ownership on day one. A product-market fit story that depends on features the roadmap does not have.The gap between "we are going to build that" and "we have shipped that" is where thesis-breaking risk hides.

Get the board-ready written review

Enter your work email and we write back within two working days: what the red flags mean for the deal, and what independent validation would cost and cover. No call unless you ask for one.

Want us to run the diligence for you?

The checklist is what we distilled from the Technical Due Diligence we run for PE clients. If any section comes back amber or red, that is when we would come in, independent, structured, delivered as a red/amber/green report a partner can put in front of an IC.

Short on time? The interactive Tech-Risk Scorecard runs the same review across six dimensions in about ten minutes.

See the Technical Due Diligence Book a 30-minute call →

Questions buyers ask first

The honest answers to what you're about to ask.

What are the key components of a technology due diligence checklist?: Eight areas cover it: architecture and code quality, cloud spend and unit economics, security and compliance, team and key-person risk, vendor lock-in and third-party dependencies, product delivery and roadmap, data and analytics, and reliability and recovery. The checklist on this page asks 40 questions across those eight, sorts every answer into held up, unclear, or red flag, and ends in a verdict you can print for the data room. Free, in the browser, no email required.
What is a due diligence checklist?: A structured list of the questions a buyer must answer before a deal closes, designed so nothing important survives on charm. A good one does two jobs: it forces every claim in the deck to be tested against evidence, and it turns what cannot be verified into a written follow-up list instead of a shrug. This one covers the technology side of an acquisition; commercial, financial, and legal diligence carry their own lists alongside it.