PII Redaction: How to Find and Redact Personal Data in Files and Databases

Which columns, files and documents in your organization contain PII?

In most companies, the answer is a rough estimate.

Teams rely on column names, on what people remember, or on a data inventory done years ago.

But PII redaction starts with finding the data: you cannot redact what you have not found.

What is PII, and how is it different from personal data?

PII stands for personally identifiable information: any information that can be used to identify a person, alone or combined with other data.

Europe uses a different term, personal data, defined by GDPR.

The two overlap, with a few differences worth knowing.

	PII (US usage)	Personal data (GDPR)
Definition	Information that can distinguish or trace an individual’s identity	Any information relating to an identified or identifiable natural person (Article 4)
Examples	Name, Social Security number, email, phone number, address, date of birth, account number	The same, plus IP addresses, customer IDs, cookie identifiers and any data linked to a person
Most protected	Sensitive PII: SSN, financial account numbers, health information	Special categories (Article 9): health, racial or ethnic origin, political opinions, religious or philosophical beliefs, union membership, genetic and biometric data, sex life or sexual orientation

A person can be identified directly (a name, an SSN) or indirectly, by cross-referencing (a ZIP code, a date of birth, a job title).

These indirect identifiers need to be spotted too.

Whatever the regulation, from CCPA in California to GDPR in Europe, protecting PII starts with knowing where it is.

Where does PII hide?

Columns called email, phone or date_of_birth are obvious.

The real risk is elsewhere.

1. Free-text fields.
   A “notes” or “comments” column can hold a full address, an ID number or a medical detail typed in by hand.
2. Badly named columns.
   A column called customer_info, reference or metadata says nothing about what it actually contains.
3. Reports and written documents.
   In a letter, a case file or a report, names and personal details are in the body of the text.
4. Cell comments and metadata.
   A file’s author, the last person who modified it, or a note added to a cell go unnoticed on screen.
5. CSV exports and Excel files.
   They travel by email, between departments and to vendors, often wrongly treated as “technical” files.
6. PDF, Word and PowerPoint files.
   Contracts, case files and slide decks mix personal data with useful content.
7. Database copies.
   Test environments, backups, legacy tables and old imports that were never documented.

Why manual PII review fails

1. Volume.
   Hundreds of tables and thousands of files: nobody rereads everything.
2. Names do not reflect content.
   An audit based on column headers misses free text, where a good part of the risk sits.
3. Data keeps moving.
   New columns, new imports, new exports: an inventory is out of date as soon as it is finished.
4. Human error.
   A tired reviewer misses a number in the middle of a paragraph, especially in the hundredth document.

How automated PII detection works

Reliable detection combines several signals.

1. Rules.
   They recognize known formats: the structure of an email address, an IBAN, a phone number, an IP address or a bank card number.
2. Contextual analysis.
   It reads the sentence around a word to spot a person’s name or personal detail, even without a fixed format.
3. Column names and structure.
   The column name, the type of values and how often they repeat confirm or temper each detection.
4. A confidence level.
   Each detection is ranked, so your team reviews uncertain cases first.

This combination is what flags the “notes” column of a customer export: badly named, but full of PII.

Map the data before you redact it

Detection is not an end in itself.

It lets you decide with the facts in hand.

Take a common case: a team prepares test data from a CRM export considered “internal”.

After a scan, the file turns out to contain emails, phone numbers, customer IDs, login IP addresses and dates of birth in a secondary column.

The risk does not come from bad intent, but from a lack of visibility.

A sound sequence looks like this:

1. Identify.
   Scan the file or database without changing anything.
2. Qualify.
   Decide what is actually needed for the intended use, and leave the rest out (data minimization).
3. Redact or pseudonymize.
   Choose the right method for each data type.
4. Document.
   Keep a report of what was detected and processed.
5. Share only if needed.
   Only the protected version leaves.

Redaction or pseudonymization: which one?

PII redaction and pseudonymization do not serve the same purpose.

	Redaction	Pseudonymization
What it does	Removes the value, or replaces it with its type	Replaces the value with a fake but consistent one
Example	John Carter → [PERSON]	John Carter → David Miller, or PERSON_7b94f21c
Data stays usable	No, the value is gone	Yes, the structure and links between records are kept
Typical use	Documents shared outside, court filings, public releases	Test data, analytics, training AI models

For test environments, pseudonymized data keeps your applications working, as explained in our article on data masking for test data.

The legal difference between the two is covered in pseudonymization vs anonymization.

With NymData

NymData detects and redacts PII in your files (PDF, Word, Excel, PowerPoint, CSV, text) and in your PostgreSQL and MySQL databases, on your own servers:

1. Mapping mode.
   The scan changes nothing, and the report of the data found can be reviewed before any action, for folders and databases alike.
2. Rules plus contextual analysis.
   Known formats and free text are both analyzed, including Excel cell comments, and column names and structure help confirm each detection.
3. Review by confidence level.
   Detections are ranked high, medium or low confidence.
4. Allow list.
   Terms that must never be redacted, such as your organization’s name, stay untouched.
5. The method you choose.
   Anonymization by type ([PERSON], [EMAIL]), realistic pseudonymization, a constant identifier that gives the same value the same identifier across the whole project, or a custom method per data type; the author of Office files is cleared.
6. PDF redaction.
   In PDFs, PII is covered by opaque black boxes burned into the page, as described in how to redact a PDF.

For spreadsheets, see our page on Excel and CSV anonymization.

See how NymData works