Technical Due Diligence Questions: 60 Questions to Ask the Target

These are the 60 technical due diligence questions to ask a target company before an acquisition or investment, grouped into seven areas: product and architecture, code quality, security, infrastructure, team, intellectual property, and data and privacy. Each question comes with what a weak answer tells you. Ask them in interviews, then check the answers against the code with our technical due diligence checklist.

Questions by area

Product and architecture (10 questions)
Code quality and technical debt (10 questions)
Security and compliance (10 questions)
Infrastructure and operations (8 questions)
Team and process (10 questions)
Intellectual property and open source (6 questions)
Data and privacy (6 questions)

Product and architecture questions

Start here: you need a map of the system before any other answer makes sense.

1
Can you walk us through the architecture on one diagram?
If nobody can draw it, nobody fully understands it.
2
Which parts of the system would you rebuild if you started today, and why?
Honest teams know where the debt is; evasive answers are a signal.
3
What are the main services, and how do they talk to each other?
Reveals hidden coupling and single points of failure.
4
Which third-party services is the product built on, and what happens if one goes away?
Vendor lock-in and concentration risk the buyer inherits.
5
How is the database designed, and how are schema changes rolled out?
Unversioned, irreversible migrations are a common source of outages.
6
What is the largest customer or data volume the system has handled?
Tells you how far the deal thesis stretches current proof.
7
What would have to change to handle 10× today’s load?
Separates “add servers” from “rewrite the core”.
8
Where is the code that handles money, permissions and customer data?
The places where a bug costs the most deserve the deepest review.
9
How many repositories are there, and do we have access to all of them?
Missing repos are where surprises hide.
10
What is planned on the technical roadmap for the next 12 months?
Checks the roadmap against the team and budget that actually exist.

Code quality and technical debt questions

These questions pair with the code checks in the checklist; ask them, then verify in the code.

11
What share of the code is covered by automated tests, and which areas have none?
Untested payment or auth code is a post-close incident waiting to happen.
12
Does CI run the tests on every pull request and block merges on failure?
A pipeline that exists but is ignored protects nothing.
13
How do code reviews work, and can anyone merge without one?
Self-merged changes to production are a governance gap.
14
Which parts of the codebase do engineers avoid changing?
Those are the expensive parts to maintain after the deal.
15
How much of the code was generated with AI tools, and how is it reviewed?
Unreviewed generated code tends to duplicate logic and skip edge cases.
16
How do you track technical debt, and how much time goes to paying it down?
Zero time on debt means it compounds into the buyer’s problem.
17
When did you last upgrade the language runtime and major frameworks?
End-of-life runtimes stop getting security patches.
18
Is there dead code, duplicated logic or abandoned features still deployed?
Inflates the codebase the buyer is paying for.
19
How long does it take a new engineer to ship their first change?
Onboarding time is a direct measure of maintainability.
20
What would you fix first with an extra engineer for three months?
Usually names the single biggest technical risk.

Security and compliance questions

Security findings are the ones most likely to become conditions of close.

21
When was the last penetration test or security audit, and what did it find?
Ask for the report and what was actually fixed.
22
Have you had a security incident or data breach? How was it handled?
Undisclosed incidents are a legal risk, not just a technical one.
23
How are secrets and API keys stored and rotated?
Keys in the repo or shared in chat are an immediate finding.
24
Who has production access today, and how is it removed when someone leaves?
Former staff with live access is a common, serious gap.
25
How is customer data isolated between tenants?
One missing check can expose every customer’s data.
26
Which compliance standards do you meet (SOC 2, ISO 27001, GDPR, HIPAA)?
Promised certifications that don’t exist affect enterprise revenue.
27
How do you find and patch vulnerable dependencies?
No process means a growing backlog of known vulnerabilities.
28
Is data encrypted in transit and at rest, including backups?
Unencrypted backups are a quiet but serious exposure.
29
How is authentication implemented, and is it a known library or custom-built?
Home-grown auth deserves a much closer look.
30
What logging exists, and could you tell who accessed a customer record last month?
Without audit logs, a breach can’t be scoped.

Infrastructure and operations questions

How the product runs day to day, and what it costs.

31
Where is the product hosted, and is the infrastructure defined as code?
Hand-built infrastructure is hard to reproduce or hand over.
32
What is the monthly cloud bill, and how does it scale with customers?
Costs that grow faster than revenue break the deal model.
33
How are backups taken, and when did you last test a restore?
An untested backup is not a backup.
34
What uptime have you had over the last year, and what caused the biggest outages?
Patterns in outages point to structural weaknesses.
35
How are deployments done, and how often? Can you roll back?
Manual, rare deployments slow every future change.
36
Who is on call, and how are incidents detected?
If customers report outages first, monitoring is missing.
37
Is there a disaster-recovery plan, and has it been rehearsed?
A single region or database is a single point of failure.
38
Which environments exist (dev, staging, production), and how close is staging to production?
Without real staging, every release is tested in production.

Team and process questions

Key-person risk is the finding money can’t fix quickly.

39
Who wrote most of the code, and are they staying after the deal?
One author with no retention plan is a bus factor of one.
40
Which systems does only one person understand?
Those need documentation and a handover before close.
41
How many engineers are employees versus contractors or agencies?
Contractor-built code may have IP and continuity gaps.
42
Who has left the engineering team in the last 12 months, and why?
Recent senior departures often mean knowledge already left.
43
How is work planned and prioritised?
Shows whether delivery is predictable or reactive.
44
What documentation exists for architecture, setup and runbooks?
Missing docs make every post-close change slower.
45
How long would it take to replace your most senior engineer?
A direct estimate of key-person risk.
46
What is the engineering hiring plan, and is it funded?
Roadmaps that depend on unfunded hires won’t ship.
47
How are engineers paid and incentivised, including equity?
Vesting that ends at close is a retention risk.
48
What do engineers say is the most frustrating part of working here?
Often the most honest answer you get all day.

Intellectual property and open source questions

Questions for the technical lead and counsel together.

49
Does the company own all of its code, including work by contractors?
Missing IP assignments can cloud ownership.
50
Do you use any GPL or AGPL code, and how is it distributed?
Strong copyleft can oblige publishing your own source.
51
Is there a list of open-source dependencies and their licenses?
No list usually means nobody has checked.
52
Has any code been copied from previous employers or other projects?
Inherited code can carry legal claims.
53
Are any core features built on another company’s API or model with restrictive terms?
Terms can change, or forbid the buyer’s use case.
54
Are there patents, trademarks or pending disputes related to the product?
Litigation risk belongs in the deal terms.

Data and privacy questions

Where customer data lives and who can touch it.

55
What personal data do you store, and where?
Defines the privacy obligations the buyer takes on.
56
Which regions is data stored in, and do any customers require residency?
Contract terms can restrict migration plans.
57
How do you handle data deletion and export requests?
GDPR and CCPA obligations need a working process.
58
Which third parties receive customer data?
Every sub-processor is a risk and a contract.
59
Is production data ever copied to development or test environments?
Real data in test systems is a common leak.
60
How long is data retained, and is retention enforced automatically?
Keeping data forever increases breach impact.

How to run the interviews

Send the questions a few days ahead. You want considered answers, not improvisation.
Get repository access before the interviews. Then you can ask about what you already found in the code instead of taking answers on trust.
Talk to more than the CTO. The engineers who own each system give the most accurate detail.
Write down every answer you can’t verify. Those become open items, warranties or conditions in the deal.

Most code-level questions (tests, dependencies, secrets, licenses, who wrote the code) can be answered from the repository directly. See the red flags that kill deals and why due diligence now takes days, not weeks.

Technical due diligence questions FAQ

What questions should you ask in technical due diligence?

Ask about architecture and scalability, code quality and tests, security and compliance, infrastructure and costs, team and key-person risk, intellectual property and open-source licenses, and data and privacy. Then verify the answers against the code itself rather than relying on the responses alone.

Who should answer technical due diligence questions?

The CTO or head of engineering for architecture and roadmap, the engineers who own each system for the detail, and legal counsel together with the tech lead for intellectual property and licensing questions.

How do you verify the answers?

Read-only access to the repositories lets you check claims about tests, dependencies, secrets, licenses and who wrote the code. Automated scanning answers most code questions in hours; interviews cover what the code can’t show, like plans and hiring.

How many questions should a technical due diligence questionnaire have?

Enough to cover each risk area without burying the team: this list has 60. For an early screening, pick the 15 to 20 most relevant to the deal thesis and verify the rest from the code.

Get the code-level answers in days: see Audit Bench Ai technical due diligence →