Subprocessors in a data licensing transaction: who touches your data

Who are the parties in a data licensing chain?#

The parties in a data licensing chain are the supplier that owns the records, anyone who prepares them, any intermediary that manages the transaction, the licensee that uses them and the licensee's own vendors. Each one may in turn use subprocessors, such as cloud hosts, de-identification tools or annotation contractors.

Read the table as a map from left to right. The key question at each row is which version of the data that party sees: raw exports, working copies or the released de-identified package.

Why does the fourth party matter?#

The fourth party matters because it is the one your contract does not reach directly. You sign with the licensee; the licensee signs with an annotation vendor; that vendor may use freelance reviewers. Unless your license requires flow-down terms, those parties have no obligation to you.

Use limits are where this bites. A license that restricts use to model training, bans re-identification and requires deletion at term end protects little if a labeling contractor keeps copies on personal laptops. Under the CCPA definition of deidentified information, a business holding the data must contractually obligate recipients to comply with the no-re-identification requirements, so flow-down is part of keeping the data de-identified, not only good hygiene.

Flow-down also decides who answers when something goes wrong. If an annotation contractor leaks a subset, the licensee should be responsible to you for that vendor's conduct, as if the vendor were the licensee itself. Without that clause, you may have no contractual path to the party that caused the problem.

What controls belong at each link?#

Controls at each link should match the version of data that party sees. Parties that touch raw records need the strongest set: named people, isolated environments, logging and fixed deletion dates. Parties that only see the prepared package need use limits, security terms and a ban on re-identification.

Write these into the license and ask the intermediary or preparer to confirm them in their own agreements.

• 1Supplier side: an isolated staging environment, named preparers and a written release approval.
• 2Preparer: a subprocessor list, no use of your data to train its own tools, and deletion of raw copies on a set date.
• 3Intermediary: access limited to metadata and samples unless delivery requires more, and a documented chain of custody.
• 4Licensee: permitted use, no re-identification, no onward transfer without consent, security standards and deletion at term end.
• 5Licensee vendors: flow-down of the same terms, notice to you of new vendors handling the data, and audit or certification rights.

What to ask for in a subprocessor list#

A useful subprocessor list names the company, its function, the data version it handles and where it processes the data. Generic lists that say cloud hosting provider or analytics vendor tell you little about risk.

Ask also how changes are handled. Many standard terms let a vendor add subprocessors with notice and an objection window, and that model works for licensed data too. Some tool vendors publish terms on whether their AI subprocessors may train on customer content; read those for every tool in the preparation path.

Illustrative: an engineering firm maps its chain#

Illustrative: a fictional engineering and architecture firm plans to license internal RFI logs, submittal reviews and project scheduling records from Procore and Deltek, excluding client deliverables. Its general counsel asks every party for a subprocessor list before signing.

The preparer lists a cloud host and a text-redaction tool, and confirms the tool vendor is barred from training on inputs. The licensee lists its training infrastructure and one annotation vendor. Counsel adds a flow-down clause, a ban on onward transfer and notice of any new vendor that sees the data. The firm's managing principal approves release only after each list is attached to the license.

Mistakes that leave the chain open#

The most frequent mistake is negotiating hard with the licensee and ignoring the preparation vendors, who often see the raw data. A de-identification tool with weak terms can expose more than any licensee.

The second mistake is assuming a security report covers everything. A SOC 2 report covers a defined scope; confirm that the systems handling your records are inside it, and ask what the vendor relies on from its own subprocessors.

A third mistake is forgetting the supplier's own vendors. The managed IT provider that runs the export, the consultant who writes the scrubbing scripts and the help desk vendor whose API delivers the tickets all touch raw records before any licensee does. List them alongside the licensee's vendors so the map starts at the source system, not at the contract.

Finally, lists go stale. A subprocessor list attached at signing says nothing about a vendor added midway through the license. Tie the list to a notice obligation and review it at each renewal or new delivery, and record the reviewed version in the deal file.

How SourceX approaches the chain#

SourceX maps parties as part of the Rights and Approval steps of the SourceX five-step transaction, so the supplier sees who will touch which version of its records before approving anything. Nothing is shared during the initial assessment, and the supplier approves every release.

The SourceX Evidence Packet records permitted use, the privacy record and release authorization for each package. Those terms are what flow down to the licensee and its vendors, and the packet gives every party the same reference for what was agreed.