What Is Identity Masking? (PII Scrubbing)
Identity masking, often called PII scrubbing, is the planned removal or transformation of information that identifies a person. It can reduce exposure in datasets used for analysis, testing, or sharing, but masking names alone is not enough. Effective de-identification also checks combinations of details, linked copies, legal requirements, and the risk that someone could identify a person using other data.
A dataset can look anonymous and still point to someone. A rare diagnosis, exact dates, and a small town may identify a person even after their name is gone. That risk matters when you share records with a vendor, use data for testing, or prepare information for analysis.
The goal is not to make data look different. It is to limit what people can learn from it while retaining only the detail needed for an approved purpose. The right method depends on the data, who will receive it, and the rules that apply.
Planning — define the purpose and scope
Planning sets the boundaries for PII scrubbing: which data will be changed, why it will be used, who may receive it, and what level of re-identification risk is acceptable. Start with the intended use, not a list of names to delete. A method that works for one dataset may fail for another.
I begin by documenting the purpose and the minimum detail needed to meet it. This supports data minimization: collect, keep, and share no more personal data than the task requires. Purpose limitation means not reusing data for a new purpose without checking whether that use is allowed.
“PII” does not have one universal legal meaning. Its scope depends on the law, sector, and context. Record the rules that apply, such as HIPAA for certain health information or the GDPR for personal data within its scope.
Inventory data and copies
List the data fields, their sources, and every place they appear. Include more than the main database:
- Production tables and linked tables
- Exports, reports, and analytics datasets
- Logs, error reports, and support tickets
- Test fixtures and sample files
- Backups, archived copies, and derived datasets
- Free text, attachments, and file metadata
Classify fields as direct identifiers, quasi-identifiers, sensitive attributes, or other data. A direct identifier can identify a person by itself, such as a name or email address. A quasi-identifier may identify someone when combined with other details, such as age, a location, and an event date.
Set the risk and utility goals
NIST Special Publication 800-188 recommends a risk-based approach to de-identification. Consider who will receive the data, what outside information they may access, and how much detail the work needs. No single transformation guarantees safety in every context.
Write down what utility must remain. For example, a study may need age bands but not birth dates. A software test may need records that behave like real data, but not real people’s records. Keep the decision, owner, approval, and acceptable residual risk on record.
Access and exposure — apply the right rules
Access and exposure controls limit who can see personal data and how far it can travel before and after scrubbing. They do not replace transformation, but they reduce the chance that raw information or a retained linkage key will be misused. Check the applicable law before releasing data.
For covered health information, HIPAA provides two de-identification methods: Safe Harbor and Expert Determination. Safe Harbor requires removing 18 categories of identifiers in 45 CFR §164.514(b)(2). Expert Determination uses a qualified expert to assess and document that the risk of identification is very small. This guide focuses on Safe Harbor’s listed requirements.
HIPAA Safe Harbor details
Safe Harbor covers identifiers of the individual and of the individual’s relatives, employers, or household members. Its 18 categories include:
- Names; geographic subdivisions smaller than a state; and dates directly related to an individual, except year
- Telephone and fax numbers; email addresses; Social Security numbers; and medical record or health plan beneficiary numbers
- Account numbers; certificate or license numbers; vehicle identifiers and serial numbers; and device identifiers and serial numbers
- Web URLs; IP addresses; biometric identifiers; full-face photographs and comparable images
- Any other unique identifying number, characteristic, or code
For geography, the rule allows an initial three-digit ZIP-code group only when the relevant area’s population exceeds 20,000. If it does not, use 000 for that prefix. Ages over 89 must be grouped as “90 or older.” Dates directly related to an individual must be reduced to the year.
These are specific HIPAA requirements, not a universal recipe for every dataset. Confirm whether the data falls under HIPAA and whether Safe Harbor or Expert Determination is the appropriate route.
GDPR: pseudonymized data is still personal data
Under GDPR Article 4(5), pseudonymization replaces identifiers with other values, while keeping additional information that can link the data back to a person separately. Because that link remains possible, pseudonymized data is still personal data. Article 5(1)(c) also requires data minimization.
Do not describe pseudonymization as anonymization. A dataset is not anonymous merely because names have been removed or replaced. The legal assessment depends on whether people can reasonably be identified using the data and available information.
| Method | What it changes | Main limitation |
|---|---|---|
| Deletion | Removes a field or record | Other details may still identify someone |
| Generalization | Makes a value less precise, such as age 37 to age band 35–39 | Combinations of remaining details can still be identifying |
| Suppression | Hides selected values or rare records | May reduce usefulness and leave other risks |
| Tokenization | Replaces a value with a token | A lookup key or linked system may restore the identity |
| Synthetic replacement | Creates substitute values for a use case | Must be checked for accidental copying or disclosure of real records |
Execution — scrub data in a controlled sequence
Execution applies consistent, field-specific transformations to the full scope identified during planning. A scrub is not complete if the main table is changed but a log, export, or test file still contains the original identifier. Process data under approved access controls, and do not move raw production records into test or vendor environments first.
A practical PII scrubbing workflow
- Survey the data. Inspect fields, free text, metadata, linked tables, and copies. Look for direct identifiers and combinations that may act as quasi-identifiers.
- Choose a transformation for each field. Delete unnecessary fields. Generalize values that need less precision. Suppress rare values where needed. Use synthetic replacements when the task does not require real people’s records.
- Use pseudonyms only when linkage is needed. Tokenization or keyed pseudonyms can support record matching, but the key or mapping data must be stored separately and protected with least-privilege access.
- Apply rules across all in-scope copies. Handle linked tables consistently so transformations do not create accidental links or expose original values elsewhere.
- Check free text and metadata. Names, phone numbers, addresses, and other identifiers can appear in notes, filenames, document properties, or logs. Include these when they are within the approved scope.
- Record the work. Keep the rule set, version, approvals, exceptions, and test results. Limit access to both the source data and any retained mapping information.
Hashing is not proof of anonymization. A predictable value may be guessed, and a stable hash may allow records to be linked across datasets. Replacing names with a stable ID also preserves linkability. Treat either method as a transformation that needs a risk review, not as a guarantee that a person cannot be identified.
Illustrative case studies
These examples show how the same method can produce different results. They are illustrative, not reports of specific organizations or legal determinations.
Health-data analysis: A team wants to share records for a study. Removing names but retaining precise dates, small-area geography, and rare diagnoses may leave a person identifiable. The team should assess the applicable HIPAA method and the recipient’s access to other data. Under Safe Harbor, it must apply the required identifier removals, date rules, age rule, and ZIP-code rule.
Software testing: A team needs data to test how an application handles linked records. Copying production data into a test system before scrubbing expands exposure. A safer design is to use synthetic records when real data is not needed, or apply approved transformations before any transfer, with access restricted throughout.
Customer-service analytics: A report needs monthly trends, not exact customer dates or full addresses. Generalizing dates to month and removing unnecessary location details may preserve the needed trend while reducing exposure. The team still needs to check rare combinations and any exported copies.
Verification — test risk, links, and usefulness
Verification checks whether the transformation worked and whether the remaining data still serves its approved purpose. It must cover direct identifiers, combinations of quasi-identifiers, linked records, and outside information that a likely recipient could access. A clean scan for names is only one check.
Test the dataset against the documented rules. Check for identifiers in structured fields, free text, metadata, and copies. Confirm that linked tables remain consistent and that any key or mapping data is separate, access-restricted, and not included in the release.
Assess re-identification risk
A person may be identified through a combination such as a precise date, a small-area location, and a rare diagnosis. Each field may appear harmless on its own. Together, they can narrow the data to one person, especially when public or commercial records provide matching details.
Review the result in context:
- Who will receive it, and what can they access?
- Could outside data help connect records to named people?
- Are rare values or unique combinations still present?
- Does a stable pseudonym link this dataset to another one?
- Can the dataset’s purpose be met with less detail?
NIST SP 800-188 supports assessing re-identification risk in context, including likely recipients, auxiliary data, and data utility. It does not make simple masking a universal pass. If a review finds too much risk, change the transformations, limit access, or reduce the data shared.
Validate utility and document decisions
Check that the approved use still works after scrubbing. Verify counts, ranges, referential integrity, and the analyses or tests the recipient must perform. If a change harms utility, adjust it only after reviewing the privacy risk again.
Keep a record of the transformation version, approvals, exceptions, and test results. Review the process when the dataset, purpose, recipients, or available outside information changes. The next step is to release only the minimum data needed, under the access controls and terms approved for that use.
Conclusion
Identity masking is a controlled process, not a single operation. Inventory data and copies, select transformations for the purpose and legal context, restrict access to any retained links, and verify both privacy risk and usefulness. Names removed is not the same as people unidentifiable.
FAQ
What is identity masking?
Identity masking changes or removes identifying information to reduce the chance that data can be linked to a person. The method depends on the data and its intended use.
Is PII scrubbing the same as anonymization?
Not always. Scrubbing describes actions taken on data. Whether the result is anonymous depends on whether people can still be identified using the remaining data and information available to others.
Does removing names make a dataset anonymous?
No. Dates, location, rare traits, or combinations of fields may identify someone even after names are removed.
Is pseudonymized data anonymous under GDPR?
No. GDPR treats pseudonymized data as personal data when additional information can link it back to a person.
What is the difference between masking and tokenization?
Masking changes or hides values. Tokenization replaces a value with a token that may be linked back using separate mapping information. That mapping must be protected.
Does hashing personal data anonymize it?
No. Hashing alone does not prove anonymity. Values may be guessed, linked, or tested against other information.
What does HIPAA Safe Harbor require?
It requires removal of 18 identifier categories under 45 CFR §164.514(b)(2), including rules for dates, ages over 89, and certain ZIP-code prefixes. It applies to covered health information.
When can a three-digit ZIP prefix remain under Safe Harbor?
It may remain when the population in the relevant area exceeds 20,000. Otherwise, use 000 for that ZIP-code prefix.
Should production data be copied to a test system before scrubbing?
No. Do not copy production data into test, analytics, or vendor environments before applying approved scrubbing and access controls.
How often should a scrubbed dataset be reviewed?
Review it when its purpose, content, recipient, or access to outside data changes. Those changes can alter the risk of identification.
(This article was written by one of our staff writers, Garrett Vance. Visit our Meet the Team page.)
