Is leaked de-identified data a reportable breach?

What do state breach laws actually protect?#

State breach notification laws protect a defined list of data elements, not every record that relates to a person. The typical pattern is an individual's name, or first initial and last name, combined with something that enables fraud or harm: a government identification number, a financial account number with its access code, and in many states health information, biometric data or online account credentials.

That structure matters for a company preparing records for licensing. A support ticket export that has had names, emails and phone numbers replaced, and that never contained payment card or ID numbers, often does not contain the combination these statutes describe. A raw CRM export with contact names and nothing more may also fall short of most definitions, but it is still personal information under broader privacy laws.

Definitions differ from state to state and change over time. The state of residence of the affected people usually decides which laws apply, so a single archive can be measured against several definitions at once.

When does de-identified data stay outside breach notification?#

De-identified data generally stays outside breach notification when no one could reasonably link it back to a specific person and none of the listed data elements survive. California's privacy law offers a useful test, separate from its breach statute: under the CCPA, information counts as deidentified only if it cannot reasonably be linked to a particular consumer, the business takes reasonable measures to keep it that way, publicly commits not to re-identify it and contractually binds recipients to the same terms. Breach statutes use their own, narrower definitions, but data that meets this test rarely contains the elements they list.

In practice, that means the leaked file contains replaced or removed names, contact details and account numbers, no lookup table that reverses the replacement, and no free-text passages that name individuals. If all three hold, counsel may conclude that no statutory notice is triggered, though contracts may still require telling a customer or licensee.

Why pseudonymized records are the gray zone#

Pseudonymized records are the gray zone because they are reversible by design. A consistent token such as Customer 4417 in place of a real name keeps threads readable for an AI developer, but if the mapping table leaks with the dataset, the records are effectively identified again.

European law states this plainly: GDPR Recital 26 says pseudonymized data that could be attributed to a person with additional information should be considered information on an identifiable person. US breach statutes rarely use that vocabulary, yet the practical question is the same. If an attacker holds both halves, assume the data is personal information until counsel says otherwise.

The control that keeps pseudonymized data out of the gray zone is separation. Keep token maps in a different system, under different credentials, and never ship them with a licensed dataset.

Where de-identification usually fails in business records#

De-identification usually fails in unstructured text rather than in structured fields. Column-level tools catch the email address in the requester field, but miss the customer who typed a card number into a chat, the technician note that names a homeowner, or the quoted reply that repeats a signature block.

Before deciding a leak is harmless, sample the leaked files and look for these residues. If you find even one listed data element tied to a name, the analysis changes from de-identified data to a partial breach of personal information.

• 1Message bodies in Zendesk, Intercom or Freshdesk tickets where customers pasted account or card numbers.
• 2Email signatures and quoted replies that carry names, direct phone numbers and titles.
• 3Attachments such as invoices, W-9 forms or driver license photos stored alongside tickets.
• 4Rare combinations, such as a job title plus a small town plus a date, that single out one person.
• 5File names and folder paths that include customer or employee names.

What to do in the first hours after a leak#

The first step after a leak is to preserve evidence and establish exactly which file versions left your control. A preparation workflow usually produces several versions, from raw export to staged to released, and the answer depends on which one leaked.

Then bring in counsel before drawing conclusions. Even when a statutory notice is unlikely, licensing agreements, customer contracts and cyber insurance policies often have their own notice clauses with their own clocks.

• 1Identify the file version: raw export, working copy, or released de-identified package.
• 2Confirm whether any token map, lookup table or re-identification key was reachable.
• 3Sample the leaked records for listed data elements in free text and attachments.
• 4Map affected individuals to states of residence, as far as metadata allows.
• 5Review contractual notice duties to customers, licensees and insurers.
• 6Record every finding and decision in the incident log for later review.

Illustrative: a leaked staging copy at a software company#

Illustrative: a fictional vertical software company with a few hundred employees prepares several years of Zendesk tickets and linked Jira issues for licensing. A contractor misconfigures a storage bucket and a folder is exposed for a short period before logging flags it.

The incident team finds the folder held the released package, not the raw export. Names and emails had been replaced with consistent tokens, and the token map lived in a separate account the contractor could not reach. A sample review turns up two tickets where customers had pasted partial card numbers without names attached. Counsel concludes that statutory notice is unlikely to be required, notifies the licensee under the contract, and the company adds a card-number pattern to its scrubbing rules before re-releasing.

How SourceX approaches breach exposure in preparation#

SourceX treats breach exposure as a design question in the Preparation step of the SourceX five-step transaction. Personal and confidential details are removed before release, re-identification keys stay with the supplier, and the supplier approves the prepared package before anything moves.

The SourceX Evidence Packet records the privacy record for each package: which fields were removed or replaced, which methods were used and who approved release. If something goes wrong later, that record is what counsel needs to judge whether the exposed data was personal information at all.