Personally identifiable information: Definition and examples
Oct 22, 2026
Exposed personally identifiable information (PII) enables identity theft, fraud, and blackmail, and whether data counts as PII depends on context. PII is information that can identify or trace a person, alone or combined with other information, such as a full name, Social Security number, passport number, driver's license number, or biometric data.
Most exposures of personally identifiable information (PII) begin with access, since 75% of sensitive data exposures start with compromised identities or misconfigured permissions, according to the Netwrix 2026 Data and Identity Security Report.
Knowing what counts as PII is the first step toward controlling that access, and the answer depends on context, because a zip code and a birth date can each look harmless yet together point to one person.
Data privacy laws draw the boundary in different places, so one dataset can fall under one regime and be exempt under another.
What is personally identifiable information?
PII, short for personally identifiable information, is any information that can distinguish or trace a specific person's identity, either alone or when combined with other information that is linked or linkable to that person.
The US Office of Management and Budget used this definition in a 2007 memorandum, and the National Institute of Standards and Technology (NIST) carries it forward in SP 800-122, its guide to protecting PII.
A name, a Social Security number, or a biometric record can identify a person alone, while a date of birth or a zip code identifies one only when combined with other data. Since identifiability depends on the surrounding dataset, the same field can be PII in one context and harmless in another.
Aspect | PII | Personal data | Protected health information (PHI) |
|---|---|---|---|
|
Definition |
Information that can distinguish or trace an individual, alone or combined with other linkable information |
Any information relating to an identified or identifiable person |
Individually identifiable health information about health status, care, or payment for care |
|
Where the term is used |
US law and federal guidance |
European Union (EU) law under the General Data Protection Regulation (GDPR) and many other jurisdictions |
US healthcare law under the Health Insurance Portability and Accountability Act (HIPAA) |
|
Regulated by |
A mix of federal sector laws and state privacy laws |
GDPR |
HIPAA Privacy and Security Rules, enforced by the US Department of Health and Human Services (HHS) |
|
Typical example |
A name with a Social Security number |
An online identifier linked to a known person |
A name with a diagnosis or insurance number |
A single system often holds all three. For example, a telemedicine app stores names and emails (PII) next to appointment records and prescriptions (PHI), and any EU user's data in it is also personal data under GDPR.
Linked and linkable information
SP 800-122 defines PII in two parts, and the first covers information that can distinguish or trace an identity, such as a name, Social Security number, or biometric record. The second covers any other information linked or linkable to an individual, such as medical, educational, financial, and employment information.
The guide also ties the label to how easily data identifies someone. Names, fingerprints, and Social Security numbers identify individuals uniquely and directly, while zip codes and dates of birth can identify individuals indirectly or help narrow large datasets.
Context changes the stakes, as NIST's own example shows when it compares two lists with the same fields, such as name, address, and phone number. One lists newsletter subscribers and the other lists people who work undercover in law enforcement, so a breach of each has very different consequences for the individuals and the organization.
Non-PII and when it becomes PII
Information stops being PII when it can no longer distinguish or trace an individual, alone or combined with other information. NIST defines anonymized information as previously identifiable information that has been de-identified and for which no code or other association for re-identification remains.
Anonymization has limits, because NIST notes that de-identified information can be re-identified. Combining datasets can undo it too, since a zip code and a date of birth that look harmless in separate systems can identify one person once they're matched.
PII, personal data, and PHI compared
PII is the US term, and its history explains why the three definitions differ. The 1973 report by the US Department of Health, Education, and Welfare, Records, Computers, and the Rights of Citizens, proposed a code of fair information practices, and Congress used it to draft the Privacy Act of 1974.
In 1980, the Organization for Economic Co-operation and Development adopted guidelines on protecting privacy and transborder flows of personal data, using the broader term personal data.
The term personally identifiable information appears in federal guidance by 2007, in the memorandum cited above, and in NIST SP 800-122, published in April 2010.
Under GDPR, personal data covers any information relating to an identified or identifiable person, and Article 4(1) lists online identifiers among those that can make a person identifiable. A dataset that passes a narrow US PII test can therefore still be regulated personal data in the EU.
PHI is individually identifiable health information about a person's health status, care, or payment for care, held by a covered entity or its business associate, and HIPAA regulates it. A name alone is PII, but a name combined with a diagnosis or insurance number is PHI when a covered entity or business associate holds it.
Examples and types of PII
Five common examples of PII are a full name, a Social Security number, a passport number, a driver's license number, and biometric data such as fingerprints, all of which appear in NIST's own examples.
Each field in the table is classified by how it identifies a person and how much harm its exposure can cause, and the ratings vary by organization and jurisdiction.
Example | Direct or indirect identifier | Sensitive or non-sensitive | Identifies on its own? |
|---|---|---|---|
|
Full legal name |
Direct |
Non-sensitive on its own |
Usually |
|
Social Security number (SSN) |
Direct |
Sensitive |
Yes |
|
Passport, driver's license, state ID, or taxpayer ID number |
Direct |
Sensitive |
Yes |
|
Personal email address or phone number |
Direct |
Non-sensitive |
Yes |
|
Biometric data (fingerprints, retina scans, voice or facial data) or a full-face photograph |
Direct |
Sensitive |
Yes |
|
Credit card or bank account number |
Direct |
Sensitive |
Yes |
|
Medical record |
Direct |
Sensitive (also PHI) |
Yes |
|
Criminal history |
Context dependent |
Sensitive |
Depends on context |
|
Date of birth |
Indirect |
Non-sensitive on its own |
Only in combination |
|
Zip code |
Indirect |
Non-sensitive |
Only in combination |
|
Street address |
Indirect |
Non-sensitive |
Only in combination (identifies a household) |
|
Gender |
Indirect |
Non-sensitive alone |
Only in combination |
|
Employment information (job title, employer, office location) |
Indirect |
Non-sensitive |
Only in combination |
|
Online identifiers |
Indirect (context and jurisdiction dependent) |
Non-sensitive on its own |
Only in combination |
|
Precise location data |
Context dependent |
Sensitive |
Depends on context |
A Social Security number counts as PII even without a name because NIST says it identifies individuals uniquely and directly, making it more sensitive than a phone number or zip code.
A first and last name counts under NIST's definition because it distinguishes an individual, though NIST's incident response roster example shows how little added risk publicly available names and work contact details carry. A birth date alone doesn't identify a person, but combined with a zip code it can.
Direct and indirect identifiers
Direct identifiers point to one person without supporting data. NIST gives names, fingerprints, and Social Security numbers as examples of information that uniquely and directly identifies individuals.
Indirect identifiers point to a person only when combined with other data. NIST cites zip codes and dates of birth as examples, since they can identify individuals indirectly or help narrow large datasets. Each additional field narrows the population further, so a classification program must assess which fields identify together.
Sensitive and non-sensitive PII
Sensitive PII is PII whose exposure could cause serious privacy, financial, or legal harm. NIST's guide formalizes this idea with confidentiality impact levels of low, moderate, or high, indicating the potential harm to individuals and the organization if PII is accessed, used, or disclosed inappropriately.
It notes that a Social Security number, medical history, or financial account information is generally more sensitive than a phone number or zip code.
NIST recommends a risk-based approach, so higher-impact PII requires stronger safeguards. Recommendations include access enforcement, encryption of stored information, and monitoring events that affect PII confidentiality.
Lower-impact PII, such as the names and work contact details in NIST's roster example, still needs protection against being combined with other fields, because combined fields can make sensitive data identifiable.
Netwrix Access Analyzer resolves nested AD groups and SharePoint inheritance to surface overexposed sensitive data. Request a demo.
Laws and regulations that govern PII
No single law defines PII for every purpose. US regulation is sectoral, with separate laws for federal agencies, healthcare, finance, education, and consumers under state law, while the EU and Australia apply national frameworks to personal information.
Payment card data also falls under the Payment Card Industry Data Security Standard (PCI DSS), which applies to entities that store, process, or transmit cardholder data.
Law | Jurisdiction | Who it covers | What it protects |
|---|---|---|---|
|
Privacy Act of 1974 |
US federal |
Federal agencies |
Personal records held by agencies |
|
California Consumer Privacy Act (CCPA), as amended by the California Privacy Rights Act (CPRA) |
California |
For-profit businesses that meet defined thresholds |
Personal information of California consumers |
|
Health Insurance Portability and Accountability Act (HIPAA) |
US federal |
Health plans, clearinghouses, providers, and their business associates |
Protected health information |
|
Gramm-Leach-Bliley Act (GLBA) |
US federal |
Companies offering consumers financial products or services |
Customer information |
|
Family Educational Rights and Privacy Act (FERPA) |
US federal |
Educational institutions receiving US Department of Education funds |
Student education records |
|
General Data Protection Regulation (GDPR) |
European Union |
Organizations processing the personal data of people in the EU |
Personal data |
|
Australian Privacy Act 1988 |
Australia |
Government agencies and organizations with annual turnover above AUD 3 million, plus some others |
Personal information |
Privacy Act of 1974
The Privacy Act gives individuals the right to access records about them and have inaccurate records corrected, and it requires federal agencies to collect records only for lawful, authorized purposes and to safeguard them. It covers federal agencies only.
California Consumer Privacy Act and California Privacy Rights Act
The CCPA gives California consumers the right to know what personal information businesses collect about them, delete it, correct inaccurate information, and opt out of its sale or sharing.
It applies to for-profit businesses that do business in California and meet at least one threshold based on revenue, the number of California consumers whose data they handle, or revenue from selling or sharing personal information.
The CPRA amended the law, added consumer rights and business duties, and took effect on January 1, 2023.
HIPAA
HIPAA applies to covered entities, meaning health plans, health care clearinghouses, and health care providers that transmit health information electronically in standard transactions, as well as their business associates.
Under 45 CFR 164.306, they must ensure the confidentiality, integrity, and availability of the electronic protected health information they create, receive, maintain, or transmit. Under 45 CFR 164.404, a covered entity must notify affected individuals of a breach of unsecured PHI without unreasonable delay and no later than 60 calendar days after discovery.
Gramm-Leach-Bliley Act
GLBA covers companies that offer consumers financial products or services, such as loans, financial or investment advice, or insurance. Its Privacy Rule requires them to tell customers about their information-sharing practices and about the right to opt out of sharing with certain third parties. The Safeguards Rule requires an information security program to protect customer information.
Family Educational Rights and Privacy Act
FERPA applies to educational agencies and institutions that receive funds under a US Department of Education program. It protects education records directly related to a student and maintained by the institution or a party acting for it.
General Data Protection Regulation
GDPR has a territorial scope, set out in Article 3, that covers the processing of personal data about people in the EU. It gives individuals rights of access, rectification, erasure, and data portability, and Article 37 covers the appointment of data protection officers.
Australian Privacy Act 1988
According to the Office of the Australian Information Commissioner, the Privacy Act 1988 regulates how Australian Government agencies, organizations with annual turnover of more than AUD 3 million, and some other organizations handle personal information.
Its 13 Australian Privacy Principles cover the collection, use, and disclosure of personal information; the integrity and correction of that information; and individuals' rights to access it.
How PII is exposed
Documented incidents follow three recurring routes: deceptive messages, unpatched systems, and third-party access.
Phishing
Phishing happens when criminals try to get people to open harmful links, emails, or attachments. The bait can arrive as an email, text, direct message, or phone call, and it's designed to look like it comes from a trusted person or organization.
The warning signs include urgent or emotional language, requests for personal and financial information, untrusted shortened URLs, and incorrect email addresses or links.
Unpatched software
The 2017 Equifax breach shows the cost of a missed patch. The Apache Struts project announced Common Vulnerabilities and Exposures (CVE) entry CVE-2017-5638 and released a patch on March 7, 2017, and the Department of Homeland Security alerted Equifax the next day, yet Equifax did not fully patch its systems.
According to the House Oversight Committee's report, the attackers stayed in the network for 76 days and reached the personal information of about 148 million people, including names, Social Security numbers, birth dates, addresses, and driver's license numbers.
Equifax later agreed to pay at least $575 million, and potentially up to $700 million, in a settlement with federal and state regulators.
Third-party access
The Facebook and Cambridge Analytica case shows how third-party access exposes PII. The Federal Trade Commission (FTC) alleged that a Facebook app built by developer Aleksandr Kogan asked users personality and other questions and also collected information about their Facebook friends.
It further alleged that Cambridge Analytica matched the resulting personality scores with US voter records for profiling and targeted advertising.
Facebook said it may have improperly shared information on up to 87 million people with Cambridge Analytica. In 2019, the FTC imposed a $5 billion penalty on Facebook, the largest ever imposed on any company for violating consumers' privacy.
What happens when PII is mishandled
Consequences fall on the organization that held the data and on the people it identifies.
Fines and regulatory sanctions
Under Article 83 of GDPR, fines reach up to €20 million or 4% of total worldwide annual turnover, whichever is higher. The CCPA allows administrative fines of up to $2,663 per violation and $7,988 per intentional violation, as set in the 2025 adjustment.
HIPAA civil penalties start at $145 per violation and rise with culpability, with a minimum of $73,011 for uncorrected willful neglect, according to HHS's January 2026 inflation adjustment.
Lawsuits and settlements
Settlements can run to hundreds of millions of dollars, as Equifax's did. Under the CCPA, consumers can sue over certain data breaches and recover statutory damages of $107 to $799 per consumer per incident, or actual damages if greater.
Remediation and operating costs
IBM's Cost of a Data Breach Report 2026 puts the global average cost of a breach at a record-high $4.99 million. NIST's guide lists remediation costs, administrative burden, and financial losses among the harms an organization can suffer.
Loss of public trust and market value
NIST lists loss of public trust and legal liability among organizational harms. After Equifax announced its breach, its stock price fell 35 percent in the first week, wiping out $6 billion in market value, according to the House Oversight Committee's report.
Identity theft and financial fraud
According to the FTC, thieves can use stolen personal information to get new credit cards in a victim's name, apply for loans, file fraudulent tax returns to collect refunds, and get medical care or Medicare benefits. NIST names identity theft first among the harms to individuals.
Blackmail and other harm to individuals
NIST lists blackmail, embarrassment, physical harm, discrimination, and emotional distress among the potential harms of a PII breach. Exposing sensitive details can therefore cause damage well beyond financial loss.
How to protect PII
NIST recommends a risk-based approach, so each control below should be tied to a specific repository and the impact level of the PII it holds.
Discover and classify PII
You can't protect PII you don't know about, so start by inventorying where it is stored, processed, and transmitted. Include file shares, databases, cloud apps, backups, and the spreadsheets people export from them.
Then classify data by the harm its exposure would cause, which NIST calls the confidentiality impact level, so a table of Social Security numbers gets stronger safeguards than a staff directory. Repeat the inventory on a schedule, because copies and exports spread PII faster than a one-time audit can track it.
Limit who can reach PII
Grant each person only the access their role needs, under the principle of least privilege, and review it on a schedule. Access that was right at hire accumulates into access that's wrong two roles later.
Assign access through role-based groups instead of to individuals, so a role change updates access in one place. Where possible, let users access PII through an application that limits which records and fields they see, keeping them out of the raw databases and files that hold it.
Collect less and delete on schedule
Every field you collect is a field you have to protect, so ask what decision each one supports and stop collecting the ones that support none. Set a retention period for each PII category, and run deletion as a scheduled job instead of an occasional clean-up project.
Data nobody uses still counts as exposed in a breach. Storing less reduces both the likelihood and scale of harm, making minimization a core part of data lifecycle management.
Encrypt and monitor PII
Encrypt PII at rest on servers, laptops, and backups, and in transit between systems, so a stolen disk or an intercepted connection yields nothing readable. Encryption doesn't stop an authorized account from reading the data, so pair it with monitoring of who opens, copies, and moves PII.
Alert on patterns such as one account reading far more files than usual or PII landing on removable media, and investigate each alert before the data leaves. File access monitoring provides that record for file shares.
Patch systems promptly
Patching protects PII only if you know what you run and can confirm each fix landed. Keep an inventory of internet-facing software, including open-source frameworks and libraries inside your own applications, because you can't queue a patch for a component you don't know about.
Set deadlines by severity and by whether attackers are already exploiting the flaw, with the shortest for the ones they are. CISA says organizations should use its Known Exploited Vulnerabilities catalog as an input to that prioritization.
Then verify with a scan, and check the scan too. After the Struts alert, Equifax's open-source component scan missed the vulnerable version because it ran against a root directory instead of the subdirectory where Struts was listed, and a second scanner checked 958 external IP addresses and found nothing.
Train staff before they get access
Make training a condition of access instead of a first-month task by tying completion to the step that grants access to systems holding PII. Cover what people do with PII in their jobs, which includes how to recognize it, where it may be stored and shared, how to dispose of it, what the retention schedule is, and what sanctions apply to misuse.
Add role-based training for the people who handle the most sensitive PII, such as HR, payroll, and support teams that see customer records. Teach them to recognize a PII incident and where to report one at any hour, and refresh the training on a set schedule using current scams and recent breaches as examples.
Prepare an incident response plan
A PII breach adds decisions that a standard security incident plan skips, and you must make them before an incident. Decide who can declare a PII breach, who sits on the response team, and who speaks to regulators, affected people, and the press.
Give staff one reporting channel that works at any hour, and collect the same facts every time, including what was lost, from which system and storage medium, how many people are affected, and whether law enforcement has been contacted.
Plan notification in advance, including whether it's required, how soon, who sends it, what it says, and whether to offer help such as credit monitoring. Under GDPR Article 33, a controller must notify the supervisory authority within 72 hours of becoming aware of a breach, where feasible, so those decisions can't wait until after the incident.
Preserve evidence before deleting PII from media, because NIST advises against sanitizing it until you've decided whether you must keep it as evidence. Test the plan with a tabletop exercise that simulates a breach, then update it with each lesson learned.
Protect your own PII
CISA's basic practices apply to individuals, too.
- Use strong, unique passwords and keep them in a password manager.
- Turn on multifactor authentication (MFA) wherever it's offered.
- Recognize and report phishing before sharing personal information.
- Install software updates promptly.
How Netwrix helps protect PII
Netwrix products handle four PII jobs: locating it, mapping it to regulations, reviewing who can access it, and stopping it at the endpoint.
Find PII across file servers, SharePoint, and databases
Netwrix Access Analyzer scans file servers, SharePoint, databases, and Amazon S3 for PII, PHI, and payment card data, using pattern-based and context-based rules plus custom rules for organization-specific data.
Rule-based PII detection matches predefined patterns in structured and unstructured data, and Access Analyzer adds context to those patterns. Teams can tune classification rules in different ways to identify sensitive data more accurately.
Map classified PII to GDPR, HIPAA, and PCI DSS
Access Analyzer maps classified PII to GDPR, HIPAA, PCI DSS, and other frameworks. Netwrix Auditor audits activity and includes pre-built compliance mappings for GDPR, HIPAA, PCI DSS, SOX, and the Cybersecurity Maturity Model Certification (CMMC).
At Forreston State Bank, Auditor keeps the bank continuously compliant with Federal Financial Institutions Examination Council (FFIEC) and GLBA requirements, and it saves 8 hours per week in audit preparation.
Review who can open PII and who owns it
Access Analyzer analyzes permissions, identifies overexposed data, determines data owners, and supports access-rights review workflows. Its Effective Access Report calculates effective access from group membership, including nested groups, and flags stale trustee accounts.
Block PII from leaving through USB and web uploads
Netwrix Endpoint Protector enforces content-aware data loss prevention policies at the endpoint. It controls USB storage devices, monitors browser transfers, and blocks uploads of sensitive data to cloud storage and AI tools such as ChatGPT and Microsoft Copilot.
Start with the PII that would do the most harm
NIST's guidance sets a clear order of work. Identify all PII in the environment, rate each repository by the harm its exposure could cause, and apply the tightest safeguards where the rating is highest. Because access failures drive most exposures, tighten who can reach those repositories first.
Ratings change over time because NIST asks organizations to evaluate the sensitivity of PII fields in combination. A dataset that looked low-impact on its own needs a new rating the moment it's joined with another, as when a zip code meets a date of birth.
Teams that treat each new combination as a reclassification event keep their controls matched to the data they hold.
Request a demo to see how Netwrix Access Analyzer finds PII across file shares, SharePoint, and databases and shows who can reach it.
Frequently asked questions about personally identifiable information (PII)
Share on
Learn More
About the author
Netwrix Team
Learn more on this subject
Endpoint DLP as a compliance response: What regulators ask
Continuous posture management vs. point-in-time assessments
What an AD/Entra Hybrid Audit Actually Looks For & Why Most Teams Fail the First One
Netwrix Auditor named to two 2026 Capterra Shortlists
NIST CSF 2.0: What's new in the Cybersecurity Framework