Software due diligence: what buyers and investors check

Software due diligence is the review a buyer or investor runs on the software behind a deal before money moves. It checks who owns the code, which open-source licences it carries, how secure and maintainable it is, what it costs to run and which people it depends on. The findings change the price, the terms or the decision.

This guide shows what reviewers ask for in each area, the document that answers each request and the red flags that reopen a negotiation. If you are the one buying or investing and cannot read the code yourself, our technical due diligence services give you an independent review of the code, security, infrastructure and team before you commit.

What is software due diligence?

Software due diligence is an evidence-based review of a company's software before an acquisition or an investment. The reviewer reads the code and the records around it, then reports what the buyer is getting and what it will cost to own.

It runs beside the financial and legal reviews and feeds both. A licence problem becomes a legal term. An ageing platform becomes a line in the financial model. When the product is the main asset, a gap in this review is a gap in the valuation.

The term overlaps with technical due diligence, and many people use the two names for the same review. Where they are kept apart, the software review concentrates on the code and what is inside it: ownership, open-source components and licences. The technical review is wider and follows the whole process through to the report. This guide stays with the evidence.

One more name causes confusion. "Due diligence software" means tools, such as data rooms, that manage the paperwork of a deal. This guide is about reviewing software, not about those tools.

What software due diligence covers

A software review covers six areas, and each one comes down to documents the seller can hand over. The table lists the evidence a reviewer asks for, a typical red flag and how that finding reaches the deal.

None of these findings is unusual in a growing company. What a reviewer weighs is whether the seller already knew, and whether a plan exists.

Code ownership and IP: who owns every line

The first question is whether the company owns its code. The evidence is a signed agreement for every person and firm that wrote part of it, matched against the list of authors in the repository history.

The gaps tend to sit in the same places: a contractor from the first year, an agency that built the first version, or work a founder did before the company existed. Ownership rules differ by country, so the lawyers decide what each agreement must say. The reviewer supplies the facts, which are who wrote what and when.

Two newer questions belong here. Reviewers ask which AI coding tools the team used and under which terms, because the answer can affect what the company is able to claim as its own. They also read commercial licences and API terms, since some restrict transfer when a company changes hands.

Open-source licences and the SBOM

Reviewers ask for a software bill of materials (SBOM): a list of every component in the product with its version and licence. Without one, nobody can say what the product is built from or which licence terms come with it.

The reference definition comes from the US National Telecommunications and Information Administration (NTIA). Its July 2021 report, The Minimum Elements For a Software Bill of Materials, calls an SBOM a formal record containing the details and supply chain relationships of the components used in building software. It sets seven data fields for each component:

• supplier name
• component name
• version of the component
• other unique identifiers
• dependency relationship
• author of the SBOM data
• timestamp

The US Cybersecurity and Infrastructure Security Agency (CISA) published a draft update to those minimum elements for public comment in August 2025. As of November 2026, a reviewer can still treat the seven fields as the floor.

An SBOM should arrive in a standard format so tools can read it. The two a seller is most likely to produce are SPDX, published as ISO/IEC 5962:2021, and CycloneDX, published by Ecma International as ECMA-424. The second edition of ECMA-424, dated December 2025, defines CycloneDX v1.7. Either one generated from the current build is acceptable. A spreadsheet typed by hand is not.

Which licences raise a flag

Permissive licences such as MIT and Apache 2.0 mainly ask for attribution and notices, and they seldom trouble a buyer. Copyleft licences ask for more. The GNU Project describes copyleft as requiring all modified and extended versions of a program to be free as well, which matters when the product ships that code to customers.

Hosted products have their own case. Section 13 of the GNU Affero General Public License says that if you modify the program, you must offer its source to users who interact with it over a network. A modified AGPL component inside a SaaS product is therefore a finding, and the lawyers decide how serious it is.

A component with no licence at all is a problem too, because no licence means no stated permission to use it. So is a component nobody maintains any more.

Process counts as evidence as well. OpenChain ISO/IEC 5230 defines the key requirements of an open-source licence compliance program, and a company can adopt it through self-certification. Its companion, ISO/IEC 18974, does the same for checking open-source components against known vulnerabilities. A seller that follows either has most of this section ready.

Security, architecture and running cost

These three areas show what the product will cost to own after the deal. The reviewer wants scan output, a diagram and the bills, not a description of them.

Security. The starting point is a dependency scan against known vulnerabilities. Anything listed in CISA's Known Exploited Vulnerabilities catalog goes to the top, because CISA maintains it as the authoritative source of vulnerabilities exploited in the wild. Reviewers also ask for the latest penetration test report, a SOC 2 report if one exists, and proof that no secrets sit in the repository history. They also ask how customers' personal data is stored, shared and deleted, a question this review shares with the legal one. Our guides to penetration testing for startups and SOC 2 for startups explain what each report does and does not show.

To judge how the team builds, a reviewer can map its habits to the Secure Software Development Framework (SSDF), NIST SP 800-218. Version 1.1 dates from February 2022, and NIST published a draft of version 1.2 in December 2025.

Architecture and code quality. The reviewer checks that the architecture diagram matches the running system, that automated tests cover the paths that earn revenue, and that a new engineer can build the product from the written instructions. A deal review samples the code. Where it finds trouble, code audit services go deeper and rank what to fix first.

Infrastructure and cost. Twelve months of cloud bills show whether cost grows faster than usage. Runtime, framework and database versions are checked against their end-of-life dates, and our software end-of-life tracker lists those dates for a common startup stack. A backup only counts once someone has restored it in a test.

Software due diligence checklist

This checklist has 24 checks: 4 on code ownership, 4 on open-source licences, 5 on security, 4 on architecture, 3 on infrastructure and 4 on team and process. Each one names something a seller can hand over.

Code ownership and IP

• A signed IP assignment for every employee, contractor and agency in the repository history
• Founders' work from before incorporation assigned to the company
• Commercial licences and API terms that survive a change of ownership
• A written policy on AI coding tools and the terms they were used under

Open-source licences

• An SBOM in SPDX or CycloneDX format, generated from the current build
• A licence recorded for every component, with none missing
• Copyleft components listed with how each one is used and distributed
• A named owner for licence compliance

Security

• Dependency scan results, with known exploited vulnerabilities fixed
• A penetration test report from the last 12 months, with retest results
• No secrets in the repository or its history
• Evidence that one customer cannot read another customer's data
• An incident log, and what changed after each incident

Architecture and code quality

• An architecture diagram that matches the running system
• Automated tests on the paths that earn revenue
• A build that a new engineer can run from the written instructions
• A ranked list of known technical debt

Infrastructure and cost

• Cloud bills for the last 12 months, by service
• Runtime, framework and database versions with their end-of-life dates
• A backup that has been restored in a test

Team and process

• A list of who has production access, and why
• More than one person able to deploy and to recover the system
• Deployment records that show how often changes ship and how often they fail
• Documentation for the parts only one person has touched

The software due diligence questionnaire

A software due diligence questionnaire is the written list of questions a buyer sends the seller before anyone opens the code. Strong answers attach a document. Weak answers describe one.

The questionnaire screens the deal early and sets the scope of the review. Its answers are checked against the code later, so an answer the code contradicts becomes a finding of its own. Typical questions, one per area:

• Who has written code for the product, and is there a signed assignment for each of them?
• Can you provide a current SBOM, and which copyleft components does it list?
• When was the last penetration test, and which findings are still open?
• Which parts of the system have no automated tests?
• Which runtime and framework versions are in production, and when does support for each end?
• Who can deploy to production, and who can restore the system from a backup?

If you are the seller, answer with the document and say plainly when one does not exist. "We do not have this yet" is an ordinary finding. An answer that turns out to be wrong puts every other answer in doubt.

How findings change the deal

A finding reaches the deal in one of four ways: a fix before closing, a change in price, a protection in the contract or a cost in the plan after closing. A finding does not have to end the deal.

• Fix before closing: missing paperwork, such as an unsigned IP assignment, that the seller can still collect.
• Price: work the buyer will have to fund, such as moving off a platform past its end of life.
• Contract protection: a risk that cannot be measured yet, which the lawyers cover with terms in the agreement.
• Plan after closing: hiring, documentation and rework that the buyer budgets for the first year.

Take an invented example. A buyer finds that a contractor wrote the billing module three years ago and never signed an assignment. If the contractor signs now, the finding closes. If the contractor cannot be found, the buyer prices a rewrite of that module or asks for protection in the contract.

The findings that do end deals are of a different kind: ownership that cannot be established at all, or a seller who knew about a problem and hid it.

How we run software due diligence

We run these reviews for investors and acquirers who need to know what they are buying, and for founders who want to see the findings before a buyer does. Senior engineers read the code themselves, and the report separates deal-breakers from ordinary engineering debt.

Every review is scoped to the deal, so an early investment gets a few sharp questions answered and an acquisition gets the full picture. Every engagement is under an NDA, and the IP is always the customer's. The details are on our page for Technical due diligence services for investors and founders.

Frequently asked questions