De-identifying resumes and candidate profiles: what to remove

Why is a resume harder to de-identify than a form?#

A resume is harder to de-identify than a form because the person wrote it to be recognized. Identity is spread across the whole document: an employer sequence, a niche certification, a conference talk and a city can together describe one individual even after the name is gone.

This is also why a blind resume is not the same thing. A blind resume hides a few fields from a hiring manager to reduce bias in one decision. De-identification for an AI dataset has to hold up against anyone who holds the data, can search the web and has time, so it removes and generalizes far more.

Decide the purpose before choosing treatments. If the dataset is meant to show how skills and roles progress over a career, durations and role families must survive and exact employers can go. If it is meant to show how resumes are matched to job orders, skills and seniority matter most and career detail can be coarser. Fields that serve no stated purpose should be removed rather than generalized.

Field-by-field table: direct identifiers, quasi-identifiers and free text#

The field-by-field table below gives a default treatment for the content found on most resumes. Remove means the content is deleted, generalize means it is replaced with a broader category and review means a person reads it after automated scanning.

What else sits in an ATS candidate profile?#

An ATS candidate profile carries far more than the resume, and each part needs its own rule. Profiles usually hold status history, source, tags, recruiter notes, attached files and communications logs, and some hold EEO self-identification answers collected for reporting.

Treat the profile as a set of separate decisions rather than one record:

• 1Status history and stage dates: keep, with tokens and consistent date shifting.
• 2Source and campaign codes: keep as categories; remove referrer names.
• 3Skills tags: keep, after checking that no tag encodes a protected trait.
• 4Recruiter notes: review line by line for names, health, family and pay remarks.
• 5Attachments such as cover letters, transcripts and ID scans: exclude unless reviewed individually.
• 6EEO and voluntary self-identification: exclude entirely.
• 7Email and text logs: usually exclude.

Where automated tools miss identifiers#

Automated tools catch the obvious identifiers well and miss the contextual ones. Presidio, an open-source PII detection and anonymization SDK now governed by the community Data Privacy Stack organization, combines named-entity recognition, regular expressions, rule-based logic and checksums. The project is candid about the limit: its documentation says automated detection cannot promise to catch every piece of sensitive information, so other safeguards are needed alongside it.

Resumes produce predictable misses: names embedded in email handles or file names, project and product names that identify an employer, client names in consulting or contract histories, foreign-language text and details inside images or tables. Run automated detection first, then have a trained reviewer read a meaningful sample of every batch and all free text flagged as uncertain.

How do you test whether a de-identified set can be re-identified?#

Testing for re-identification means checking the dataset as a whole, because risk comes from rare combinations of fields shared by few records. The research behind this is old and consistent: Latanya Sweeney estimated from 1990 Census data that 87% of the US population was likely unique on five-digit ZIP code, gender and date of birth, and Philippe Golle's 2006 revisit put the figure at about 63% on 2000 Census data. The exact number depends on method; the lesson for resumes, which carry far more detail than three fields, does not.

The standard test is k-anonymity, defined in Sweeney's 2002 paper: a release is k-anonymous when each person's record cannot be distinguished from at least k-1 others. For resumes, that means every combination of role family, region, degree level and years of experience should be shared by at least a set number of records; l-diversity adds a check that sensitive values inside each group vary. Google's Sensitive Data Protection API, for example, offers k-anonymity, l-diversity, k-map and delta-presence as built-in risk analyses. When a combination is too rare, coarsen a field or remove the record; niche specialists in small markets are the usual cases.

Illustrative: an engineering staffing firm prepares a resume sample#

Illustrative: a fictional engineering staffing firm wants to understand what its candidate archive would look like after de-identification. It pulls an internal sample of resumes and ATS profiles for mechanical and controls engineers.

The privacy lead applies the field table, generalizing employers to industry and size and converting employment dates to durations. Automated detection removes contact details, but the reviewer finds employer names inside project descriptions and a patent title that would identify one engineer. A k-anonymity check shows that several senior controls engineers in one small region are unique, so region becomes a broader area for that group. The firm concludes that resumes need heavier treatment than its workflow records and scopes them as a separate decision.

How SourceX approaches resumes and candidate profiles#

SourceX treats resumes and candidate profiles as high privacy burden records. In the SourceX five-step transaction, the Rights step checks candidate notices and the consent language in use when the records were collected, and Preparation applies field rules the supplier has approved, with a prepared sample reviewed before release.

The privacy record in the SourceX Evidence Packet lists each field treatment, the detection tools and human review used and the results of re-identification testing. Which privacy laws may apply is assessed deal by deal with counsel.