What Is PII? Personally Identifiable Information, Examples, and Why It Is Not the Same as Personal Data

PII, or personally identifiable information, is any information that can be used to distinguish or trace a person's identity, either on its own or when combined with other data that is linked or linkable to that person. That is the US federal definition, from NIST. It covers a name, a Social Security number, a date and place of birth, biometric records, and anything else that gets you to one specific human being.

Here is the part most explainers leave out. PII is a US security term, not a privacy law term, and it is narrower than what privacy laws actually make you find and disclose. The CCPA does not use the phrase. Neither does the GDPR. If you scope a data subject request to your PII inventory, you will under-collect, and the gap is not small.

What does PII stand for?

Personally identifiable information. The term comes out of US federal information security practice rather than privacy legislation, which is why it shows up in security awareness training, breach response playbooks and government handling rules far more often than in the text of any consumer privacy statute.

What is PII, in the official definitions?

There is no single one, which is the first thing to know. Several federal documents define it slightly differently, and NIST's glossary carries all of them side by side.

The most widely quoted is NIST SP 800-122, which defines PII as "any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual's identity, such as name, social security number, date and place of birth, mother's maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information."

OMB Circular A-130, quoted in NIST SP 800-188, trims it to "information that can be used to distinguish or trace an individual's identity, either alone or when combined with other information that is linked or linkable to a specific individual." NIST SP 800-79-2 takes a broader angle: "any representation of information that permits the identity of an individual to whom the information applies to be reasonably inferred by either direct or indirect means."

The common thread across all of them is the two-part structure: information that identifies someone directly, plus information that becomes identifying once you connect it to something else. That second half is where teams consistently under-count, because a row of data that looks anonymous in isolation stops being anonymous the moment it sits next to a customer ID.

What is considered PII? Examples

The useful way to sort examples is not by data type but by how much work it takes to get from the data to the person.

Notice how ordinary most of that is. A support ticket has a name and an email. A shipping record has an address. A web log has an IP address and a device ID. An invoice archive is full of names, addresses and sometimes bank details, and the moment somebody pulls that data out of the PDFs into a spreadsheet for reporting, a second copy exists that nobody added to the inventory. Almost none of this lives in the system you would name first if asked where you keep personal data, and a mature data governance program will not close that gap either, because it indexes data by asset rather than by person.

Is an IP address PII?

Usually yes, and under privacy law almost always. NIST treats an IP address as linkable information, so it is PII when it can reasonably be connected to a person. Under the GDPR the question is settled: the Court of Justice of the European Union held in Breyer that a dynamic IP address is personal data in the hands of a party that has legal means to identify the user. The CCPA removes the ambiguity entirely by naming "internet protocol address" in its list of identifiers at Civil Code 1798.140(v)(1)(A).

The practical version: if you can tie the address back to an account, a session, or a person, treat it as in scope. Most companies can, because the same log that holds the IP address usually holds a user ID two columns over.

Is an email address PII?

Yes. An email address is a direct identifier in almost every framework, and even a role-based address like [email protected] is PII once it is associated with a named individual in your records. This one matters operationally more than it looks, because email addresses are the join key that stitches a person's data together across systems. If you are trying to find every record about one person, the email address is usually how you do it, and it is also one of the things you have to return.

PII vs personal information vs personal data

This is the distinction that costs money to get wrong. The three terms are not synonyms, and the two that appear in enforceable privacy law are both broader than the security term.

Three gaps open up when you scope a request off a PII list.

Households. The CCPA protects a "particular consumer or household". PII is defined around an individual. Anything you hold at household level, a shared account, a service address, a set of devices grouped by network, is personal information in California and is invisible to a PII inventory that only indexes person records.

Inferences. The CCPA lists inferences drawn to create a profile reflecting someone's preferences, characteristics, predispositions, behavior and attitudes as a category of personal information in its own right, at 1798.140(v)(1)(K). And this is not theoretical. In March 2022 the California Attorney General issued Opinion No. 20-303, the first AG opinion interpreting the CCPA, concluding that internally generated inferences a business holds about a consumer are personal information that must be disclosed in response to a right to know request. That holds even when the underlying data was exempt from the CCPA when it was collected. Trade secrets remain fully protected, but the opinion is clear that a business withholding inferences on that basis has to show the information derives independent economic value from not being generally known and that it made reasonable efforts to keep it secret. A scoring model output sitting in your warehouse is squarely in range.

Online identifiers. Cookie IDs, device identifiers, advertising IDs and probabilistic identifiers get treated as non-PII by a lot of internal documentation, on the reasoning that they do not name anybody. Both the CCPA and the GDPR name them anyway. The CCPA even defines a "unique personal identifier" as a persistent identifier that can recognize a consumer, a family, or a device linked to a consumer or family, over time and across services.

What is not PII?

Genuinely aggregated and genuinely deidentified data. The CCPA excludes both at 1798.140(v)(2), along with publicly available information and lawfully obtained truthful information that is a matter of public concern. The GDPR takes the same position on anonymous data in Recital 26.

The word doing the work in both is "genuinely". Deidentification means the data cannot reasonably be re-linked to a person and that you have committed not to try. Stripping names from a table that still contains a customer ID, a ZIP code and a birth date is pseudonymization, not anonymization, and pseudonymized data is still in scope under both regimes. That distinction is the most common place a scoping decision goes wrong, and it goes wrong in the direction that leaves records out of a response.

Why this matters for a data subject request

When someone submits an access or deletion request, the standard you are held to is the statute's, not NIST's. In California that means everything that identifies, relates to, describes, is reasonably capable of being associated with, or could reasonably be linked to that consumer or their household. Under the GDPR it means any information relating to them. Both are broader than a PII checklist, and you have 45 days under the CCPA or one month under the GDPR to be right about it.

Which turns a definitional question into a search problem. The obligation is not to list the categories of data you hold, it is to find the actual records, in every system, including the ones nobody registered: the legacy database, the internal admin tool, the warehouse table built for one analysis in 2023, the shared drive, the support inbox. Our guide to what a DSAR is covers the request lifecycle, and the CCPA compliance checklist covers the surrounding obligations.

Two practical steps close most of the gap. First, index by identifier rather than by system: pick the join keys you actually use, usually email address, customer ID and phone number, and confirm which of them each system stores, because that is what determines whether you can find a person there at all. Second, write down where derived data lives. Scores, segments, propensity models and enrichment outputs are the records least likely to appear in a data map and, after Opinion 20-303, among the clearest to be in scope in California.

Then keep a human in front of the disclosure. A response that sweeps broadly will pull in records that mention other people, and third-party data has to come out before anything is sent. That is a judgment call, not a filter, which is why redacting third-party data is a review step rather than an automated one.

Obtainer is built around exactly this problem: AI-native discovery that finds where a person's data actually lives across your systems, one reviewable manifest of what came back, a drafted response, and tracking on the statutory clock, with a human redaction and approval gate before anything leaves. It covers the full set of data subject rights under both the CCPA and the GDPR.

Obtainer helps you comply; it is not legal advice, and scoping decisions stay with your team.