Auditing customer data terms across acquired vertical SaaS products

What does a customer data terms audit need to answer?#

A customer data terms audit needs to answer one question for each acquired product: which records, if any, the contracts allow the company to license to an AI developer, and on what conditions. The answer is rarely the same across a vertical software group, because each product arrived with its own founder-era terms, its own enterprise riders and its own history of updates.

Separate two kinds of records before reading a single clause. Customer content is what customers put into the product: work orders, inspection reports, invoices, scheduling notes and uploaded files. Company records are what the product team created while running the business: Zendesk or Intercom tickets, Jira and Linear issues, GitHub pull request reviews, release notes and internal Slack or Confluence threads.

Customer terms mainly govern the first kind, although company records often quote customer content and need the same scrutiny where they do. Treat the audit as a way to organize the review, not as a legal opinion; contract interpretation turns on wording and state law, so counsel signs off on each product's conclusions.

The six clause types that decide what is licensable#

The six clause types that decide what is licensable are the definition of customer data, aggregated data rights, usage data rights, feedback rights, AI and machine learning use, and deletion or return. Read them together, because a generous clause in one place can be cancelled by a narrow definition in another.

One reading mistake causes most false positives. An aggregated data clause written for benchmarking dashboards often reads as permitting statistics across customers, not the transfer of record-level text such as individual work orders or notes, even after names are removed. Ask counsel whether the wording reaches record-level de-identified data before counting it as a license right.

Which document controls when terms conflict?#

The document that controls is usually set by an order-of-precedence clause, and in most acquired products a signed agreement overrides the online terms for the customers who signed it. Map the hierarchy per product before reading clauses in isolation.

Update clauses deserve their own line in the worksheet. Many founder-era terms say the company may change the terms by posting a new version, but whether a later change reaches records collected under the earlier version depends on the wording, the acceptance method and state law. Record every version you can find, with dates, and flag gaps where no archived copy exists.

Build the audit worksheet#

The audit worksheet should hold one row per product and terms version, plus one row for each customer on negotiated paper. Holding companies that keep it beside the group's system inventory can see rights and records side by side.

Quote the clause text in the worksheet rather than paraphrasing it. Paraphrase is where most errors enter, and a buyer's diligence team will ask for the exact language anyway.

• 1Product, contracting entity and the acquisition it came from.
• 2Terms version, effective dates, acceptance method and where the archived copy is stored.
• 3Customers on negotiated MSAs, riders or data processing agreements, each listed by name.
• 4A quoted clause and a one-line reading for each of the six clause types.
• 5Order-of-precedence and update clause wording.
• 6Record families affected: customer content, support tickets, engineering history, usage logs.
• 7Conclusion per record family: candidate, candidate with exclusions, or excluded.
• 8Reviewer, review date and open questions for counsel.

Findings that come up across acquired products#

The findings that come up most across acquired vertical SaaS products are template terms, missing version history and enterprise riders nobody tracked. Founders often adapted another company's terms at launch, so the definitions may not fit the product they actually built, and older versions were overwritten on the website without being archived.

Untracked riders are the second pattern. A large customer may have negotiated a no-training clause or strict confidentiality in a rider stored in the sales team's shared drive rather than the contract system. Search Salesforce or HubSpot attachments as well as the legal folder, or the audit will miss the customers most likely to object.

The third pattern is records that should no longer exist. If a churned customer's agreement required deletion at termination and the data is still in the production database or backups, the next step is a remediation plan with counsel, not a licensing discussion.

Illustrative: three acquired products, three answers#

Illustrative: a fictional vertical software holding company reviews three products it acquired over several years: a reporting tool for home inspectors, a parts and repair-order system for independent auto repair shops, and a membership billing product for fitness studios.

The inspection tool's terms define customer data to include every report and photo, limit use to providing the service and say nothing about aggregation, so customer content is excluded. Its Freshdesk tickets and the GitHub issues they reference are company records, and they move forward as a candidate once customer names, addresses and screenshots are removed.

The repair-order system's terms allow de-identified aggregated data for any business purpose. Counsel reads that as covering parts demand statistics but not individual repair-order notes, so the group lists the statistics as a possible offering and parks the record-level notes. The fitness product's records are mostly member personal and payment details, and the group leaves that product out of the review.

How SourceX uses a terms audit#

SourceX uses a terms audit as the main input to the Rights step of the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The fit check starts from metadata, such as product names, systems, record families and known contract restrictions, and nothing is shared during the initial assessment.

When a record family proceeds, the clause readings and excluded customers are recorded in the SourceX Evidence Packet under licensing rights and permitted use, so the holding company, the product's signer and the buyer work from one documented basis for what was licensed.