One of the most common sources of confusion in privacy is the difference between PII and personal data. The terms get used interchangeably, but they come from different legal worlds and mean different things — and the gap between them trips up many teams building toward GDPR compliance.
This guide explains both concepts, shows exactly where they diverge, and gives you a reliable way to scope your data under GDPR.
The short answer
“PII” and “personal data” are often used as if they mean the same thing, but they don’t. PII (personally identifiable information) is a US concept centred on data that identifies a specific person. Personal data is the GDPR term, and it is considerably broader: it covers any information relating to an identified or identifiable person.
The practical consequence is that a US team applying a “PII” mindset to GDPR will almost always under-scope their obligations — missing data that GDPR clearly protects.
PII vs personal data at a glance
The table highlights where the two concepts diverge. The differences look subtle but have a big effect on what you must protect.
| Aspect | PII (US concept) | Personal data (GDPR) |
|---|---|---|
| Core idea | Information that identifies a specific person | Any information relating to an identifiable person |
| Breadth | Narrower — focused on identifiers | Broader — includes anything linkable to a person |
| Online identifiers | Often excluded or treated inconsistently | Explicitly included (IP, cookie IDs, device IDs) |
| Pseudonymised data | Often considered de-identified | Still personal data — in scope |
| Sensitive subset | “Sensitive PII” (varies by law) | “Special category data” (defined in Art 9) |
| Where used | US laws, standards and policies | EU/UK GDPR |
Free resource
The Ultimate Guide to GDPR
Scope your data correctly with a clear, practical guide to GDPR personal data.
What counts as PII
PII generally refers to information that can identify an individual, either on its own or combined with other data. Definitions vary across US laws and standards, but typical examples include name, Social Security number, passport number, email address and account numbers. Some frameworks split PII into “linked” information (directly identifying) and “linkable” information (identifying when combined with other data).
Crucially, there is no single statutory definition of PII in the US. It shifts depending on the law, sector or organisation using the term, which is one reason it travels poorly to a GDPR context.
What counts as personal data under GDPR
GDPR’s definition is deliberately expansive: any information relating to an identified or identifiable natural person. “Relating to” is the key phrase — the data doesn’t have to identify someone by itself; it is enough that it can be linked to an identifiable person.
That sweeps in obvious identifiers and things a PII mindset often overlooks: IP addresses, cookie identifiers, device IDs, location data, and online behaviour. If it can be tied back to a person, directly or indirectly, GDPR treats it as personal data.
The big gap: online identifiers
The clearest difference is how the two treat online identifiers. GDPR explicitly names IP addresses and cookie IDs as personal data. Many US PII definitions either exclude these or treat them inconsistently.
For a website or app, this single difference is enormous. Analytics, advertising and tracking data that a US team might consider “non-PII” is squarely personal data under GDPR, with all the consent, transparency and rights obligations that follow.
Pseudonymised data is still personal data
Another trap: GDPR makes clear that pseudonymised data — where identifiers are replaced with tokens but a key still exists to re-link them — remains personal data and stays fully in scope. A PII mindset often treats hashed or tokenised data as “de-identified” and therefore out of scope.
Only true anonymisation, where re-identification is no longer reasonably possible, takes data outside GDPR. Pseudonymisation is a valuable security measure, but it is not an exemption.
Sensitive PII vs special category data
Both worlds recognise that some data is more sensitive, but they define it differently. US laws refer to “sensitive PII”, with the contents varying by statute. GDPR defines a specific list of special category data in Article 9 — health, biometrics, race, religion, sexual orientation and more — which is prohibited from processing unless a specific condition applies.
The GDPR list is precise and legally binding, whereas “sensitive PII” is a looser, context-dependent idea.
Handled well, this is one more building block of practical GDPR compliance.
Why the difference matters in practice
The terminology gap causes real compliance failures. Teams that scope their GDPR programme around “PII” routinely miss IP-based analytics, advertising identifiers, pseudonymised datasets and inferred data — then discover the gap during an audit, a data subject request, or a breach.
The fix is simple but important: when working under GDPR, stop thinking in terms of PII and start asking the GDPR question — can this information be related to an identifiable person? If yes, it is personal data.
How to map your data correctly
Build your data inventory around the GDPR definition, not a narrower PII list. For each system, ask what data it holds, whether any of it can be linked to a person directly or indirectly, and how sensitive it is. Treat online identifiers and pseudonymised fields as in scope by default.
This broader lens means your inventory will be larger than a PII-only view — which is exactly the point. You cannot protect, justify or delete data you never recorded as personal in the first place.
A note for US companies
For US organisations expanding into the EU, the shift from PII to personal data is one of the most common early stumbling blocks. The instinct to protect only “identifying” fields leaves analytics, marketing and product-telemetry data unprotected under GDPR.
Reframing early — treating any person-linkable data as personal data — saves painful rework later and aligns your programme with how EU regulators actually interpret the law.
Getting it right
The safest mental model is that personal data is a superset of PII: almost everything that counts as PII is personal data, but plenty of personal data would not be considered PII under a typical US definition. Scope to the broader concept and you cover both.
ISpectra Technologies helps teams build data inventories and classification schemes around the GDPR definition, so nothing person-linkable slips through the cracks. If your current map is built on “PII”, a short review usually surfaces several categories you need to bring into scope.
Don’t forget inferred and derived data
GDPR’s reach extends to inferred and derived data — conclusions you generate about a person, such as a credit score, a risk rating, or a marketing segment. Because these relate to an identifiable individual, they are personal data even though the person never directly provided them.
This is another category a PII mindset tends to miss, since inferred data feels like “your” analytics rather than the individual’s information. Under GDPR, profiling outputs and inferences are firmly in scope and carry their own transparency and rights obligations.
Free consultation
Need help with GDPR?
Talk to our data-protection specialists — we’ll map your fastest path to compliance.
A quick test you can apply
When you are unsure whether something is in scope, run a simple test: could this information, alone or combined with data we hold, single out or be linked to a living individual? If the answer is yes — or even “possibly” — treat it as personal data and protect it accordingly.
This errs on the side of caution, which is exactly where you want to be. Over-protecting a borderline dataset costs little; under-protecting one because it didn’t look like “PII” is how compliance gaps and breaches happen.