What is software due diligence?

Software due diligence is a review of a company's software, infrastructure, security and engineering team before a decision that depends on them: an acquisition, an investment, or an enterprise customer choosing a vendor. It checks who owns the code, how the system is built and run, how data is protected, and what it would take to keep it running and growing.

What should a software due diligence checklist include?

Ownership and licences, architecture and scalability, hosting and data location, security controls, change management, audit logs, backups and recovery, data minimization, the team and key-person risk, third parties including AI tools, running costs, and technical debt. Each item should be answered with evidence, not a yes.

How is M&A due diligence different from an enterprise vendor review?

An acquirer or investor asks whether the software is worth what they are paying and whether it can grow without the people who built it: ownership, key-person risk, technical debt, cost and scalability weigh most. An enterprise customer asks whether its data is safe with you: security controls, data location, logs, subprocessors and incident response weigh most.

How long does a software due diligence take?

An enterprise security questionnaire usually takes days to a few weeks of back and forth. A technical due diligence for an investment or acquisition typically takes two to four weeks, with read-only access to code and cloud, and interviews with the engineering team.

How do you prepare for a technical due diligence?

Write the answers down before anyone asks: a short security and architecture overview organized by the reviewer's usual sections, with evidence for each claim and the known gaps stated plainly with a date to fix them. A reviewer trusts a document that lists its own gaps far more than one that has none.

Software Due Diligence Checklist for M&A and Vendor Reviews

A clipboard with checked items beside a padlocked server, a sealed folder and a magnifying glass

A software due diligence checklist covers twelve areas: ownership and licences, architecture, hosting and data location, security controls, change management, audit logs, backups, data minimization, the team, third parties, running costs and technical debt. What changes between an acquisition and an enterprise customer's vendor review is the weight: an acquirer cares most about ownership, key people and debt; an enterprise customer cares most about where its data goes and who can touch it. Either way, the answer that passes is evidence, not "yes". I've been on the audited side six times, through a fundraising and the sale of Side, the French staffing marketplace I co-founded, to Randstad, and in enterprise reviews of companies we work for. Below is the checklist, the differences, and what a good answer looks like.

The checklist

Use it to prepare if you're the one being reviewed, or to run a review if you're the buyer. For each line, the question is not "do you have it?" but "show me."

1. Ownership and licences

Does the company own all of its code, including what contractors and agencies wrote? Are the assignments signed?
Which open-source licences are in use, and does any of them oblige you to publish your own code?
Which third-party components, APIs or data does the product depend on, under what contract?

2. Architecture and scalability

What are the main components, and where does everything wait on one database table, queue or service?
What happens at ten times today's load? Which part breaks first?
Can services scale horizontally, or does growth mean bigger machines and downtime?

3. Hosting and data location

Where is each kind of data stored and processed, by country and by provider?
Which components see personal data, and which never do?
Is anything reachable from the internet that shouldn't be? How many public entry points are there?

4. Security controls

Encryption in transit (which TLS versions are accepted) and at rest, including backups.
Secrets: where they live, who can read them, whether any long-lived keys exist.
Access: single sign-on, multi-factor authentication, least privilege, how access is granted, reviewed and removed when someone leaves.

5. Change management

Is every change reviewed before it is merged?
Do tests, static analysis and dependency vulnerability scans block a bad change automatically?
Can anyone change production from their own laptop, or only the deployment pipeline?

6. Audit logs

Who changed what, when and why, for infrastructure, for data access and for administration?
How long are logs kept, and where?
Can every database connection be traced to a named person or service?

7. Backups and recovery

How often, how long they are kept, and where.
When was a restore last tested, and how long did it take?
What is monitored, and who gets woken up?

8. Data minimization and privacy

Does each service receive only the data it needs, and reject the rest?
What is kept, for how long, and is the retention period written down?
Do error messages and logs leak personal data or internals?

9. Team and key people

Who could rebuild the system if one person left tomorrow? Is that knowledge written down?
Who makes technical decisions, and are they the right person?
How much depends on a single contractor or agency?

10. Third parties and AI

Which suppliers process the company's data, and under which agreements?
Which AI tools are in use, sanctioned or not, and what data reaches them?
What happens operationally if a supplier disappears next month?

11. Running costs

What does the cloud bill contain, line by line, and how has it grown against revenue?
What is safely removable, and what is load-bearing?

12. Technical debt and roadmap

What does the team itself say needs rewriting, and why hasn't it been?
What is the honest gap between the roadmap and what the team can deliver?

Acquisition or investment versus enterprise screening

The checklist is the same. Where the reviewer spends their time is not.

An acquirer or investor asks whether the software is worth what they're paying, and whether it keeps working without the people who built it. Expect the deepest questions on ownership and licences (1), architecture and scalability (2), the team and key people (9), running costs (11) and technical debt (12). The output is a risk register that feeds the price and the deal terms.

An enterprise customer asks whether its data is safe with you, and whether its own auditors will accept you as a supplier. Expect the deepest questions on hosting and data location (3), security controls (4), audit logs (6), data minimization (8) and third parties (10). The output is a yes, a no, or a list of conditions, often with dates attached.

The mistake I see most from companies being reviewed: answering the second kind of review as if it were the first, with an architecture diagram and a growth story, when the reviewer wanted to know where the bank details are stored.

What a good answer to an enterprise review looks like

The reviews that went fastest, on the audited side, all had the same shape:

A short overview in the reviewer's own sections. Scope, hosting and isolation, encryption, access, change management, logs, recovery, the data each service holds. Two to four pages they can map straight onto their questionnaire, instead of a deck they have to translate.
Data minimization as a rule the code enforces. A service that accepts only the fields its job needs, and rejects any request carrying anything else, answers a page of questions in one line. So does a service that produces a document and keeps nothing.
Gaps listed next to the controls. Older parts of a system rarely have every control the newer ones have. Say so, line by line, with what is in place instead and a date for the rest. A reviewer who finds a gap you didn't mention stops trusting everything else you wrote. One who reads it from you, with a plan, moves on.
Questions you can't answer yet turned into options. When a reviewer asks something the current design never had to answer, such as where exactly the data sits, a one-page note with two or three options, what each guarantees and what each costs, turns a blocker into a decision.
The review changes the system, not just the document. Expect to fix things during the review: a log retention period, an access rule, a setting nobody had looked at. Then the next version of the overview says so.

Mistakes from the audited side

Claiming what you can't show. "We're SOC 2 compliant" without the report ends the conversation. Say what you do, show it, and say what you don't have.
Answering from memory. Every answer should point at evidence: a config, a log, a pipeline, a policy with a date.
Letting one person answer everything. If only the CTO can answer, you've just shown the reviewer your key-person risk.
Promising fixes with no date. "We'll add that" reads as no. "Live by 30 November, owner named" reads as a plan.
Waiting for the questionnaire. The best time to write the overview is before the first enterprise deal or the first term sheet, when nobody is waiting on it.

What it costs

If you only need to know whether a piece of software can be safely changed, and by whom, our code audit is €2,500 (about $2,900), fixed. A full technical due diligence sprint across architecture, cloud, security, delivery, AI use and suppliers is priced after a short scoping call, because it depends on how many systems are in play, and you get the figure in writing before anything starts. Either way, the deliverable is written for the person deciding: a risk register, a 30/60/90-day plan, and a two-page summary that survives being forwarded.