Processor or controller? Why SaaS companies usually can't license customer personal data

What do processor and controller mean for a SaaS vendor?#

A processor, in GDPR terms, handles personal data on behalf of a controller that decides why and how it is processed; a controller makes those decisions for itself. US state laws such as CCPA use related terms, service provider and business, with their own definitions.

For a SaaS vendor, the role is assigned per dataset and per purpose. The same company is usually a processor for the records its customers store in the product and a controller for its own employee, billing and sales records. Licensing questions turn on which role the company plays for the specific records involved.

Roles also follow facts, not labels. A DPA that calls the vendor a processor helps, but if the vendor in practice decides to reuse data for its own ends, regulators and customers may look at what it actually did rather than what the paper said.

Role table: which records sit where#

The role a SaaS company plays varies across its record families, and the licensing implication follows the role. The table reflects common patterns; your contracts and facts decide the actual answer.

Mixed rows are common in support. The vendor runs the support relationship for its own purposes, but the customer data pasted into a ticket is still customer data, and both can sit in the same record.

Why is licensing customer personal data a new purpose?#

Licensing customer personal data to an AI developer is a new purpose because it serves the vendor's commercial interest and a third party's model, not the customer's instructions. Processor and service provider rules are generally written to keep vendors inside the customer's purposes.

Some laws allow service providers limited internal uses, such as improving their own services, but those allowances are narrow and generally do not reach handing data to another company for its own models. A processor that steps outside its role may take on controller obligations for that processing and breach its DPA at the same time.

The DPA usually reinforces the point with purpose limits, sub-processor approval rights and audit clauses. Even where a privacy law left some room, the contract often would not.

Where does controller status still leave limits?#

Controller status for a record family does not make it freely licensable. As controller, the company decided why it collected the data and told people something about it, and those statements still bind.

The practical test is whether the original notice and purpose cover sharing with an AI developer. If not, the options are exclusion, de-identification assessed with counsel, or fresh notice where that is appropriate and workable.

• 1Employee messages and email: handbook, privacy notices and employee rights under laws that may apply.
• 2Prospect and contact records in the CRM: marketing consent and privacy policy commitments.
• 3Support relationship data: what the privacy policy says about service communications.
• 4Job applicant records: notices given at application and retention limits.
• 5Any record naming customers: confidentiality obligations in customer agreements.

Which company records usually fall outside personal-data limits?#

The company records that usually fall outside personal-data limits are those about the work rather than about people: code, architecture decisions, issue histories, incident timelines and runbooks. They still need review, because author names, email addresses in commits and customer names in issue text are personal data or confidential details.

These records are often the most useful to AI developers, because they show how software is designed, built and fixed. A SaaS company that starts here avoids most processor questions entirely and spends its legal review on narrower issues such as secrets and customer mentions.

A useful exercise is to list each record family against three questions: who created it, whose purposes it served, and whether it names people. Records your staff created for your own purposes that name few people are the first candidates; records customers created for their own purposes are the last.

What should a role map record?#

A role map should record, for each record family, the role the company plays, the document that establishes it, and the licensing decision that follows. Keeping it in one place lets counsel, the CTO and any licensee follow the same reasoning.

Update the map when contracts, products or privacy notices change. A role that was clear under last year's DPA may shift after a new enterprise agreement or a product feature that collects different data.

• 1Record family and the system that holds it.
• 2The company's role for that family, with the contract or notice that establishes it.
• 3Personal data present and where it came from.
• 4Licensing decision: exclude, de-identify with counsel, or proceed.
• 5Reviewer, date and the next review trigger.

Illustrative: a fleet maintenance SaaS maps its roles#

Illustrative: a fictional fleet maintenance software company receives interest in its work order data, which includes technician notes, vehicle histories and driver names entered by customers. The general counsel maps roles before discussing any scope.

Customer work orders are processor data under the DPA, so they are excluded. Support tickets are split: the company's own diagnostic notes and linked Jira issues can proceed after redaction, while customer attachments are removed. Employee Slack channels are held for a notice review.

The scope that proceeds is engineering history, de-identified incident timelines and support resolutions written by the company's own staff. The customer work orders the inquiry was about never leave the platform, and the company tells the interested party so plainly.

How SourceX handles processor and controller questions#

As part of the Rights stage of the SourceX five-step transaction, SourceX maps roles record family by record family and writes the outcome into the privacy record of the SourceX Evidence Packet. Customer personal data processed on a customer's behalf is excluded unless the customer relationship and the law clearly support another path.

Most software packages that proceed are built from the company's own records, which keeps the transaction on the controller side of the line from the start and keeps customers out of the conversation.