Rights and contracts
Do you need a DPA when licensing de-identified data?
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
A DPA is usually not the right contract for licensing truly de-identified data: a data processing addendum governs a processor handling personal data on your instructions, and a buyer training its own models is not your processor. The license still needs DPA-like terms: a de-identification standard and a ban on re-identification. If personal data remains, controller-to-controller terms usually fit better.
Key takeaways
- A DPA governs processors acting on your instructions; a model developer licensing records for its own training is not acting on your instructions.
- Check the delivered dataset, not the source system: pseudonymized records with a retained key are generally still personal data.
- A de-identified license carries its own protections: a de-identification standard, no re-identification, no linkage and onward-transfer limits.
- Vendors that redact or host raw records for you are your processors, and that is where a DPA belongs.
- Signing a buyer's standard processor DPA for a training license can misdescribe the relationship.
Do you need a DPA to license de-identified data?#
A data processing addendum is usually not needed to license data that has been properly de-identified, and it is often the wrong document even when personal data remains. A DPA exists to govern a processor or service provider that handles personal data only on the controller's instructions. A model developer that licenses records to train its own models decides its own purposes, which is the opposite relationship.
The question still deserves care, because buyers often attach their standard DPA to the license draft, and privacy teams are trained to sign one whenever data moves. A processor DPA on a training license can create obligations neither side can meet and blur who answers to individuals and regulators.
A decision tree for the right agreement#
The right agreement depends on two questions asked in order: does the delivered dataset still contain personal data, and who decides what happens to it? Work through the steps for each package, because one supplier can have a de-identified package and a pseudonymized one under the same buyer relationship.
- Step 1: Examine the delivered dataset, not the source system. If names, contact details, identifiers and free-text mentions were removed under a documented standard, go to step 2. If pseudonymized data remains, or someone holds a key that links records back to people, go to step 3.
- Step 2: De-identified data. Use a data license with a de-identification schedule, a no-re-identification covenant and onward-transfer limits. A processor DPA with the buyer is usually unnecessary.
- Step 3: Personal data remains. Ask who decides purposes. A buyer training its own models typically acts as an independent controller, or a third party in CCPA terms, so controller-to-controller terms fit.
- Step 4: A vendor works on your behalf. A redaction vendor, hosting provider or labeling contractor that touches raw records only on your instructions is your processor and needs a DPA.
- Step 5: Cross-border or sensitive data. Where EU or UK personal data leaves its region, add a transfer mechanism, such as the EU standard contractual clauses or the UK equivalent, and exclude sensitive categories by default.
Which agreement fits which situation#
Matching the agreement to the situation is mostly a question of roles. The table below summarizes the common combinations a privacy lead sees when a licensing draft arrives.
GDPR Recital 26 says pseudonymised data that could be attributed to a person by using additional information should be treated as information on an identifiable person, so replacing names with tokens while keeping the lookup table does not reach step 2. US state laws use their own definitions of de-identified information, and which ones may apply is assessed deal by deal with counsel.
| Situation | Buyer's role | Agreement that usually fits |
|---|---|---|
| Records fully de-identified before delivery | Recipient of non-personal data | Data license with de-identification and no-re-identification terms |
| Pseudonymized records, key kept by the supplier | Often a controller of personal data, depending on the law | Controller-to-controller terms inside the license |
| Buyer trains its own models on records with personal data | Independent controller or third party | Controller-to-controller or data sharing terms |
| Vendor redacts or hosts raw records for you | Processor or service provider | DPA with that vendor |
| Buyer runs evaluations only for your benefit, on your instructions | Possibly a processor | DPA, if personal data is involved |
| EU or UK personal data leaves its region | Depends on the rows above | Add a transfer mechanism, such as the EU standard contractual clauses or the UK equivalent |
Clauses that do the DPA's job in a de-identified license#
A de-identified license still has to protect the people behind the records, so it carries clauses that do the work a DPA would do for personal data. They belong in the license itself or in a privacy schedule attached to it.
Some privacy laws make terms like these part of the definition itself. California's CCPA treats information as deidentified only if the business takes reasonable measures against re-identification, publicly commits to keep it deidentified, and contractually obligates any recipients to comply. A license without those terms can undermine the de-identified status it relies on.
| Clause | What it does |
|---|---|
| De-identification standard | Describes the method used and what was removed, so both sides know what was delivered |
| No re-identification | Bars attempts to identify any person or company in the records |
| No linkage | Bars combining the records with other data in a way that could identify people |
| Onward transfer | Allows sharing only with parties bound by the same terms |
| Discovery and notice | Requires the buyer to report, and stop using, any identifying detail it finds |
| Remediation | Lets the supplier replace or withdraw affected records |
| Security | Requires reasonable controls over the delivered files |
| End of term | Sets what happens to the delivered files when the license ends |
Why residual-risk clauses matter#
Residual-risk clauses matter because no de-identification process is perfect. Automated detection helps at scale, but the open-source Presidio project's own documentation warns that there is no guarantee it will find all sensitive information and that additional protections should be used.
Free text is where most residual risk sits. Ticket bodies, call notes and email threads mention people in ways structured fields never do, such as a nickname, a job title at a small customer or a home address typed into a comment, so the contract should assume an occasional detail may survive and say exactly what happens next.
That is the practical case for layered controls: automated scanning, human review of samples, exclusion of high-risk record types, and contract terms that make the buyer report and stop using anything identifying it finds. The DPA question is really a question about which of those controls live in the contract.
Illustrative: a SaaS privacy lead declines a processor DPA#
Illustrative: a fictional B2B SaaS company plans to license de-identified Zendesk tickets linked to Jira issues. Some tickets come from customers in the EU. The buyer's draft arrives with its standard processor DPA attached.
The privacy lead declines the DPA and explains why: the buyer will train its own models, so it cannot be a processor acting on the company's instructions. The license gains a privacy schedule instead, with the de-identification method, a no-re-identification covenant, a notice-and-withdraw process and onward-transfer limits. EU-origin tickets are held back from the first package until counsel settles the transfer analysis.
Separately, the company signs a DPA with the redaction vendor that handles raw tickets on its behalf. Each contract now matches the role the other party actually plays.
How SourceX handles the privacy paperwork#
SourceX settles agreement fit during the Rights and Preparation steps of the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. Personal and confidential details are removed before delivery, and the supplier approves the prepared scope.
The SourceX Evidence Packet includes a privacy record describing how records were de-identified and what was excluded, alongside provenance, licensing rights, permitted use and release authorization. That record is what a privacy lead points to when a regulator, customer or auditor asks how the data left the company.
Frequently asked questions
Is pseudonymized data the same as de-identified data?
Not necessarily. Pseudonymized data replaces direct identifiers with tokens, and if anyone holds the key or can link records back, many laws still treat it as personal data. De-identification removes identifiers so records cannot reasonably be linked to a person, which is a higher bar.
Can we sign the buyer's standard DPA to keep the deal moving?
Usually not. A processor DPA on a training license can create duties the buyer cannot meet, such as processing only on your instructions, and may misstate the relationship to regulators. Explain the roles, decline the processor terms and put the protective clauses in a privacy schedule to the license instead.
What is a controller-to-controller agreement?
It is a contract between two parties that each decide their own purposes for personal data. It covers lawful basis, transparency, security, onward transfers and how each side handles requests from individuals. It fits a license where personal data remains and the buyer uses it for its own purposes.
Who should keep the re-identification key, if there is one?
Ideally no one outside the supplier, and often no one at all. If a key exists, the data may still count as personal data in the supplier's hands and possibly the buyer's. Many suppliers destroy mapping tables after preparation unless a specific need justifies keeping them.
Does our role as a processor for our own customers change the answer?
It can. If the records came from customers who engaged you as their processor, their DPAs may limit any secondary use, including de-identified licensing. That question comes before the buyer agreement and is answered from your customer contracts.
Sources
- Presidio's documentation warns that because it uses automated detection mechanisms, there is no guarantee it will find all sensitive information, so additional systems and protections should be employed. Source
- GDPR Recital 26 states that personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information, should be considered to be information on an identifiable natural person. Source
- Under Cal. Civ. Code 1798.140(m), information is deidentified only if the business takes reasonable measures to ensure it cannot be associated with a consumer or household, publicly commits to keep and use it only in deidentified form and not to reidentify it, and contractually obligates any recipients to comply with these provisions. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.