PII, short for personally identifiable information, is any information that can be used to distinguish or trace the identity of a specific individual, either on its own or when combined with other information that is linked or linkable to that person. In privacy fundamentals, PII is the central category of data that privacy programs inventory, protect, minimize and eventually delete.
The term comes mainly from United States law and practice, including federal guidance such as NIST SP 800-122, sector laws and state breach notification statutes. European law uses the broader concept of personal data, and the two terms are often treated as synonyms even though their scope differs.
What makes information personally identifiable
Information is PII when it identifies a person directly or when it can be linked to a person with reasonable effort. Identifiability therefore depends on context: the same data point may be harmless in one dataset and identifying in another that contains matching details.
Practitioners usually distinguish direct identifiers from indirect identifiers, also called quasi-identifiers. The table gives typical examples.
| Category | Examples | Identification risk |
|---|---|---|
| Direct identifiers | Full name, government ID number, email address, face image | Identify a person on their own |
| Quasi-identifiers | Birth date, postal code, gender, job title | Identify when combined |
| Device and online identifiers | IP address, advertising ID, cookie ID | Identify through linkage to accounts |
| Linked data | Purchase history tied to an account | Inherits the identity of the account |
| Aggregated statistics | Counts above a safe threshold | Low, unless groups are very small |
Combinations of quasi-identifiers are surprisingly powerful. Research on public records has repeatedly shown that birth date, postal code and gender together single out a large share of a population, which is why removing names alone does not make a dataset anonymous.
Sensitive PII and risk levels
Not all PII carries the same risk. Many organizations classify sensitive PII separately, meaning information whose exposure could lead to identity theft, financial loss, discrimination or physical harm. Sensitive PII normally requires stronger controls and triggers breach notification duties in many jurisdictions.
| Tier | Examples | Typical controls |
|---|---|---|
| Public or low risk | Business contact details, published names | Access control, accuracy |
| Moderate risk | Home address, personal phone, purchase history | Encryption, role-based access, logging |
| Sensitive PII | Social Security number, passport, bank account | Strong encryption, masking, strict need to know |
| Special or regulated data | Health, biometric, children’s data | Legal basis checks, sector rules, audits |
Sector laws add their own definitions. Health information handled by covered entities falls under HIPAA as protected health information, financial customer data under GLBA, and data about children under 13 collected online under COPPA.
PII compared with personal data and related terms
The distinction between PII and personal data matters for companies that operate across regions. GDPR defines personal data as any information relating to an identified or identifiable natural person, which deliberately includes online identifiers and pseudonymous records that some narrow PII definitions omit.
| Term | Origin | Scope |
|---|---|---|
| PII | United States practice and guidance | Data that identifies or can be linked to a person |
| Personal data | GDPR and European law | Any information relating to an identifiable person |
| Personal information | CCPA and other state laws | Broad, includes household and inferred data |
| Pseudonymous data | Privacy engineering | Identifiers replaced, re-linkable with a key |
| Anonymous data | Privacy engineering and law | Not reasonably re-identifiable by anyone |
A practical consequence is that pseudonymized data remains personal data under GDPR, because the organization holding the key can re-identify people. Only properly anonymized data falls outside its scope, and true anonymization is difficult to prove.
Protecting PII in practice
Protecting PII starts with knowing where it is and why it is held. A data inventory maps systems, fields, purposes and retention periods, and it allows the organization to apply data minimization: collecting only what a defined purpose actually needs.
| Technique | How it works | Best suited for |
|---|---|---|
| Data minimization | Avoid collecting or keeping unneeded fields | Every system, first line of defense |
| Encryption | Makes stored or transmitted data unreadable without keys | Databases, backups, network traffic |
| Masking | Shows partial values such as last four digits | Support screens and reports |
| Tokenization | Replaces values with tokens held in a vault | Payment and identity numbers |
| Access control and logging | Limits and records who sees what | Internal tools and analytics |
| Retention limits | Deletes data after its purpose ends | Logs, archives, inactive accounts |
In the relationship between a data controller and a data processor, both sides need clear contractual rules on how PII is handled, secured and returned or deleted at the end of a service.
Common mistakes in handling PII
The most frequent error is assuming that data is safe because obvious identifiers were removed. Other recurring problems include PII copied into application logs, analytics events and support tickets, where it escapes the controls applied to the main database.
- Logging full request bodies that contain names, emails or tokens.
- Copying production data into test environments without masking.
- Keeping data indefinitely because no retention rule was defined.
- Sharing small-group statistics that reveal individuals.
The simple explanation
PII is any information that can point to a particular person. A name or a passport number does this directly. A birth date, a postal code and a job title can do it together, like puzzle pieces that form a recognizable picture.
Because this information can be misused, organizations must collect only what they need, keep it locked away and delete it when it is no longer useful.
How it is used in practice
An online retailer prepares a customer dataset for an outside analytics agency. The first draft removes names and email addresses but keeps full birth dates, five-digit postal codes and order histories. A privacy review finds that these quasi-identifiers could re-identify many customers when combined with public records.
The team replaces customer IDs with random tokens, reduces birth dates to birth years, shortens postal codes to regional prefixes, and suppresses groups with fewer than ten customers. The contract with the agency defines it as a processor, forbids re-identification attempts and requires deletion after the project.
The agency still receives enough detail to analyze regional buying patterns, while the retailer sharply reduces the risk that any individual customer can be identified from the shared file.