Personally Identifiable Information (PII)

Key facts

• The US government formally defined PII in 2007. OMB Memorandum M-07-16 defined PII as information that can distinguish or trace an individual’s identity, alone or combined with other data.
• NIST guidance since 2010. NIST SP 800-122 (April 2010) turned that definition into practical guidance and asks organizations to rate each PII set’s confidentiality impact as low, moderate or high.
• Broader terms in other regimes. The GDPR uses “personal data”, which explicitly includes online identifiers. HIPAA protects “protected health information” (PHI), and the CCPA/CPRA protects “personal information”.
• What protecting it prevents: identity theft, account takeover, payment fraud, targeted phishing, regulatory fines, and loss of customer trust.
• Where it is most exposed: in web and mobile forms, where users type PII into the browser before any server-side control sees it.

How PII is Collected and Exposed

PII is identifying because of context, not just content. A ZIP code alone doesn’t identify anyone. Combined with a date of birth and gender, it can narrow a search to a single person. That is why regulators treat linkable data as PII too.

In a typical web or mobile app, PII moves through five stages. Each one is a point where it can leak.

1. Collection. A user types a name, email, address, card number, or ID into a form, or the app automatically collects device and location data.
2. Processing in the browser. Before submission, the data sits in the page. Every first- and third-party script on that page, including analytics, ad, chat, and AI tags, can read it.
3. Transmission. The data is sent to the organization’s servers over HTTPS, and often also to third parties the page has loaded.
4. Storage and use. Databases, CRMs, data warehouses and logs store PII, and employees and vendors access it.
5. Sharing and disposal. PII is shared with processors and partners, retained for a period, then deleted or anonymized.

Most PII programs focus on stages 3 to 5, where encryption, access control, and DLP apply. Stage 2 is the least governed. The data exists in the browser before any server-side control sees it, and any script on the page can copy it. See Data Leakage.

Types of PII

PII is classified in two ways: by how directly it identifies someone, and by how much harm its exposure can cause.

Direct identifiers

Data that identifies a person on its own: full name, Social Security or national ID number, passport or driver’s license number, biometric records such as fingerprints or face scans, and in most cases an email address or phone number.

Indirect (linkable) identifiers

Data that identifies a person only when combined with other data: date and place of birth, ZIP or postal code, gender, job title, employer, or education records. Attackers and data brokers combine these to re-identify people in “anonymous” data sets.

Online and device identifiers

IP addresses, cookie IDs, advertising IDs, device fingerprints and precise geolocation. US federal guidance treats them as PII when they can be linked to a person. The GDPR and CCPA/CPRA name them explicitly as personal data or personal information. See Browser Fingerprinting.

Sensitive PII

PII whose exposure can cause substantial harm, embarrassment or unfairness: Social Security numbers, financial account and payment card numbers, login credentials, health and medical records, biometric data, and precise location. Sensitive PII needs stronger controls, such as encryption, strict access limits and shorter retention.

Non-sensitive PII

PII that is often public or low-risk on its own: name, business email, work phone, ZIP code. It is still regulated, and attackers use it to build convincing phishing and social engineering attacks or to link to sensitive data.

PII vs Personal Data vs PHI

The three terms overlap but are not interchangeable. PII is a US security and federal-government term. Personal data is the EU legal term, and it is broader. PHI is a narrower US health-care category.

	PII	Personal data (GDPR)	PHI (HIPAA)
Where the term comes from	US federal guidance (OMB M-07-16, NIST SP 800-122) and US state breach laws	EU General Data Protection Regulation, Article 4(1); UK GDPR	US Health Insurance Portability and Accountability Act Privacy Rule
Scope	Data that can distinguish or trace a person’s identity, alone or when linked	Any information relating to an identified or identifiable natural person	Individually identifiable health information held by covered entities and business associates
Online identifiers (IP, cookie IDs)	Included when linkable to a person; varies by state law	Explicitly included	Included when tied to health information (HIPAA lists IP addresses and URLs among its 18 identifiers)
Higher-risk subset	Sensitive PII	Special categories of personal data (Article 9): health, biometric, racial origin and others	All PHI is treated as sensitive
Who must protect it	US federal agencies; any organization under state breach-notification laws	Any organization processing EU or UK residents’ data	Health-care providers, health plans, clearinghouses and their business associates
Typical web exposure	Login, checkout and lead forms	Forms plus tracking cookies and pixels	Patient portals, appointment and symptom forms, health-site tracking pixels

In short: all PHI is PII, and almost all PII is personal data, but personal data also covers things many PII definitions leave out, such as pseudonymous cookie IDs. In California, the CCPA/CPRA term “personal information” is close to the GDPR’s scope. See GDPR Compliance, HIPAA and CCPA.

Why PII Protection Matters

Exposed PII harms the people it describes and the organization that collected it. The risk is highest where PII is first created: in the browser, before server-side controls apply.

• Identity theft and fraud. Stolen PII lets attackers open accounts, take over existing ones, file false claims, and make fraudulent payments. Combining a few indirect identifiers is often enough.
• Targeted phishing and social engineering. Even non-sensitive PII, such as a name, employer and email, makes phishing messages convincing and helps attackers reset passwords.
• Regulatory penalties. The GDPR allows fines of up to €20 million or 4% of global annual turnover, whichever is higher. US state breach-notification laws, the CCPA/CPRA and HIPAA add notification duties, fines and private lawsuits.
• Silent leakage through third-party scripts. Analytics, advertising, session-replay, chat and AI tags run with full page privileges. Without controls, they can collect form fields, URLs and identifiers and send them to destinations the organization never approved, even when no attacker is involved.
• Theft through web skimming. Attackers who compromise a site or one of its suppliers inject code that copies PII and payment data as users type. The page still loads over HTTPS from the real domain, so users see nothing wrong. See Web Skimming and Formjacking.
• Lost trust. A PII incident forces public disclosure, and customers judge the brand, not the vendor whose script leaked the data.

How to Protect PII: Best Practices

Govern PII across your systems

• Map and classify PII. Inventory where PII is collected, stored, processed and shared, and label each data set by sensitivity. See Data Classification.
• Collect only what you need. Data minimization limits the damage of any breach. Drop fields, shorten retention, and delete what no longer serves a purpose.
• Encrypt in transit and at rest. Use TLS for every page and API, and encrypt sensitive PII in databases, backups, and logs.
• Enforce least-privilege access. Restrict who and what can read PII, use multi-factor authentication, and review access regularly.
• De-identify where possible. Tokenize, pseudonymize or anonymize PII for analytics, testing and AI training.
• Assess vendors. Every processor, SaaS tool and script supplier that touches PII is part of your risk. See Vendor Risk Management.
• Prepare an incident response plan. Know your notification deadlines, such as 72 hours to the supervisory authority under GDPR Article 33.

Protect PII where it is created: the browser

• Inventory every script on PII pages. Know which first-, third- and fourth-party scripts run on login, registration, checkout and account pages, and why each is there.
• Restrict which scripts can read form fields. Allow only the scripts that need a field to access it, and block the rest from sensitive inputs, cookies and storage.
• Control where data can be sent. Block scripts from transmitting data to domains you have not approved.
• Monitor for behavior changes. Alert on and stop scripts that start reading new fields or contacting new endpoints during live sessions.
• Use security headers as a baseline. Content Security Policy (CSP) and Subresource Integrity (SRI) limit where code loads from. They do not control what an allowed script does, so pair them with runtime controls.
• Respect consent at runtime. Make sure tags actually stop collecting when a user declines tracking, not just that the consent banner records the choice.
• Keep audit-ready evidence. Log script inventories, blocked data access attempts and changes, so you can show regulators and auditors that controls work.

Solutions by Jscrambler

Most PII controls start once data reaches your servers. Jscrambler protects PII at the point of creation: inside the browser, where users type it and where every script on the page can read it. The Jscrambler Client-Side Security Platform extends enterprise policy into the browser runtime.

• Jscrambler Webpage Integrity continuously discovers third- and fourth-party scripts, maps which ones access sensitive fields, cookies, and storage, and enforces least-privilege data access and outbound network controls in real time. It supports Data Governance & Privacy and AI Data Governance & Security, including control over what embedded chatbots and AI agents can read from the page.
• Jscrambler Code Integrity protects first-party application logic with polymorphic obfuscation and runtime defenses, so attackers cannot easily tamper with the code that handles PII. It supports LLM-Resilient Code Protection.

Webpage Integrity also supports Compliance Enforcement for GDPR, CCPA/CPRA, HIPAA, and PCI DSS v4, with audit-ready reporting. Jscrambler has protected 9B+ user sessions.

FAQs

What are examples of PII?

Common examples are a full name, Social Security or national ID number, passport number, email address, phone number, home address, date of birth, payment card number, login credentials, biometric data and IP address.

Is an IP address PII?

It can be. Under the GDPR and CCPA/CPRA, IP addresses are personal data or personal information. Under US federal guidance, an IP address is PII when it can be linked to a specific person. HIPAA lists IP addresses among its 18 identifiers.

What is the difference between sensitive and non-sensitive PII?

Sensitive PII, such as an SSN, card number or health record, can cause substantial harm if exposed and needs stronger controls. Non-sensitive PII, such as a name or business email, is lower-risk alone but can be combined with other data to identify or target someone.

Is PII the same as personal data?

No. PII is a US term for data that can identify a person. Personal data, the GDPR term, is broader and covers any information relating to an identifiable person, including pseudonymous online identifiers.

Can third-party scripts access PII on my website?

Yes. By default, every script a page loads can read form fields, cookies and the DOM, and send data to external domains. Organizations need runtime controls to limit which scripts can access PII.

Does encryption fully protect PII?

No. Encryption protects PII in transit and at rest. It does not stop a malicious or misbehaving script from reading PII in the browser before it is encrypted and sent.