What "de-identified" actually means when you sell company data

There is no single legal definition of de-identified data, and the frameworks that try to define it disagree about how much rigor they require and who has to answer for the result. Broadly, every regime puts the obligation on whoever collected the data in the first place and then varies enormously in what it demands before that obligation is discharged. HIPAA offers two routes, one of which is a documented opinion from a qualified expert (aka Expert Determination). GDPR asks whether anyone, not only the recipient, could realistically re-identify someone by means reasonably likely to be used. CCPA asks for reasonable measures only.

If you are selling a corporate corpus, there is no framework written for your situation.

Three words that mean different things depending on who is reading

Most confusion in this market starts with the vocabulary. Anonymization, pseudonymization, and de-identification get used interchangeably in sales conversations, and for the most part that's fine — the international standards bodies do the same thing. ISO/IEC 20889 and the ISO/IEC 27559 framework built on it use de-identification as the working term for the whole field and stay deliberately neutral on legal interpretation, precisely because anonymization had come to mean too many different things.

The vocabulary stops being interchangeable the moment a regulator or an acquirer's counsel is reading. Then each word becomes a threshold, and the thresholds are set by different laws that don't agree with each other.

Pseudonymization is the one term with a stable meaning everywhere it appears. You've replaced identifying values with stand-ins and kept the information needed to reverse the swap, stored separately and under its own controls. The reversal path still exists, and that's the whole point of the definition. It preserves referential integrity across tables, which is why engineers reach for it first. Under GDPR it's a recognized safeguard, not an exemption. It lowers your exposure. It doesn't end your obligations.

Anonymization is the strictest bar in the group, and it belongs to Europe and Canada rather than the United States. Under GDPR, anonymized data falls outside the regulation entirely. Quebec's Law 25 sets the most demanding wording of any regime: the information must, at all times and in reasonably foreseeable circumstances, irreversibly no longer permit identification, whether directly or indirectly.

De-identification is the American term, and it's where the mapping gets genuinely confusing. Canada's Office of the Privacy Commissioner has made the point plainly: what GDPR and Quebec call anonymization corresponds more closely to what HIPAA and the CCPA call de-identification, while what Quebec calls de-identification is closer to GDPR's pseudonymization. The same corpus can clear the de-identification bar in Texas and miss the anonymization bar in Toronto without a single byte changing. G7 data protection authorities have met specifically to work on the absence of consistent definitions across their jurisdictions.

So the terms don't sort into a hierarchy of rigor. They sort by jurisdiction.

What anonymization does not require

Anonymization has a reputation in this market for destroying data, and the reputation is misplaced. It comes from confusing an outcome with a technique.

Anonymization is defined by what has to be true when you're finished, not by how you got there. Nothing in GDPR's threshold or in HIPAA's expert route specifies a method. The methods that earned the reputation are the legacy ones: aggregation rolls records into counts, generalization buckets dates into years and swaps a job title for a department, suppression drops the fields too revealing to keep. Each of those trades detail for safety, and on a workplace archive the trade is brutal. You end up with statistics about a company rather than a record of how it operated.

That tradeoff belongs to those three techniques. It was never a requirement of the standard.

There is another way to reach the same outcome, and it runs in the opposite direction. Instead of deleting the identifying detail, replace it with realistic detail belonging to nobody. One employee becomes one consistent synthetic person: the same invented name in the CRM record, in the email thread, in the PDF attachment, and in the Slack message where a colleague used only her first name. Job titles stay job titles. Dates stay dates. The relationships between records survive. The corpus still reads like a company doing its work, and no one in it exists.

Consistency across unstructured content is the hard part, and it's what separates this from find-and-replace. Identifiers in emails, tickets, transcripts, and documents don't sit in labeled columns. They're spelled inconsistently, referenced by nickname, buried in signature blocks, and repeated across systems that never shared a schema.

Two decisions then determine which threshold your output clears, and you control both. Keep a reversal mapping and you have pseudonymization by definition, with everything that carries. Destroy it and that path closes. Then assess the residual risk, because removing direct identifiers is not the finish line — quasi-identifiers can still single someone out in combination, which is exactly what HIPAA's expert route exists to evaluate.

This matters because the buyer isn't paying for privacy. The buyer is paying for signal. How work moves between people, how a deal progressed, what an escalation looks like. Strip too hard and you've sold nothing. Keep a reversal path and you've sold personal data. The only version that works is the one where identity is gone and structure survives.

The question to put to a vendor is not which of the three words they use. Everyone uses them loosely, including the standards bodies. The question is which threshold they can tell you your output clears, in which jurisdiction, and what documentation they'll hand you to support it. A vendor who can't answer that hasn't thought about either axis. A vendor promising to anonymize your corpus with aggregation and suppression is about to torch the thing you're trying to sell.

The legislation varies as much as the terminology

No single statute governs the de-identification of corporate data, so the standard you're held to depends on which regime covers the people in your corpus, and that's a function of where your employees and customers live rather than where the data sits. If you employ people in Quebec or Ontario, those regimes come with you, and Quebec's anonymization bar is higher than anything in US law.

Three regimes set the terms in practice, and they disagree on the two things that matter most: how rigorous the work has to be, and whether anyone independent has to attest that it was done.

California: an outcome test with nobody checking

The CCPA, as amended, defines deidentified information as information that can't reasonably be linked to a consumer, provided the business takes reasonable measures to prevent re-identification, publicly commits to keeping it that way, and doesn't try to reverse it.

Read the statute for what it does not require. No methodology. No named expert. No sampling. No documentation. No attestation from anyone. Two companies can both claim compliance while one resolved every employee's identity across email, payroll and the CRM and the other ran a find-and-replace on a list of names, and on the face of the statute both of them took reasonable measures.

Penalties run to $2,500 per violation and $7,500 per intentional violation, which for a corpus with millions of people in it is a number worth taking seriously.

Europe: identifiability depends on who is holding it

GDPR's Recital 26 asks whether a person is identifiable using all the means reasonably likely to be used, by the controller or by anyone else. Article 4(5) makes pseudonymization a safeguard.

The important movement is EDPS v SRB, decided by the Court of Justice of the European Union in September 2025, where the court held that pseudonymized data isn't automatically personal data for every party. Whether it is depends on whether re-identification is reasonably likely for that recipient, weighed against the technical, organizational, and legal measures in place. The same judgment held that a controller's duty to inform data subjects is assessed from the controller's own position at the point of collection, independent of what the recipient can do. Strongly pseudonymized data can therefore be personal data in the hands of the company that transferred it and not personal data in the hands of the company that received it.

That case was decided under the regulation covering the EU's own institutions rather than GDPR itself, but it turns on the same definition of personal data and is being read across both jurisdictions. The European Data Protection Board had already said in Opinion 28/2024 that you can't assess that risk against the intended recipient alone. You have to account for the third parties nobody planned for.

Put those together and you get the most useful principle available in this market. The same corpus can be personal data in one company's hands and anonymous in another's. Identifiability is a function of who holds the data and what they could still do with it, not a property of the file. This is why the identity, independence, and competence of whoever performed the de-identification is part of the legal question rather than an implementation detail.

HIPAA: the only framework that names a person

Under HIPAA, protected health information can be de-identified two ways.

Safe Harbor removes 18 categories of identifiers, and then adds a catch-all. Even after they're gone, you can't have actual knowledge that what remains could still identify someone, alone or combined with other data. It's prescriptive and fast. It’s worth being precise about a common misreading however. Safe Harbor dictates which identifiers must be dealt with, not that they must be blacked out. For direct identifiers like names, replacing them with realistic synthetic values preserves analytic value that redaction destroys. Dates are the exception: Safe Harbor permits only the year, so a realistic synthetic date takes you off the Safe Harbor route and onto the expert one. 

Expert determination asks a person with genuine statistical training to apply accepted methods, conclude that the risk of re-identification is very small, and document the methods and the result. Neither route is preferred by the regulation. The healthcare sector relies on both approaches because Safe Harbor’s checklist fails when applied to clinical narratives. In unstructured medical text like clinical notes, identity is typically revealed through contextual details, specific dates, and subtle phrasing rather than straightforward fields like [NAME_GIVEN], making Expert determination essential in those situations.

Given the amount of unstructured data generated by a company’s operations, expert determination is the closest thing to a template that exists for de-identifying corporate data. The threshold doesn't transfer, since a HIPAA-grade absolute standard applied to a workplace corpus risks destroying the signal the buyer is paying for. But the structure provides essential components: an identified responsible party, established methodologies, and a formal assessment of residual risk.

The frameworks, side by side

De-identification standards by legal framework: the standard each sets, and whether it requires a qualified expert or documentation

Framework	The standard	Requires a qualified expert?	Requires documentation?
CCPA / CPRA, Civ. Code § 1798.140(m)	“Reasonable measures” so data can’t reasonably be linked to a consumer, plus a public commitment not to re-identify	No	No
GDPR, Recital 26 and Art. 4(5)	Not identifiable by any means reasonably likely to be used, assessed recipient by recipient after EDPS v SRB	No	Not for de-identification as such, but the accountability principle requires you to be able to evidence the assessment
Quebec Law 25, s. 23	Irreversibly no longer permits direct or indirect identification, per the anonymization regulation and generally accepted best practices	No	Yes, the regulation prescribes the process
HIPAA, 45 CFR § 164.514(b)	Safe Harbor’s 18 identifier categories, or an expert determination that risk is “very small”	Yes, on the expert route	Yes, on the expert route
Bankruptcy, 11 U.S.C. §§ 363(b)(1) and 332	Court approval after a consumer privacy ombudsman is appointed	No, but an independent overseer is mandatory	Through the court

Where the liability actually sits

Under the CCPA, the duty attaches to the business that collected the information. The contract terms California requires when you hand data to a third party limit your liability only where you didn't know and had no reason to know the recipient would violate the statute, and a business that never enforces those terms loses even that defense.

Under HIPAA, the covered entity remains responsible. A business associate agreement moves the work downstream and shares exposure but it doesn't relocate the duty.

Under GDPR, the controller answers for the processing. That's normally the company that collected the data and still holds it, which in a data sale is the seller. And after SRB, the assessment turns partly on what the recipient could do, which is precisely the thing the seller stops controlling the moment the data moves.

In bankruptcy, the estate carries it, and the FTC has intervened directly when a debtor's own privacy promise was at odds with the sale.

The practical consequence for anyone monetizing a corpus: the exposure stays with you, and the only durable protection is a documented, independent determination you can put in front of a regulator, a court, or an acquirer's diligence team.

Tonic.ai has been focused on data de-identification for close to a decade. We understand the complexities, the regulations, and the risks involved. If you’re exploring approaches to de-identifying your corporate operational data, our team of experts is here to help.