Last checked: 7 October 2026 (buyer statements quoted on this page)
Buyers say they remove personal and confidential details before data is used or passed on. Your job is different: decide what never leaves the building, check what the process produces on your own records, and know what risk remains afterwards.
Buyers, lawyers and privacy laws use these words differently. Agree on the meaning before you agree on the method.
The umbrella term: removing or replacing details that point to a person or a confidential matter, so the record can be used without exposing them.
Removing or masking a detail. Every name may become the same placeholder, which is simple and strong but breaks the thread of who did what.
Replacing each person or client with a consistent stand-in, such as Person 7, everywhere it appears. The thread survives; a mapping key now exists.
Processing so that people can no longer reasonably be identified. Some laws treat this as a legal threshold rather than a technique.
Work histories are valuable because you can follow who asked, who answered and what happened next. The method decides whether that survives.
Dana Ruiz: Harbor Dental wants the Q3 renewal at last year's rate.
Sam Okafor: Loop in Priya, she handled their 2024 dispute.
[NAME]: [CLIENT] wants the Q3 renewal at last year's rate.
[NAME]: Loop in [NAME], she handled their 2024 dispute.
Person 7: Client 112 wants the Q3 renewal at last year's rate.
Person 3: Loop in Person 9, she handled their 2024 dispute.
Fictional people and company, for illustration only. Note what neither method touched: "Q3 renewal", "last year's rate" and "2024 dispute" can still identify a client to anyone who knows the business.
| Redaction | Consistent pseudonyms | |
|---|---|---|
| What it does | Removes or masks each detail | Replaces each person or client with the same stand-in throughout |
| Keeps the workflow | Partly: three different people all become [NAME] | Yes: who said what to whom survives |
| Main residual risk | Context left in the text; missed variants such as nicknames | The mapping key; patterns across many messages that point to one person |
| What to verify | Nicknames, initials, email signatures, attachments | Where the key is held, who can access it, and when it is deleted |
Most tools are good at the first layer. Business records leak through the other four.
Names, email addresses, phone numbers, street addresses, account and ID numbers.
Job titles in small teams, office locations, dates and one-off events: "the only CFO", "the week the Denver office flooded".
Client names, project code names, prices, deal terms and unreleased plans, including your clients' secrets.
Health, disciplinary, family and financial details that turn up inside ordinary HR and manager threads.
Attachments, screenshots and scanned PDFs; author fields and other file metadata; email headers and signatures; passwords and API keys in code and chat.
In the published programs the buyer runs de-identification after export. You control the input and sign the warranties.
From the buyers' own pages and as reported, checked 7 October 2026.
Practitioners describe de-identification and acceptance as stages of a deal that takes 60 to 90 days to close. Each step below has an owner and a question.
Leave out HR, legal, health and client-confidential sources, and private messages your staff notice does not cover. Records that are never exported cannot leak. See preparing your data for sale.
Who runs the export, where the files go, how they travel, and who can access them before processing. Agree in writing whether this is a one-time copy or a recurring delivery, since each new delivery needs the same checks.
Redaction, pseudonyms or both, applied by a method described in writing. Ask which of the five layers it covers.
Read de-identified output from your own records, not a demo. This is where your knowledge of clients and staff matters most.
The cleaned copy is accepted against written criteria and used, or passed onward, under the contract's limits.
Originals held by the buyer, intermediate copies and the pseudonym key, each with a date and written confirmation.
You do not need to run the process to check it. You need a sample, a list of names and someone who knows the business.
De-identification lowers risk; it does not remove it. Smaller companies have fewer people per role, so context identifies faster. Free text is harder to clean than structured fields. Details can be matched against public sources such as press releases and professional profiles.
The remaining risk lands somewhere in your contract. Before you sign, know whether it lands on you, on the buyer, or is shared, and whether the answer is capped.
These are requests any seller can make of any buyer. They are not claims about what a particular buyer offers or refuses.
Which layers are covered, by what tools and people?
Can you review output from your own records before release?
Is there a third-party review or report you can see?
Originals, copies and keys: deleted when, confirmed how?
How fast are you told if a miss is found downstream?
What a buyer agrees to is its decision. Asking the same questions of more than one buyer makes the answers comparable. For the wider legal picture, start with is it legal to sell company data.
Buyers list these systems as sources. Each one hides identifying detail in different places, and each suits a different method.
| Source | Where identifiers hide | Method that tends to fit | What to check in your sample |
|---|---|---|---|
| Slack, Microsoft Teams | Display names, @mentions, nicknames, shared files | Consistent pseudonyms, so threads still read | Nicknames and first names used alone |
| Gmail, Outlook | Headers, signatures, external senders, quoted earlier replies | Pseudonyms plus header and signature removal | Old threads quoted at the bottom of messages |
| Zendesk, ServiceNow | Customer names, emails, order and account numbers | Pseudonyms for customers, redaction for numbers | Free-text fields and attachments |
| Salesforce, HubSpot | Contact records, call notes, deal names | Drop contact fields, keep the reasoning in notes | Notes that name people or companies |
| QuickBooks, Xero, NetSuite | Client names, bank details, invoice amounts | Redaction for numbers, pseudonyms for clients | Memo fields and attached invoices |
| GitHub, GitLab, Bitbucket | Commit authors and emails, secrets in old history | Pseudonymized authors, full-history secrets scan | Config files and early commits |
| Confluence, Notion, Google Drive | Worked examples with client names, author fields, comments | Redaction of examples, metadata stripping | Embedded images and comment threads |
Systems as listed by buyer programs, checked 7 October 2026. The methods are general guidance, not a process any buyer has published.
Most exports mix several of these sources, so most real pipelines combine methods: pseudonyms for people and clients, redaction for numbers and secrets, and outright exclusion for anything that cannot be cleaned with confidence. Ask the buyer which method it applies to which source, and check one sample per source rather than one sample overall.
This is why the sample has to come from your own records and be read by someone who knows the business.
A 70-person logistics company receives a 200-message de-identified sample of its own Microsoft Teams history. Its operations manager, who knows every customer and every shift, spends an afternoon reading it before anything is released.
The text was clean, but a pasted screenshot of a delivery board still showed a customer's name.
Image handling in the method, or images excluded from scope.
"Person 12" signs off as the only night dispatcher at one depot. Anyone in the company knows who that is.
Handling of job titles and locations, or that channel left out.
A shipping account number pasted as part of a table was not caught by the pattern rules.
Added pattern rules and a re-run on the full export, then a fresh sample.
None of the three would appear in a demo built on someone else's data. All three were obvious to a person who knows the business. That afternoon of reading is the cheapest risk control in the whole deal.
The mistakes are generic and common to any seller. The questions go to the buyer, to your lawyer, or to both.
Redaction removes or masks a detail, so every name may become the same placeholder. Pseudonymization replaces each person or client with a consistent stand-in, such as Person 7, so a thread can still be followed. Pseudonyms keep more of the workflow but depend on a mapping key that must be protected and then deleted.
In the published programs the buyer handles it after export, sometimes with a third party. micro1 states that sensitive and confidential information is scrubbed, and Mode states that it de-identifies before onward delivery (as published, checked 7 October 2026). You still decide what is exported, and you can ask to review a de-identified sample of your own records.
It depends on the law and the method. GDPR draws a line between pseudonymized data and anonymous data, and HIPAA names two de-identification methods, Safe Harbor and Expert Determination. Whether a given output meets any of these is a question for your lawyer, not something a general guide can settle.
Sometimes, from context. In a small company a job title, a date or an unusual event can point to one person, and free text is harder to clean than structured fields. That residual risk is why the contract should say who carries it.
You can ask. Requests made in general terms include a written method description, a right to review samples, an independent review or report, written deletion confirmation and prompt notice of any incident. What a buyer agrees to is its decision; compare the answers across offers.
The cheapest privacy step is not exporting a record at all. Leave out HR, legal and health records, client-confidential material, private messages your staff notice does not cover, and anything holding credentials. The buyer’s process then handles what remains in scope.
You can do a first pass, especially exclusions and a secrets scan, while the published programs describe the buyer handling de-identification. Doing both can lower risk. Agree in writing who is responsible for which step, so nothing falls between two processes.
Big enough to cover every system and record type in scope, attachments included, and read by someone who knows your clients and staff. No published standard sets a size, so agree it with the buyer before export and write it down.
Applying lets you ask each program how it de-identifies and whether you can review a sample of your own data. Nothing leaves your systems at the application stage.
Independent site. Some links are referral links: if your company signs with a buyer through them, the buyer may pay us a fee. You are not charged, and we never see your data.