Customer data vs company data: what a SaaS company can actually license

What is the difference between customer data and company data?#

The difference between customer data and company data is who created the record and which contract governs it. Customer data is what customers put into or create in your product; company data is what your own team creates while building, selling and supporting that product. Most SaaS terms state the first point plainly: Slack's Supplemental Terms, for example, say the customer retains all ownership of its Customer Data.

A third class sits between them. Service-generated data, such as logs, usage events, performance metrics and model outputs, is produced by your system as customers use it. Contracts treat it inconsistently, which is why it causes the most disagreement inside SaaS companies.

Thinking in three classes rather than two prevents the most common error in early licensing conversations: assuming that anything stored in your infrastructure is company data because your company pays for the servers. Hosting a record and controlling it are separate questions, and the contracts answer the second one.

The three-class framework for SaaS records#

The three-class framework for SaaS records sorts each record family by source and states its default position. Your own agreements set the final answer, but most SaaS contracts follow this pattern closely enough to make it a reliable first cut.

Read the table by column, not by row. Each class has its own deciding document and its own decision-maker, which is why the classes are reviewed separately even when the records sit in the same database.

Where do the gray zones appear?#

Gray zones appear wherever a company-created record quotes, attaches or summarizes customer content. These records are often the most valuable in the archive, because they show your team solving a customer's real problem from report to fix.

The usual resolution is to keep your team's work and remove the customer's material. That preserves the diagnosis, reasoning and outcome that AI developers care about while leaving customer content where the contract says it belongs.

When can service-generated data be licensed?#

Service-generated data can be licensed when the contract gives the vendor rights in it and the licensed form no longer reveals any customer's content or identity. Error traces and application logs often fail the second test, because they capture fragments of what users typed or uploaded.

Aggregated metrics, such as how long a workflow step takes across all customers, pass more easily but carry little training value on their own. Detailed event streams carry more value and more risk. Counsel should read the usage data clause for its stated purposes, check whether it allows disclosure to third parties, and confirm that de-identified outputs cannot be linked back to a customer.

Why buyers care which class a record belongs to#

Buyers care which class a record belongs to because the class determines whether the supplier can prove it had the right to license the record. AI developers increasingly ask for provenance and permitted-use documentation before accepting a dataset, and a package that mixes classes without labels is slow to clear their review.

Published standards point the same way. The Data and Trust Alliance's Data Provenance Standards organize dataset metadata into Source, Provenance and Use groups, which the specification describes as necessary for proper dataset selection for AI model training. A clean three-class sort makes that kind of documentation straightforward to produce.

How to sort your record families#

Sorting record families takes a working session with the CTO, head of support and counsel, using metadata only. No exports are needed to make the first cut, and the result can be tested by counsel before any data moves.

The output is a short map of systems, record families, classes and governing clauses. That map later becomes the backbone of a data inventory and the rights section of any license.

• 1List each system that holds records: GitHub or GitLab, Jira or Linear, Zendesk or Intercom, Salesforce or HubSpot, Slack, Confluence or Notion, and the product database.
• 2For each system, name the record families it holds, such as pull requests, incident reports or ticket threads.
• 3Assign each family to one of the three classes, and mark gray-zone families separately.
• 4Write down the clause or policy that governs each class, citing the version of the customer terms in force when the records were created.
• 5Flag records from acquired products, contractors and resellers for separate review.
• 6Choose the company-created families with the deepest linked history as the first scope.

Illustrative: a landscaping software company draws the line#

Illustrative: a fictional maker of routing and crew scheduling software for commercial landscaping companies runs the sort. Its product database holds customers' property lists, crew schedules and service histories, all classed as customer content and left out.

Route optimization logs and feature usage events are service-generated. The customer agreement allows use of aggregated, de-identified usage data to improve the service, so counsel concludes they can inform the company's own product work but should not be licensed in raw form.

Company-created records carry the package: years of GitHub pull requests and code reviews on the routing engine, Jira issues linked to Intercom conversations, and Confluence design documents. Property addresses pasted into bug reports are stripped, and the company proceeds with that scope.

How SourceX applies the framework#

SourceX applies the three-class sort in the Supply and Rights steps of the SourceX five-step transaction, before any preparation work begins. The SourceX Enterprise Data Value Framework then rates the company-created records qualitatively on drivers such as uniqueness, domain expertise, human-generated signal, recency, rights and AI utility, weighed against preparation cost and privacy burden.

Each package that proceeds is documented in a SourceX Evidence Packet: provenance, licensing rights, permitted use, the privacy record and release authorization. The supplier approves every step, and the company keeps ownership because the records are licensed, not sold.