Reviewing an anonymized sample before delivery: what to look for

Before any of your company's data reaches a buyer, you see an anonymized sample of it. That review is one of the most useful steps in the process, because you know things about your company that no pipeline does: which nicknames people used, which client hid behind a project codename, which channel was supposed to be excluded.

You do not need to read everything. You need to know where to look. Here is a practical guide to reviewing a sample well, in about the time it takes to read a long report.

Anonymization replaces every person, company, address, email, phone number and account with a consistent token, so PERSON_014 is the same person in Slack, email and Jira. Credentials, API keys, card numbers and government IDs are removed outright. Faces, logos and signatures are blacked out in images and PDFs. That work happens in-house, and no third party touches raw data.

A pipeline is good at patterns. It is less good at context only an insider would recognize. The engineer everyone called "Bear," the client referred to by the name of its CEO's dog, the side project that only makes sense if you know who started it: these are the things a reviewer who knew the company is best placed to catch.

Pick a reviewer accordingly. A founder, an early employee or an operations lead who was around for most of the company's history will spot more than someone new.

Before reading for names, check that the sample reflects what you agreed. Your scope and exclusions were annexed to the contract before any data moved, so they are the reference point.

• Excluded clients should not appear at all, under their name or under a token
• Excluded channels, folders and projects should be absent, not just anonymized
• Direct messages should be missing unless you chose to include them
• HR, payroll, medical and legally privileged folders should be absent unless you explicitly included them
• Systems you left out of scope should not be in the sample

If something excluded appears, flag it. That is a scope problem rather than an anonymization problem, and it should be fixed at the source before anything else.

Most identifiers sit in obvious places and are handled reliably. The ones worth hunting for live in less obvious spots:

• Usernames, handles and @mentions that do not match a person's real name
• Nicknames, initials and shortened names used casually in chat
• Email signatures, out-of-office replies and forwarded headers
• File names, document titles and folder paths
• URLs that contain a company or person's name
• Code comments, commit author fields and branch names
• Project codenames that were named after a client

Check consistency too. Pick two or three people you remember well and follow their tokens across tools. The same person should carry the same token in a Slack thread, the related ticket and the email that kicked it off. If one person seems to have split into two tokens, or two people seem to share one, flag it. Consistency is what makes the data useful, and we explain why in why the same person must get the same token everywhere.

Some content is not tokenized; it is removed. It is worth spot-checking a few places where it tends to appear.

Search the sample for anything that looks like a password, key or token, particularly in code, config files, onboarding docs and messages where someone pasted credentials "just this once." Card numbers and government ID numbers should be gone too. Our post on secrets in the archive covers where these usually turn up.

Then look at images and PDFs. Faces, logos and signatures should be blacked out. Pay attention to the hard cases: low-resolution scans, photos taken at an angle, small logos used as watermarks and handwritten initials on approvals. More on this in faces, logos and signatures.

The last pass is the one only an insider can do. Read a handful of longer threads and ask whether anyone outside the company could work out who the people or clients were from the context alone.

That can happen without a single name appearing. "Our only customer in Iceland." "The CFO's sister, who handled our audit." "The office above the bakery on Main Street." A unique role, an unusual location or a very specific event can point to a person as clearly as a name. These are the indirect identifiers discussed in re-identification risk and how to reduce it.

You do not need to find every one. Flag the patterns you notice, and they can be handled across the full dataset, not just the sample.

When you flag an issue, it gets fixed across the dataset and you can review the result before signing off. There is no penalty for flagging, and it is better to flag something borderline than to wonder about it later. The licence also protects the people in the data: buyers may use it for training and evaluation only and may never market to, profile, contact or re-identify anyone in it.

Once you sign off, delivery proceeds and payment goes to the company entity. The raw archive is deleted within 30 days of sign-off as a contract obligation, and you receive a deletion certificate. You can read the full pipeline on our trust page.

If you are considering a licence and want to understand what the review will involve for your company, book a 15-minute call.