---
title: "SaaS Acquisition Legal Due Diligence Checklist for Buyers"
description: "A SaaS buyer’s legal due diligence checklist: documents to request, IP and contract risks to investigate, and issues to resolve in the purchase agreement before closing."
canonical: "https://acquisitionstars.com/blog/saas-acquisition-legal-due-diligence-checklist"
author: "Alex Lubyansky"
firm: "Acquisition Stars"
practice: "M&A and securities law"
office: "Novi, Michigan (serves clients nationwide)"
contact: "consult@acquisitionstars.com | 248-266-2790"
---

# SaaS Acquisition Legal Due Diligence Checklist for Buyers

**SaaS legal due diligence asks whether the buyer can acquire and operate the software business on the terms assumed in the deal.** Start with ownership of the product, contributor assignments, third-party licenses, customer transfer rights and data obligations. Record the evidence, unresolved question and proposed closing action for each issue. Revenue verification and technical testing are separate workstreams that should inform these legal decisions.

This checklist is for a buyer with an identified software target, whether it is a first acquisition or an addition to an existing platform. For the wider transaction process, use our [technology and SaaS M&A guide](https://acquisitionstars.com/blog/technology-saas-ma-guide).

## Have a target and a diligence deadline?

Tell us the business you are buying, the proposed asset or equity structure, your deal stage and the legal question holding up the next step.

[Request Engagement Assessment](https://acquisitionstars.com/consultation)

## The document-to-risk-to-closing-action matrix

Ask for executed documents and amendments, not just templates or a folder marked “IP.” Use this as an initial request list, then tailor it to the product, customers, jurisdictions and transaction structure. Record “not provided” separately from “reviewed with no issue identified.”

| Workstream | Documents to request | Question to resolve | Possible closing action |
| --- | --- | --- | --- |
| Software ownership | Product and repository list; prior acquisition documents; founder IP transfers; registrations; liens and licenses granted to others. | Does the seller own the rights being sold, and are important assets held by a founder or another entity? | Identify the correct transferring parties, required assignments and lien releases. List excluded or licensed assets expressly. |
| Employees and contractors | Contributor roster mapped to code; signed employment, consulting and invention-assignment agreements; agency contracts; departures and disputes. | Is there a documented chain from each material contributor to the seller, including subcontractors? | Obtain missing assignments where available, investigate competing claims and decide which gaps must be resolved before closing. |
| Third-party software and open source | Dependency inventory and scan findings; applicable license versions; commercial SDK, API and hosting agreements; notices and source offers. | Can the buyer continue the actual use, distribution and hosting model, and what obligations or approvals follow? | Agree on consent, replacement or remediation tasks, with technical validation and a named owner. Document continuing license obligations. |
| Customer contracts | Executed agreements, order forms, amendments, side letters, DPAs and SLAs; renewal dates; credits, complaints and termination notices. | Which customers have assignment, change-of-control, termination, price-adjustment or other rights affected by the proposed deal? | Build a customer-specific consent and notice schedule. Negotiate required consents, closing conditions and treatment of unresolved exceptions. |
| Data and privacy | Data map; current and historical privacy notices; customer processing terms; subprocessor list; incident records and regulator correspondence. | Are proposed transfers and post-close uses consistent with contracts, prior promises and applicable privacy requirements? | Separate permitted use from changes needing further review. Plan required notices, consents, contract updates and remediation before integration. |
| Disputed and unresolved issues | Claims, demand letters, settlements, security findings, insurance notices and the seller’s outstanding remediation list. | Who bears the known exposure, what remains uncertain, and could the issue affect continued operation? | Escalate to the buyer’s decision maker. Negotiate a cure, specific risk allocation, revised economics or a closing condition as appropriate. |

## Verify ownership beyond access to the repository

Administrator access, payment of a development invoice and copyright ownership answer different questions. Under U.S. law, transferring a copy of a work does not itself transfer copyright, and a voluntary transfer of copyright ownership generally requires a signed writing. Review what the seller actually acquired, from whom and for which product versions. See [17 U.S.C. §§ 202 and 204](https://www.copyright.gov/title17/92chap2.html).

Do not assume that every contractor’s work is automatically owned by the company. The employee and commissioned-work routes to “work made for hire” have different requirements. Match contributor status and signed documents to the work involved, including contributions from a development agency’s subcontractors. The [Copyright Office’s work-made-for-hire circular](https://www.copyright.gov/circs/circ30.pdf) explains these distinctions.

A missing assignment should produce a specific follow-up: who may hold the rights, whether they can be reached, what needs to be signed and whether the product can be operated if the gap remains. A seller representation alone does not obtain a missing third party’s rights.

## Tie license review to how the software actually runs

Have the technical team connect the dependency inventory to deployment, modifications, distribution and customer delivery. Counsel can then assess the applicable license language. An open-source component’s presence is a starting point for review, not an automatic conclusion that the whole product must be disclosed.

For example, [AGPL version 3, section 13](https://www.gnu.org/licenses/agpl-3.0.html#section13) addresses source availability for modified programs used through remote network interaction. Whether a particular integration creates an obligation needs analysis of the license and implementation. Commercial API and SDK contracts require a separate review of transfer restrictions, usage limits and pricing changes.

## Review customer rights and the planned use of data together

Read assignment and change-of-control clauses against the proposed structure and governing law. An equity deal is not a universal shortcut around customer approvals. Link each relevant contract to the affected customer, renewal timing, notice method and person responsible for obtaining consent. Our [SaaS customer-contract assignment guide](https://acquisitionstars.com/blog/saas-customer-contracts-ma-assignment) examines that workstream in more depth.

For data, compare the buyer’s integration plan with historical promises as well as current documents. In its Facebook/WhatsApp acquisition guidance, the FTC emphasized that privacy promises continued to matter after the acquisition and warned about changes to previously collected data. That example supports checking the target’s own promises; it does not establish one consent rule for every SaaS transaction. See the [FTC’s acquisition privacy guidance](https://www.ftc.gov/news-events/news/press-releases/2014/04/ftc-notifies-facebook-whatsapp-privacy-obligations-light-proposed-acquisition).

Record which entity processes which data, on whose instructions and for what purpose. An ownership change, a change of processing entity and a new use of customer data can require different analyses. Identify applicable requirements before combining datasets or changing subprocessors.

## A missing assignment or consent is a deal decision

Our [SaaS acquisition counsel](https://acquisitionstars.com/services/technology-saas) can discuss how an identified issue affects diligence scope, purchase documents and the closing sequence.

[Submit Transaction Details](https://acquisitionstars.com/consultation)

## Turn findings into a buyer decision log

In a discussion of his transaction approach, Alex Lubyansky says, “I’m of the mind that every deal is different.” [Watch the discussion at 20:09](https://www.youtube.com/watch?v=6megSCwsPsA&t=1209). The practical application here is to prioritize what this buyer needs to own and operate, rather than treating every missing document as equally important.

1. **Resolve before the buyer commits:** an uncertain right to core code, a known threat to a critical customer relationship or a license incompatible with the planned product. Identify the evidence needed for the buyer to decide whether to proceed.
2. **Resolve between signing and closing:** an agreed assignment, third-party consent or remediation deliverable. Specify who must act, the deadline, acceptable evidence and the contractual consequence if it is not completed.
3. **Accept and allocate expressly:** a known issue the buyer is willing to take with negotiated economics or contractual protection. Record the decision; do not bury it in a general disclosure folder.
4. **Carry into a post-close plan:** an item that can appropriately wait, with an owner and date. Distinguish a permitted integration task from a missing right required to operate at closing.

Keep these columns in the log: issue ID, document or evidence link, affected asset/customer, open question, legal and technical owner, proposed resolution, buyer decision and completion evidence. If a row is marked resolved, a later reviewer should be able to see why.

### A worked example: the unavailable former developer

Suppose repository history shows a former contractor wrote a core module, but the seller supplies only invoices. This is an illustrative scenario, not a client account. First, ask for the consulting agreement, assignments and any agency records. Next, have counsel assess the rights and have the technical team identify where the contribution is used. If documents do not establish the required rights, evaluate obtaining them, replacing the module or changing the transaction terms. Record the buyer’s decision and any closing dependency. Do not label the row complete merely because the seller answered the request.

## What to share when requesting SaaS acquisition counsel

Start with a short description of the target, whether you are buying assets or equity, the LOI or draft-agreement stage, the expected timetable and the issues already identified. If this is an add-on, explain what you intend to integrate and what will remain separate. An initial assessment can establish the legal scope and the coordination needed with your financial and technical advisers.

This checklist provides general information. The documents and legal analysis needed depend on the transaction, contracts and applicable law.

---

Source: https://acquisitionstars.com/blog/saas-acquisition-legal-due-diligence-checklist

Markdown version generated for machine readers. Canonical HTML at the source URL.