What Is PII? Definition, Examples, PII vs PHI

PII stands for personally identifiable information: data that identifies a particular person, either by itself or when put next to something else. That much is uncontroversial. The trouble starts one question later, when somebody asks whether a specific field in front of them counts, because four different bodies of law answer that differently and all four are in force.

This post gives each of the four definitions, the examples that fall under them, the two questions people actually arrive with, which are about email addresses and IP addresses, and the line between PII and PHI. It also covers the distinction that matters most if your job is to find this data rather than to argue about it, which is not a legal distinction at all.

The reference definition in the United States comes from the National Institute of Standards and Technology, in Special Publication 800-122. PII is any information about an individual maintained by an agency that can be used to distinguish or trace that individual's identity, and any other information linked or linkable to them. The phrase doing the work there is linked or linkable. A record does not have to name someone to identify them.

That gives you two kinds of identifier. Direct identifiers point at one person on their own: a full name, a national insurance or social security number, a passport number, an email address. Indirect identifiers do not, until you combine them. A date of birth is not identifying. A postcode is not identifying. A date of birth plus a postcode plus a gender narrows most populations to a handful of people, and in many cases to one, which is why de-identification standards care about combinations rather than fields.

Under NIST and US federal practice, PII is framed around information an agency holds about an individual, and the guidance is risk-based rather than a fixed list. Under the GDPR, Article 4(1) defines personal data far more broadly: any information relating to an identified or identifiable natural person, where identifiable includes indirect identification by reference to an identifier such as a name, an identification number, location data, an online identifier, or factors specific to that person's physical, physiological, genetic, mental, economic, cultural or social identity. That last clause is deliberately wide, and European regulators have read it widely.

HIPAA is narrower in a different direction. Protected health information, defined at 45 CFR 160.103, is individually identifiable health information held or transmitted by a covered entity or its business associate. Two conditions have to hold at once. The information has to relate to health, care, or payment for care, and it has to sit with a covered entity. The same blood test result in a hospital record is PHI; in a note you typed into a personal spreadsheet, it is not, though it is still personal data under the GDPR.

California is broader than any of them. The CCPA, as amended by the CPRA, defines personal information as information that identifies, relates to, describes, is reasonably capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular consumer or household. Household is the word that makes it unusual. A smart meter reading tied to an address is personal information in California in a way it is not obviously personal data elsewhere.

The consequence is practical rather than academic. A field is not PII in the abstract. It is PII under a named law, for a named organisation, in a named context, and a redaction policy that is correct for a HIPAA disclosure can be wrong for a GDPR subject access request. If a compliance conversation is going in circles, it is usually because two people are using the word against two different definitions.

Now the split that decides whether software can help you at all. Structured identifiers are the ones with a shape. A credit card number is sixteen digits that satisfy the Luhn checksum. An IBAN carries its own check digits. A national ID number has a fixed length and often a validation rule. These can be found by pattern with high precision, they can be validated rather than guessed at, and they work the same way in any language, because the shape does not change when the surrounding sentence is in German.

Contextual identifiers have no shape at all. A person's name is a sequence of letters that is a name because of where it sits. So is a street address, an employer, a job title, a diagnosis. Finding these needs a model that reads the sentence, not a pattern that matches a string, and that is a genuinely harder problem: the same word can be a surname, a town, or a brand depending on the clause around it.

Almost every disappointment with a detection tool traces back to this line. Tools built on patterns are excellent at the structured half and blind to the contextual half. Tools built on language models are the reverse, and will confidently mislabel a validated identifier. We publish our own numbers on both halves against Google Cloud DLP: the Fast tier recognises 191 of the 213 kinds of sensitive text Google detects, and the Accuracy tier is the one that handles running prose, which is where names and places live.

Sensitive PII versus non-sensitive PII is a US framing, and it is about consequence rather than definition. Non-sensitive PII is information that is identifying but low harm if disclosed: a name, a work telephone number, a job title, much of which is on a business card or a public staff page. Sensitive PII is information whose disclosure creates real risk of harm, fraud or discrimination: a social security number, financial account details, biometric data, immigration status, health information. The categories are not statutory, and the practical use of the distinction is that it sets how hard you protect a field, not whether it counts.

The GDPR has a stricter version of the same idea, and it is statutory. Article 9 names special categories of personal data: racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic and biometric data processed to identify someone, health data, and data concerning sex life or sexual orientation. Processing these is prohibited by default, with a list of specific exceptions. This is not a stronger flavour of ordinary personal data. It is a separate legal regime with its own lawful bases.

Is an email address PII? In almost every case, yes. Under the GDPR it is an identifier that relates to an identifiable person, and a work address of the form firstname.lastname at company is a name and an employer joined by a dot, which identifies someone more precisely than most fields on a form. California lists email addresses explicitly. Under NIST it qualifies whenever it can be linked to a person, which a personal or named work address plainly can. The only arguable case is a genuinely shared functional address such as an enquiries mailbox, and even that is worth treating as personal data if a single person reads it.

Is an IP address PII? Under the GDPR, yes for practical purposes. The Court of Justice held in Breyer that a dynamic IP address is personal data in the hands of a website operator where that operator has legal means reasonably likely to be used to identify the subscriber, with the help of a third party such as the access provider. California lists IP addresses among the categories of personal information. In the United States there is no single federal answer and it turns on the sector and the context, which is a real difference rather than a hedge.

PII versus PHI is the pair that causes the most confusion, and the relationship is simple once stated. PII is the general category of information that identifies a person. PHI is a narrower subset defined by HIPAA: identifying information that relates to health, care or payment for care, and that is held by a covered entity or a business associate. All PHI is PII. Most PII is not PHI. HIPAA also does something no other regime here does, which is to make the list concrete: the eighteen Safe Harbor identifiers enumerate exactly what has to come out for a record to count as de-identified, which turns an argument into a checklist.

Finding PII is only half of the work, and it is the half people talk about. The other half is deciding what happens to each kind once it is found, and that decision is per type, not per document. A name in a clinical letter and an account number in the same letter should not receive the same treatment, because the letter has to stay useful after you are finished with it. Omit applies one operator per entity type: label it with its type, black it out, mask all but the last few characters, hash it, keep it, replace it with a consistent fake value that preserves the format, reduce a date to its year, or reduce a name to initials. Those last two exist because a court rule asks for exactly those shapes, which is covered in the post on redacting a court filing under Rule 5.2.

Which treatment you choose has a legal consequence, and the words for the treatments are used loosely enough that it is worth being precise: redaction, anonymisation and pseudonymisation are three different operations with three different outcomes under the GDPR, and pseudonymised data is still personal data. It is worth knowing what redacted actually means before relying on a tool that claims to do it. Region matters too, because which identifiers even exist depends on where you are: the recogniser set is a setting, so a run configured for the EU looks for different national identifiers than one configured for the US.

Two last practical points. First, confirm that a value is actually gone rather than covered, because the most common redaction failure is a black rectangle drawn over text that is still in the file. Second, the moment PII is most likely to leave your control is not a breach, it is an ordinary paste into a chat window, which is why what a general purpose AI assistant does with what you type is worth knowing before you type it, and why the clipboard guard in Protect is free for everyone permanently.

Omit Redact finds and removes this data in documents, spreadsheets, images and email, entirely on your own machine, with no upload, no account and no API key. There is more on the architecture behind that claim on the security page, and on what it means for patient records in particular on the healthcare page.