Technology Due Diligence Checklist: 40 Questions to Ask Before You Close

Why a checklist is a starting point

A technology due diligence checklist helps you ask the right questions in the right order. It does not tell you whether the answers are true.

Two companies can both answer “yes” to “Do you have backups?” One restores from backup every quarter and has the logs to prove it. The other has never tried. The checklist treats them the same. The investor should not.

So use the list below as a set of prompts. For each one, ask for the evidence behind the answer: a document, a screen, a log, a person who can explain it without notes.

1. Product and architecture

Why it matters: architecture decides how much growth the product can absorb before it needs a rewrite, and how much that rewrite will cost.

1. Can you draw the system on one page, and does the team agree with the drawing?
2. Which components would fail first if usage doubled?
3. What was the last major design decision the team regretted, and what did it cost?
4. Which parts are bought, which are built, and which are held together by scripts?
5. What is on the roadmap that the current design cannot support?

Good answer: a clear diagram, named weak points, a plan already in the roadmap. Red flag: “It scales fine” with no test or number behind it.

2. Code quality and technical debt

Why it matters: debt is a cost that arrives later. The question is how large it is and when it comes due. See our note on how investors should price technical debt.

1. How old is the oldest code still in production, and who understands it?
2. What share of engineering time goes to fixing and working around problems?
3. How are changes reviewed, tested and released?
4. Which dependencies are out of support or close to it?
5. What would the team fix first if given a free quarter?

Good answer: the team can name its debt and rank it. Red flag: “We have almost no debt.” Every working product has some.

3. Security and access

Why it matters: a weak security posture is a liability the buyer inherits, and access control is the part most often found in poor shape.

1. Who has administrator access to production, cloud accounts, source code and the domain registrar?
2. How is access removed when someone leaves, and when was it last checked?
3. When was the last independent security test, and what happened to its findings?
4. How are secrets such as keys and passwords stored?
5. What has the company done after its last security incident, however small?

Good answer: a current access list, a documented leaver process, findings tracked to closure. Red flag: shared logins, or no one who can list who has access.

4. Data and privacy

Why it matters: personal data brings legal duties that differ by market, and poor data practice is expensive to fix after a deal.

1. What personal data do you hold, where does it sit, and who can see it?
2. Can you show the consent or legal basis for collecting it?
3. Can you delete one person’s data from every system, including backups and analytics?
4. Which vendors process data on your behalf, and what do the contracts say?
5. Where does data cross borders, and has anyone checked the rules that apply?

Good answer: a data inventory and a tested deletion process. Red flag: the team cannot say where customer data lives. For Indian targets, see what technology due diligence misses under the DPDP Act.

5. Infrastructure and cloud cost

Why it matters: cloud cost can look like a small line today and become a margin problem as the product grows.

1. What is the monthly cloud bill, and how has it moved against usage over the last year?
2. Who owns cost, and how is waste found?
3. What happens if the main cloud region has an outage?
4. When was the last time you restored from backup?
5. Which environments exist, and are test environments holding real data?

Good answer: cost per customer or per transaction is known and falling or stable. Red flag: spend grows faster than revenue and nobody can say why.

6. Team and key people

Why it matters: the system is only as safe as the people who understand it. Our post on key person risk covers this area in depth.

1. Which two or three people would hurt most if they left?
2. Can anyone besides the founder deploy to production?
3. How long does a new engineer take to become useful?
4. What is the attrition in the last twelve months, and where?
5. Are the key people retained, through equity, contracts or both?

Good answer: knowledge is spread, with documents and pairs. Red flag: one person holds the keys and the memory.

7. Delivery and process

Why it matters: a team that ships reliably can fix its other problems. A team that cannot ship will struggle to fix any of them.

1. How often does the team release to production, and how often does a release fail?
2. How are incidents handled, and are they reviewed afterwards?
3. How do you decide what to build next, and who can say no?
4. What does the team measure about its own speed and quality?
5. How long does it take to go from an idea to a customer using it?

Good answer: simple, honest numbers the team already uses. Red flag: metrics prepared for the data room that nobody looked at before.

8. IP, open source and vendors

Why it matters: ownership problems and licence conditions can block a deal late, when it hurts most.

1. Who owns the code, including work by contractors and former employees?
2. Which open source components are used, and under which licences?
3. Does any licence require the company to release its own code?
4. Which vendors would be hard to replace, and what do the contracts allow?
5. Is any critical component maintained by one outside person or a small project?

Good answer: a bill of materials and signed assignment of work. Red flag: no list of components, or contractor work without written assignment.

Match the depth to the stage

The same list works at different depths. A rough guide:

Stage	Where to spend the time
Seed and Series A	Areas 1, 3, 6 and 7. Is the product sound enough, is access controlled, can the team ship
Growth round	Add areas 2, 4 and 5. Debt, data practice and cost at scale
Buyout or acquisition	All eight, plus integration questions
Carve-out	Areas 1, 3, 4 and 8, with a focus on what is shared with the parent

This is a guide from experience, not a rule. A fintech at seed may need area 4 early.

What a checklist cannot do

A checklist cannot judge people, and it cannot tell you what the answers mean for the price. Reading the answers takes someone who has run technology and has seen how these gaps play out after a deal closes. That reading is what turns a completed form into a diligence finding. Once the deal closes, the same areas can be reviewed every quarter; see technology governance vs technology due diligence.

If you are a founder, the best use of this list is to answer it honestly before an investor does. Gaps you name yourself are usually discussed. Gaps an investor finds first are usually priced.

Eidoran advises investors and boards on this through its technology due diligence and governance practice. Related reading: Series A technical due diligence, key person risk in startups, how investors should price technical debt, technology governance vs technology due diligence.

Frequently asked questions

What should a technology due diligence checklist include?

It should cover architecture, code and technical debt, security and access, data and privacy, infrastructure and cost, the team, delivery process, and IP, open source and vendors. Each question should ask for evidence, not only a yes or no.

Who should run technology due diligence?

Someone independent of the company and of the deal team’s incentives, with experience running technology at a comparable scale. An in-house engineer can help, but an outside reviewer gives the investment committee a view it can rely on.

When should technology due diligence happen?

After a term sheet or letter of intent and before the final commitment. Starting earlier with a light screen can save time, because deal breakers are cheaper to find early.

How is technology due diligence different from a security audit?

A security audit tests one area in depth. Technology due diligence looks across all areas and asks what the findings mean for value, risk and the plan after closing.

Can founders use this checklist to prepare?

Yes. Answer each question with evidence before the data room opens, and fix what you can. It is also a good base for a mock diligence.

This material is prepared for the general information of boards, investors and advisors, and does not constitute investment, legal or accounting advice.