Re-identification prohibition clauses in data licenses: what buyers will be asked to sign

Why suppliers cannot drop this clause

Suppliers usually cannot negotiate the clause away because the law ties their own position to it. Under the CCPA as amended by the CPRA, information counts as "deidentified" only if the business takes reasonable measures against re-identification, publicly commits not to re-identify, and contractually obligates recipients to comply [3]. Several later state laws use a similar three-part test, though the wording differs from state to state [4]. Nebraska's statute is one example that explicitly requires recipients to be bound by contract [5].

Health data follows a separate track. A HIPAA limited data set is still protected health information. It can be disclosed only under a data use agreement in which the recipient agrees not to identify the information or contact the individuals, to use appropriate safeguards, to report uses the agreement does not allow, and to bind its agents to the same restrictions [1]. Hospital DUA templates, such as Harris Health's, restate these terms [6].

Fully de-identified health data under Safe Harbor or Expert Determination is no longer PHI. Even so, an expert's risk conclusion often assumes recipient controls, which come back to you as contract terms [2]. For background on the legal categories, see de-identified vs anonymized legal definitions and the CCPA buyer obligations guide.

The clause family, sub-clause by sub-clause

A modern re-identification clause is really a bundle of separate obligations, often eight, and each one needs an owner on your side. Read each sub-clause as an operating requirement, not just a legal statement.

Illustrative example: invented to show structure; it does not describe an available dataset.

The last row is newer and appears in some AI training licenses. For background on why suppliers want it, see training-data extraction and memorization risk.

Linkage is where most buyers breach without noticing

Linkage prohibitions are breached far more often by ordinary data engineering than by anyone deliberately unmasking a person. A feature-store join, an entity-resolution pass in a dedup pipeline, or an analyst enriching records with a public dataset can each put quasi-identifiers back together. NIST's de-identification guidance treats the release environment and the other data available to a recipient as part of the risk, not just the transformed file [7].

The EU test points the same way. GDPR Recital 26 asks whether identification is possible using means "reasonably likely to be used," which includes data the recipient already holds [8]. If your organization has CRM or product telemetry about the same population, a linkage clause effectively blocks joins against it. Read the linkage and mosaic risk guide before you sign one.

Handle this by negotiating an explicit approved-join list rather than a vague "no linkage" ban you cannot audit. Name the allowed keys (for example, a supplier-issued record_token and a non-personal product_category) and require privacy review before any other join.

Inadvertent re-identification and the notice clause

The notice clause decides what happens when a person is identified despite everyone's good faith. Because redaction is imperfect, this is a realistic scenario and not an edge case. Even the Presidio project warns that ML-based PII detection gives no guarantee of finding all sensitive information [9], and residual names in free text, signatures in email threads, or rare job titles can identify people. See PII redaction for LLM training data and LLM-assisted re-identification.

A workable notice clause tells the licensee to stop processing the affected records, avoid recording or sharing the identity, notify the licensor within an agreed period, and follow the licensor's instructions on deletion or replacement. Push back on terms that call any inadvertent identification a material breach with immediate termination. A breach should require failing to notify or contain, not the discovery alone.

Get the remedy language in this clause to match the deletion and return clause so the two are consistent. If the affected records have already been used for training, say in advance whether deleting the source data is enough or whether the parties will negotiate further.

Controls you need before you sign

Compliance with a re-identification clause is shown by controls you can evidence, not by your intent. Before you sign, confirm that your platform team can produce each item below.

Illustrative example: invented to show structure; it does not describe an available dataset.

Pre-signature compliance checklist

• Dataset registered in your data catalog with a license_id, reid_prohibited: true, linkage_policy and contact_prohibited: true tags.
• Storage in a separate bucket or workspace with role-based access; no default read access for analytics groups.
• Access logs retained for the license term and reviewable on audit request.
• Join-approval workflow: any join outside the approved key list needs a ticketed privacy review.
• Training for every person with access (engineers, annotators, eval contractors), with completion records.
• Back-to-back terms signed by each subprocessor and annotation vendor before data moves.
• Incident runbook entry for "suspected re-identification," with a named owner and a quarantine step.
• Memorization and extraction testing planned for models trained on the data, with results kept internally.
• Outbound controls: no exports to personal devices or email; transfers only through approved pipelines.

If any line is a "no," either fix it before signing or negotiate a phased obligation with a date. Ask the supplier for the matching evidence on their side using the de-identification evidence package checklist.

How the clause differs across HIPAA, state law and the EU

The obligations are similar in each regime, but the trigger and the consequences differ, so the clause should say which regime applies. HIPAA limited data sets require a DUA with fixed minimum terms [1]. For data de-identified under Safe Harbor or Expert Determination, contract terms are usually a condition of the expert's opinion rather than a statutory requirement [2]. For guidance on choosing between them, see Safe Harbor vs Expert Determination.

Under California and similar state laws, the contractual obligation on recipients is part of what keeps the data outside the definition of personal information in the first place [3][4]. If your organization breaches the clause, the supplier's data may stop qualifying as deidentified, and so may your copy. In the EU, pseudonymised data stays personal data for anyone who can reasonably identify people, so the clause supports, but does not settle, the anonymity analysis [8].

Questions counsel should put to the supplier

Six questions cover most of the negotiation risk:

1. Which legal regime is the clause meant to satisfy (HIPAA DUA, CCPA deidentified, an Expert Determination condition, GDPR)?
2. What does "attempt" include, and are privacy red-teaming and memorization tests allowed?
3. Which join keys and external datasets are pre-approved?
4. What is the notice period for inadvertent re-identification, and what remedy follows?
5. Which affiliates, contractors and cloud processors may receive the data, and on what flow-down terms?
6. Does the clause survive termination, and how does it interact with deletion obligations?

For a broader view of restricted uses, compare the prohibited-use clauses guide and the privacy cluster hub. For a plain-language explainer, see how personal details are removed and whether anonymized data can be licensed.

How SourceX handles personal details before licensing

SourceX sources operational datasets from US companies on request, and every dataset is rights-reviewed and delivered under a license that defines records, uses, term and delivery. Personal details such as names, emails, phones and account numbers are removed or replaced before delivery. The method is recorded and a sample is checked, though no method is perfect. Health records require HIPAA de-identification by Safe Harbor or Expert Determination. Teams can describe what they need on the SourceX buyer page.

Sourcing de-identified data under a re-identification clause

If you need de-identified operational data, SourceX can look for US businesses that hold it. Diligence materials on source, rights, preparation and allowed use are prepared for each dataset, and nothing is contracted until the supplier agrees. Describe the data you need at sourcex.si/buyers.

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.