Customer DPAs and de-identified data: what secondary use is allowed?

What does a customer DPA allow beyond running the service?#

A customer DPA allows very little beyond running the service unless it says so expressly. Most DPAs cast the vendor as a processor or service provider that handles personal data only on the customer's documented instructions, so any secondary use, including building datasets or licensing records, has to come from a carve-out in the text.

Carve-outs exist because vendors need some room to secure the platform, produce benchmarks and improve the product. Most were drafted with analytics in mind rather than AI training data, which is why they need a careful read before anyone relies on them.

Look in four places: the definitions, the clause on the customer's processing instructions, the annex describing the nature and purpose of processing, and the clause on what the vendor may keep after termination. Carve-outs are often split across them, and an annex that lists purposes narrowly can undercut a broader carve-out in the body.

How to read the common DPA carve-outs#

The common DPA carve-outs each answer a narrower question than their labels suggest. The table paraphrases typical wording and shows what each one usually reaches and where it usually stops.

Watch the structure as well as the words. Some DPAs say anonymized data falls outside the agreement entirely, which leaves the definition doing all the work. Others keep it inside the agreement but grant the vendor a license to use it, which adds purpose limits on top.

When is data de-identified enough for the carve-out?#

Data is de-identified enough for a carve-out only when it meets the definition in that specific DPA, and many definitions require that the data cannot reasonably be linked back to an individual or a customer. Stripping names and email addresses from a support ticket rarely meets that bar alone, because free text carries job titles, locations, order numbers and distinctive events.

Privacy teams measure re-identification risk rather than assume it away, and mainstream tooling reflects that: Google's Sensitive Data Protection API offers k-anonymity, l-diversity, k-map and delta-presence risk analysis. Automated detection has limits too. The open-source Presidio project warns that its automated detection cannot guarantee finding all sensitive information, so human review stays part of any defensible method.

Customer identity matters as well. A ticket can be anonymous about people and still reveal which customer it came from through product names, configuration details or unusual workflows, and many MSAs protect the customer's confidential information alongside personal data.

State privacy laws may set their own floor as well. Under the California Consumer Privacy Act as amended by the CPRA, information counts as deidentified only if the business takes reasonable measures so it cannot be associated with a consumer or household, publicly commits to keep it deidentified and not attempt reidentification, and contractually obligates any recipients to do the same. Where a law like that may apply, a license would need to carry the no-reidentification obligation to the licensee.

A four-part decision rule before any secondary use#

A four-part decision rule keeps the analysis honest. Each part must pass under every customer agreement that governs the records, and a failure on any part ends the inquiry for that customer's data.

Where all four pass, document the reasoning and the version of each agreement relied on. Where any part fails, the usual route is consent: a short addendum naming the record types, the method and the permitted recipient.

• 1Definition: do the actual records meet the DPA's own definition of aggregated, de-identified or anonymized data?
• 2Purpose: does the intended use fit the purpose the carve-out names, such as improving the services, or go beyond it?
• 3Recipient: does the carve-out allow disclosure to a third party, or only use by the vendor itself?
• 4Conflict: do the MSA, an AI rider, the privacy notice or a negotiated side letter forbid what the DPA seems to allow?

Why processor status narrows what you can do#

Processor status narrows what a vendor can do because the role is defined by acting for the customer. Under GDPR and similar frameworks, a processor that starts using personal data for its own purposes may be treated as a controller for that use, with obligations of its own, and some US state privacy laws draw a comparable line for service providers.

That is why licensing at SaaS companies usually starts with company-owned records, such as engineering history, internal documentation and product decisions, rather than customer data. Those records are not processed on anyone's instructions, although they still need personal and customer details removed before anything moves.

Data that is not personal data at all, such as system telemetry without user identifiers, may sit outside the DPA, but the MSA usually still governs it as customer data or usage data. Check both agreements before treating any category as free to use.

Illustrative: a returns management software company reads three DPA versions#

Illustrative: a fictional returns management software company serves online retailers. Over the years it has used three DPA templates: the first says anonymized data falls outside the agreement, the second lets the vendor use de-identified data to improve the services, and the third, adopted for enterprise deals, adds a flat ban on AI training.

An AI developer shows interest in support conversations about return disputes. Counsel runs the four-part test per template. Under the third template the answer is no. Under the second, purpose and recipient fail, because licensing to another company is not improving the vendor's services. Under the first, the definition is the obstacle: the conversations hold shopper names, order numbers and retailer-specific details that removal scripts miss.

The company decides not to license customer conversations. It offers instead its internal escalation notes and the linked engineering fixes, with retailer and shopper details removed, and records why none of the DPA templates reaches them.

How SourceX approaches DPA carve-outs#

SourceX reviews DPA templates and negotiated versions in the Rights step of the SourceX five-step transaction, and the Preparation step removes personal and confidential details from whatever remains in scope. The fit check needs only metadata, such as which templates exist and roughly how many customers sit on each.

When a package proceeds, the SourceX Evidence Packet records the rights analysis, permitted use, the privacy record of what was removed and how, and release authorization, so the reasoning behind each carve-out decision stays attached to the data.