Product

October 30, 2026

The Technical Due Diligence Checklist: Questions, Evidence, and Red Flags by Area

A deal team can have a data room full of documents and still lack the evidence it needs to judge the technology. A useful technical due diligence checklist turns broad topics such as architecture, security, and team risk into specific questions, documents to request, and red flags to investigate.

This one is for buy-side deal teams, the CTOs and architects they pull in, and sellers who want to know what's coming. It covers software and technology diligence for M&A and investment. The tables below also show how to weight findings by deal stage and type. If you need the end-to-end due diligence process first, start with our technology due diligence guide.

What a Technical Due Diligence Checklist Should Cover

A technical due diligence checklist tests whether the target's technology can carry the investment thesis. At minimum, it covers architecture and code quality, infrastructure and DevOps, security and compliance, and team and engineering practices. For a deal, our technology due diligence checklist splits those into seven areas and adds open source, intellectual property, and the product roadmap.

Area	What it answers for the deal	Weight by deal type (our view)
Architecture and scalability	Will the software architecture hold the planned growth and fit ours?	Highest for strategic acquirers
Code quality and engineering practices	How much technical debt are we buying?	Similar across deal types
Infrastructure, cloud cost, and resilience	What does it cost to run, and how does it fail?	High for PE platforms and carve-outs
Security, compliance, and data	What exposure and data privacy obligations come with it?	High; higher with regulated data
Open source, IP, and AI-generated code	Do we own what we're paying for?	High for all
Team and organization	Who holds the knowledge, and will they stay?	Highest for PE platforms
Product roadmap and delivery	Can it deliver the roadmap in the deal model?	High for PE platforms and strategic acquirers

Findings don't move price equally. In our view, a key-person problem or licensing conflict can change deal terms, while a style issue with no material delivery or security effect may remain a post-close cleanup item.

How to Scope the Checklist for Your Deal

Scope the M&A technical due diligence checklist to the deal stage, access available, and investment thesis.

Pre-LOI Screen vs. Confirmatory Diligence

Before a letter of intent, access and time are limited. Focus on four potential deal-breakers: open source licensing in shipped or hosted code, key-person concentration, security posture, and whether the architecture can support the roadmap. For security, request a recent penetration test and SOC 2 report or equivalent.

The broader review follows during confirmatory diligence, when repository access is available. The 8-phase technical due diligence process in our guide shows where each stage sits.

Weighting by Deal Type

Deal type	Look hardest at	Why
Private equity platform	Cloud cost per customer, delivery speed, leadership bench	Margin and a founder-independent team
Strategic acquirer	Architecture fit, data architecture, identity, integration effort	Value comes from combining systems
Carve-out	Hosting independence, shared services, intellectual property ownership after the split	What the parent runs becomes a transition cost

The Document and Access Request List

Send this on day one of confirmatory diligence, and ask for exports from source tools rather than summaries written for the data room.

Architecture diagrams, ADRs, and a service and dependency inventory
A same-week cloud resource export covering every production account and region
Read-only source code access, or an independent third-party scan
An SBOM per shipped product with license data
A full-history secrets scan and the credential rotation log
The latest pen test, its remediation tickets, and any retest
SOC 2 report or ISO/IEC 27001 certificate with scope, or a security questionnaire
12 to 24 months of incident history from the incident tool
CI/CD deployment history and the last restore test date
12 months of cloud invoices by service, plus main vendor contracts
Org chart with tenure, roles, and responsibilities, plus contractor IP assignments
The AI coding assistant policy, and the roadmap the deal team saw

The Technical Due Diligence Checklist, Area by Area

Copy the rows into your tracker; a check with no evidence by interview time is itself a finding.

Architecture and Scalability

Start here, with a dependency diagram; every other area assumes you know what the system is.

Check	Evidence to request	Red flag
Does the diagram match what's running?	Dated diagrams plus a same-week export of every production account and region	Services or data stores in the export that no diagram shows
What depends on what?	Service and dependency inventory, including third-party APIs	Nobody can say what breaks if a given database goes down
Why is it built this way?	Architecture decision records for major choices	Big decisions nobody wrote down, or records that stop years ago
Where are the single points of failure?	Failover design and last failover test	A critical service or database with no tested failover, or one person who knows the config
Will it scale to the deal model's growth?	Load test results, capacity headroom	Growth that needs a redesign nobody has scoped
How are tenants and data residency handled?	Tenancy model, data location by customer	Residency commitments the architecture can't enforce
Will it fit the acquirer's stack?	Authentication and authorization model, core data models	Custom identity and a data model that conflicts with yours

Check the diagram against deployment records and observed dependencies. A missing queue or vendor API connection is a specific discrepancy to investigate.

Stacks shows a model we build from code, cloud config, and observability data via read-only integrations. Archie, our reasoning agent, answers questions against that model, such as which services depend on a given database. Our homepage claims 5 minutes to a decision-grade system view; that's our own figure, not a benchmark.

In a deal, that fits sell-side preparation or post-close review. Our setup docs list AWS estates at companies past the early-stage startup phase as the supported configuration. We don't replace a pen test, a license scan, or financial and legal diligence.

Code Quality and Engineering Practices

Size the technical debt you'd be buying, and check whether the software development lifecycle keeps it from growing.

Check	Evidence to request	Red flag
Are coding standards and code reviews enforced?	Branch protection settings and a sample of merged PRs	Direct pushes to main, or approvals that land within seconds
Is code coverage moving the right way?	Coverage by service over 12 months	Coverage falling in the services the roadmap depends on
What does static analysis flag?	Current static analysis output and the triage policy	Thousands of suppressed findings with no owner
How often do changes ship, and can they roll back?	Deploys per month from CI/CD, rollback runbook	Rare manual releases, or a rollback nobody has tried
Can the team name and cost its debt?	Debt register with rough estimates	"Some legacy code" with no list, owner, or estimate

Infrastructure, Cloud Cost, and Resilience

Cloud spend goes straight into the deal model, so build cost per customer from the invoices yourself.

Check	Evidence to request	Red flag
What does it cost to run, per customer?	12 months of cloud spend by service, from invoices	Spend rising every quarter and no cost-per-customer figure
Is infrastructure defined in code?	Infrastructure as code repos and a coverage estimate	Production resources created by hand
Are disaster recovery and business continuity plans tested?	RTO and RPO targets, date of the last restore test	Targets on paper only, or a test that missed them
What happens during an incident?	Observability setup and incident history	Repeat incidents with the same root cause
Any physical hosting?	Data center or colocation contracts	Terms that run past the planned migration date

Security, Compliance, and Data

Read the reports, not the badges: check which product and entity the scope covers, and the issue date.

Check	Evidence to request	Red flag
What assurance exists, for what scope?	SOC 2 report or ISO/IEC 27001 certificate with scope statement	Scope excluding the product you're buying, or unowned exceptions
What did the last pen test find?	Report, remediation tickets, and retest evidence	Critical findings risk-accepted with no compensating control or named approver
Who can access production?	Access review, MFA enforcement, privileged account list	Shared admin accounts, or former employees still listed
Are secrets in the code or git history?	Full-history secrets scan of all branches, dated rotation log	Secrets scrubbed from history but never rotated
What data do they hold, and under which rules?	Data inventory mapped to GDPR, HIPAA, or other obligations, plus encryption settings	Personal or health data in systems missing from the inventory
Would they notice an intrusion?	Intrusion detection, alert routing, incident response plan	Alerts going to an inbox nobody watches

Revoke or rotate an exposed secret before cleaning up repository history. A force push changes the repository's history; it does not invalidate the credential or remove every copy of the commit. The commit can still turn up in clones and forks, in cached views by SHA, and in pull requests that reference it. GitHub Support only helps clear the last two when rotating the credential can't mitigate the risk.

Open Source, IP, and AI-Generated Code

Black Duck's 2026 OSSRA report found license conflicts in 68% of the 947 commercial codebases it audited, up from 56% the year before, and its audit set includes 197 M&A transactions.

Check	Evidence to request	Red flag
What's in the product, under which licenses?	SBOM with component license and hash fields, plus a license scan	No SBOM, one generated once for a customer and never refreshed, or license fields mostly marked unknown
Is copyleft code in what they ship or host?	Copyleft components and how each is used	Copyleft code in a closed-source product counsel never reviewed
Does the company have intellectual property ownership of its code?	IP assignments from everyone who touched core code	Core modules written by contractors with no signed assignment
Is there a policy for AI coding assistants?	Written policy, approved tools, review and scan rules for AI output	A ban on paper while developers use assistants anyway
How are AI/ML features governed?	Training data sources, model monitoring, provider contracts	Customer data in training with no clear basis, or one provider and no exit plan

Use CISA's 2026 Minimum Elements for an SBOM as the bar. It requires component license and component hash fields, so a conforming SBOM helps answer the license question. Those fields were only recommended in the 2021 NTIA baseline.

A written AI policy is only useful if the team follows it. The OSSRA report's AI figures help explain why the checklist asks about both policy and review: 71% of companies that prohibit AI coding assistants say developers use them anyway. Only 54% of organizations evaluate AI-generated code for IP and license risk. These figures come from Black Duck's wider research, not the codebase audits.

Team and Organization

Check the org chart against who actually ships and who holds the keys.

Check	Evidence to request	Red flag
How long have people stayed?	Org chart with tenure, recent departures	Most senior engineers hired within the year
Who actually knows each critical system?	Commit history by service for 12 months	One name on most of the last year's commits to a revenue-critical service
Who holds deploy rights and production credentials?	CI/CD and cloud account access lists	A single person, or someone who has left
How dependent are they on contractors?	Contractor list, scope, and notice periods	Contractors owning core services on short notice
Who is likely to leave after close?	Retention plans and vesting for key engineers	Key engineers fully vested with no retention plan
Can new engineers get productive?	Onboarding docs, time from hire to first deploy	Knowledge that lives only in people's heads

In MIT Sloan research on post-acquisition attrition, 33% of acquired workers at U.S. high-tech startups left within a year, against 12% of comparable regular hires. Build the retention plan around who the commit history says the code depends on.

Product Roadmap and Delivery

A tech stack audit of the running estate gives you the baseline for judging the roadmap the deal pays for.

Check	Evidence to request	Red flag
Can this codebase deliver the product roadmap?	Roadmap with the architecture work each item needs	Items that assume a rebuild nobody has costed
How fast does the team deliver today?	Delivery metrics exported from tools	Numbers that only exist in the management presentation
How good is product quality?	Defect rates, bug backlog age, customer support escalations	A growing bug backlog and rising escalations
Does customer feedback reach engineering?	How support tickets become roadmap items	No path from support to the backlog
What runs outside the official stack?	SaaS and internal tool inventory	Shadow IT handling customer data or revenue workflows

Technical Due Diligence Questions to Ask in Management Interviews

Use these technical due diligence questions to test the evidence behind leadership's answers.

"Pull up a postmortem from this quarter. What changed because of it?" Look for a shipped ticket or PR dated after the incident.
"Besides its lead, who has deployed this service in the last 90 days?" Names should match the deploy history.
"Which roadmap items need architecture work first?" Good answers name items, work, and rough effort; an empty list suggests nobody has looked.
"Which system is that figure exported from, for which dates?" The export should match the slide.
"What would you rebuild with a quarter of no feature work?" Ask for specific debt items and a rough remediation cost.
"Which vendor would hurt most if it doubled its price or went down?" Listen for a name, terms, and a fallback.
"How is AI-assistant code reviewed before it merges?" A good answer names the policy and review step; "we don't use them" is weak.

When an answer contradicts the data room, reconcile the discrepancy and verify related claims against source records.

How to Score Findings and Turn Them Into a Report

Score each area green, yellow, or red against the investment thesis rather than an ideal system. A monolith can be green for a private equity buyer growing the existing product and red for a strategic acquirer that needs to split out one domain.

Then tag each finding by the decision it requires. A deal-breaker stops or restructures the deal. A price or terms adjustment affects valuation, escrow, an indemnity, or a closing condition. Work that can wait becomes a 100-day plan item with a budget.

Give every finding an owner and a rough remediation cost so the buyer can assign and budget the work. Our guide shows how to build a technical due diligence report from these findings.

How Sellers Should Prepare for Technical Due Diligence

Work through this tech due diligence checklist 60 to 90 days before a deal process starts. Sell-side technical due diligence moves faster when the data room already holds the evidence.

Export real numbers from source tools: deploys, incidents, coverage, and cloud spend.
Run your own license and full-history secrets scans, and generate an SBOM.
Rotate exposed credentials and log each rotation's date.
Spread knowledge of critical systems so no engineer is a key-person finding.
Collect signed IP assignments from every contractor on core code.
Redraw architecture diagrams from what's running.
Write down known technical debt with a rough cost.

If you're past the early-stage startup phase on AWS and connect your estate to Catio, your data room's diagrams and architecture answers come from a model of what's running. Reviewers can compare that model with the intended design to flag drift as diligence progresses.

Conclusion

A technical due diligence checklist only helps if each item ends in evidence and a decision. The right artifacts help expose key-person concentration, licensing risks, and a system that no longer matches its diagram.

For a quick architecture check, compare the newest diagram with a same-week export of every production account and region. Investigate the gaps before relying on the architecture evidence.

Preparing your system for a buyer, or getting to grips with one you've just acquired? Chat with our team to see a current model of your own system.

FAQ

What is technical due diligence?

Technical due diligence reviews a target company's technology, from architecture and code to security, team, and IP, before an acquisition or investment. It shows whether the technology can support the deal and what fixing the gaps will cost. Our technology due diligence guide covers the full process.

What should be included in a technical due diligence checklist?

Architecture, code quality, infrastructure and cloud cost, security and data, open source and IP (including AI-generated code), team, and product roadmap. Each item should name the evidence to request and the red flag to look for. Weight areas by deal type.

How long does technical due diligence take?

It depends on deal size and how fast the target grants access. As a working assumption, not a benchmark, plan a few days for a pre-LOI screen and a few weeks for confirmatory review of a mid-market software company. Carve-outs and multi-product targets take longer.

What are the five core parts of due diligence?

Lists vary, and most general ones include financial and legal work alongside technology. For the technology track, this checklist folds into five parts: architecture, code and delivery, infrastructure and cost, security and data, and people. Open source and IP questions sit mostly under code, with ownership questions under people.

Share this Post