Technical due diligence checklist for selling a SaaS company

What does technical due diligence cover in a SaaS sale?#

Technical due diligence in a SaaS sale covers whether the product works as represented, whether the company owns it, whether it is secure and whether its data can be used as the buyer plans. The buyer's engineers or an outside firm usually review documents, run code scans and interview the CTO and senior engineers.

Data rights and AI use are the newer areas, and many sellers arrive less prepared for them than for code and security questions. The checklist below covers all five areas in 25 items, grouped so each can be assigned to an owner.

Code ownership: items 1 to 5#

Code ownership items show that every part of the product belongs to the company or is properly licensed to it. Buyers check these first because a gap goes to the core asset being acquired.

Ownership questions are legal ones. This checklist is general information, not legal advice, and counsel should review any gap before it is disclosed or fixed.

• 1Signed invention assignment agreements for every current and former employee who wrote code.
• 2Written IP assignments from contractors, agencies and offshore teams, matched to the work they did.
• 3Records showing that IP from any acquired company or product was assigned to the selling entity.
• 4Development agreements with customers, with any customer-owned modules identified.
• 5A list of repositories, what each contains and which entity owns it.

Open source and third-party code: items 6 to 10#

Open source items show that the company knows which outside code it uses and meets each license's conditions. A buyer's scan will find the components anyway, so a prepared inventory with context is faster than answering findings one at a time.

• 1A software composition analysis report covering every production repository.
• 2A license inventory flagging copyleft licenses such as GPL and AGPL, and how each component is used.
• 3Notices and attributions shipped with the product, where licenses require them.
• 4Commercial third-party SDKs and components, with their license terms and any transfer restrictions.
• 5A written open source policy and evidence that code review follows it.

Security and operations: items 11 to 15#

Security items show that controls exist and operate, not only that policies were written. Recent reports and test results carry more weight than descriptions of intent.

Secret scanning deserves attention beyond the repositories, because credentials pasted into a chat thread or wiki page are as exposed as those committed to code. Some scanners cover those places too: TruffleHog, an AGPL-3.0 open-source scanner, scans sources including Git, chats, wikis, logs and object stores.

• 1The latest SOC 2 report or equivalent attestation, with any exceptions and how they were resolved.
• 2Recent penetration test reports and remediation records.
• 3Incident history, including security incidents, customer notices and postmortems.
• 4Secret scanning results across code, chat and wiki tools, with rotation records for anything found.
• 5Architecture, hosting, backup and recovery documentation, including evidence of tested restores.

Data rights: items 16 to 20#

Data rights items show where the company's data came from, what it may be used for and what has already been granted to others. Buyers planning AI features or data licensing will probe this area hardest.

Provenance standards can help organize the work. The Data & Trust Alliance's Data Provenance Standards group dataset metadata into Source, Provenance and Use, which lines up with the questions a buyer will ask about each data set.

• 1A data map of systems, record families, years of history and owners, separating customer data from company records.
• 2Customer contract definitions of customer data, usage data and aggregated data, with any negotiated riders that restrict use.
• 3Privacy notices and consents in force when each data set was collected.
• 4De-identification methods used for any data shared outside the company, with review records.
• 5Every prior data license, with scope, exclusivity, term and obligations that survive a sale.

AI use: items 21 to 25#

AI use items show where AI runs in the product and the business, and on what rights. Buyers want to know that features will not need to be rebuilt or switched off after closing.

Answer these in writing even if the honest answer is that AI use is limited. A short, accurate statement is easier to diligence than silence, which buyers tend to read as an unknown.

• 1A list of AI features, the models and providers behind them, and their subprocessor status.
• 2Provider terms on retention and training, and whether customer data trains any model.
• 3Records of any training data used for in-house models, with sources and rights.
• 4An internal policy on AI-assisted coding and how generated code is reviewed.
• 5Any AI training licenses granted to outside developers, with term, exclusivity and deletion duties.

Illustrative: a yard management software company prepares for sale#

Illustrative: a fictional company selling yard management software to distribution centers prepares for a sale process. Its CTO works through the checklist and finds three gaps: an early agency with no IP assignment, an AGPL library in an internal tool, and an earlier AI training license for its engineering history with no summary prepared.

Outside counsel secures a signed confirmatory assignment from the former agency. The AGPL library is confirmed to run only in an internal reporting tool and documented in the license inventory. The CTO writes a one-page summary of the training license: non-exclusive, limited to coding model training and evaluation, customer data excluded, deletion at term end.

When the buyer's diligence team asks about data and AI, the answers and supporting documents are already in the data room. The prior license becomes a reviewed line item rather than a late surprise.

How SourceX documentation supports diligence#

SourceX documentation supports diligence because every package licensed through the SourceX five-step transaction comes with a SourceX Evidence Packet. It records provenance, licensing rights, permitted use, the privacy record and release authorization in one place.

For a seller, the packet answers the prior-license items with documents rather than recollection. For a buyer, it shows exactly what was licensed, what was excluded and who approved the release.