Preserving useful data connections after de-identification

Removing names can also remove the story

A project manager appears in email, calendar, chat, and the file history. If each export replaces that person with a different identifier, a reviewer may no longer be able to connect their actions. The records still exist, but the workflow has fragmented.

The useful objective is to preserve authorized relationships while managing disclosure risk. It is not to make people identifiable to the buyer. Define what the training or evaluation task actually needs before choosing which fields and connections to retain.

Our linkage-rate guide distinguishes having a connection from proving it is correct.

Check the same person across the required systems

Where a stable pseudonymous employee ID is appropriate, check that it is consistent across the systems in scope. Also test the less obvious failure cases:

• Split identity: one person receives multiple IDs after an account migration.
• Collision: two people are mistakenly assigned the same ID.
• Shared account: several people use an address that should not be modeled as one employee.
• Automation: a bot’s actions are mixed into a human’s activity.

Consistency is not the same as correctness. A mapping can be consistently wrong. Verifying correctness requires an authorized reference; without one, describe the result as a structural consistency check.

Measure what survives the transformation

The remaining 30 need explanation. Were their records intentionally excluded? Did an identifier change? Was a file unavailable? Did a replacement rule vary between systems? Keep a reason for each category of loss.

Do not report a before-and-after retention percentage without a baseline. It is still possible to inspect the delivered data, but that answers a different question. Put the transformation version and comparison method in the connection manifest.

Privacy requires its own review

NIST SP 800-188 explains that de-identification involves disclosure-risk decisions as well as data transformation, and that simple masking tools may be insufficient. The publication is guidance for government datasets, not a certification of this service.

In an operational sample, free text, unusual roles, dates, attachments, and combinations of facts can still create risk. A high linkage score says nothing definitive about that risk. More connected data may require more careful review of what the recipient can infer.

Discuss permitted uses and handling with the appropriate reviewers. Keep protected re-identification material out of buyer-facing packages. See our broader guide to anonymization beyond removing names.

Review a workflow, not just an ID column

Follow a selected request into its task, supporting conversation, file revision, approval, and result. Verify that timestamps still support the sequence and that redaction has not removed the reason a decision was made.

Some loss of detail may be a deliberate part of the sharing scope. The report should distinguish an intentional limitation from an accidental processing error. A buyer can then judge whether the remaining evidence supports the task.

Start with a bounded quality review

Explore business-data quality ranking with Clear Harness, our partner. Describe the systems, the transformations already applied, and whether an authorized comparison baseline is available. Confirm which privacy and quality checks are included in the proposed engagement.

If you are at the earlier stage of exploring the market, take the Troveo business assessment (referral link; we may be compensated). A licensing assessment and a quality review serve different purposes; neither substitutes for the agreed rights and sharing process.