GDPR and PII: How EU Law Defines Personal Data Differently

If you handle data about people in Europe, the relationship between GDPR and PII is the first thing worth getting straight. Personally identifiable information (PII) is a United States concept, while the General Data Protection Regulation (GDPR) uses a broader term called personal data, and treating them as interchangeable is how compliance programs end up with gaps. This guide explains the difference, what actually counts as personal data in the EU, and how to apply that to your website. It is educational rather than legal advice, so consult a qualified attorney for guidance specific to your business.

What PII Means and What Personal Data Means

PII is information that can be used to distinguish or trace an individual's identity, either on its own or when combined with other data. That wording comes from NIST Special Publication 800-122, the reference definition most US organizations use. US privacy law has no single federal PII definition, so the scope shifts between sectoral laws like HIPAA, GLBA, and COPPA.

GDPR does not use the phrase PII at all. Article 4(1) defines personal data as "any information relating to an identified or identifiable natural person," and an identifiable person is one who can be identified "directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier."

That single phrase, "directly or indirectly," is the entire difference. A US PII analysis asks whether the data points at a specific person. A GDPR analysis asks whether the data relates to someone who could be singled out, by you or by anyone else with reasonably available means.

The practical result is that many datasets a US team labels as anonymous or non-PII are regulated personal data in the EU.

GDPR and PII: The Core Differences

Aspect	PII (US)	Personal data (GDPR)
Source	NIST SP 800-122, sectoral laws	Article 4(1) GDPR
Test	Distinguishes or traces identity	Relates to an identified or identifiable person
Online identifiers	Often excluded	Explicitly included (Recital 30)
IP addresses	Frequently treated as non-PII	Personal data (CJEU, Breyer C-582/14)
Pseudonymized data	Often treated as de-identified	Still personal data (Recital 26)
Sensitive categories	Varies by sector	Defined list in Article 9
Scope trigger	Sector or state law	Any processing of EU residents' data (Article 3)

Three of these rows cause most real-world compliance failures:

1. Online identifiers. Recital 30 of the GDPR names IP addresses, cookie identifiers, and radio frequency identification tags as identifiers that may leave traces which, combined with unique identifiers, create profiles of natural persons.
2. Pseudonymization. Replacing a name with a random ID reduces risk and is encouraged by Article 32, but Recital 26 confirms pseudonymized data remains personal data because a key still exists.
3. Territorial reach. Article 3(2) applies GDPR to organizations outside the EU that offer goods or services to, or monitor the behavior of, people in the EU.

What Counts as Personal Data Under GDPR

Personal data extends well past the fields most people picture. When mapping your systems, treat all of the following as in scope:

• Direct identifiers: full name, email address, phone number, national ID number, passport number, customer account number.
• Online identifiers: IP address, cookie ID, advertising ID (IDFA, GAID), device fingerprint, MAC address, session token.
• Location data: GPS coordinates, approximate location derived from IP, store visit data, delivery addresses.
• Behavioral and usage data: pages viewed, clickstream, purchase history, support tickets, scroll depth tied to an identifier.
• Employment and financial data: salary, job title with employer, bank details, invoice history.
• Inferred data: credit scores, propensity scores, audience segments, and any profile you build about someone.
• User-generated content: photos, voice recordings, chat messages, and review text where authorship is traceable.

Note that inferred data counts. If your analytics platform assigns a visitor to a "high intent buyer" segment, that inference is personal data about an identifiable person, and the person has a right of access to it under Article 15.

Special Category Data Gets Stricter Treatment

Article 9(1) of the GDPR prohibits processing of data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data used for unique identification, health data, and data concerning sex life or sexual orientation. Processing is only lawful if one of the exceptions in Article 9(2) applies, such as explicit consent or a substantial public interest laid down in law.

This category is narrower than what US frameworks call sensitive PII, but the conditions attached are considerably harder to meet. If you run a health coaching site or a dating app, this article governs your core dataset. Criminal conviction data sits in a separate regime under Article 10.

What Is Not Personal Data

Data leaves GDPR scope only when identification becomes impossible. Recital 26 sets the standard: account should be taken of all the means reasonably likely to be used to identify the person, considering cost, time, and available technology.

Genuinely out of scope:

• Truly anonymized data, where the linkage to individuals has been irreversibly destroyed and no key exists anywhere.
• Aggregate statistics with sufficiently large groups, such as "4,200 visitors from Germany in June."
• Data about legal entities, though a named contact at a company remains personal data.
• Data about deceased persons, per Recital 27, unless national law extends protection (Spain, France, and Italy do).

Anonymization is harder than most teams assume. The Article 29 Working Party opinion 05/2014 on anonymization techniques concluded that many common methods, including simple hashing of identifiers, fail because the result is still singling out an individual. A hashed email address is pseudonymous, not anonymous, since the same input always produces the same hash.

For a deeper walkthrough of the boundary, see the guide on what is not personal data.

Why the GDPR and PII Distinction Changes Your Obligations

Classifying data correctly is not paperwork. Each obligation below attaches to personal data, so a narrow PII-based inventory produces a compliance program with holes in it.

• Lawful basis (Article 6). Every processing operation needs one of six bases: consent, contract, legal obligation, vital interests, public task, or legitimate interests. You must select and document it before processing starts.
• Transparency (Articles 13 and 14). You must tell people what you collect, why, for how long, who receives it, and what rights they have, at the point of collection.
• Data subject rights (Articles 15 to 22). Access, rectification, erasure, restriction, portability, objection, and rights around automated decision-making all apply to every category of personal data you hold.
• Breach notification (Articles 33 and 34). You must notify the supervisory authority within 72 hours of becoming aware of a personal data breach that poses a risk to individuals.
• Records of processing (Article 30). Most organizations must maintain a written record of processing activities covering purposes, categories of data, recipients, and retention periods.
• Security (Article 32). Technical and organizational measures must be appropriate to the risk, with pseudonymization and encryption named as examples.

Miss the classification and you miss all six. A team that decides cookie IDs are "not PII" ends up with no lawful basis for its advertising tags, no disclosure in its privacy notice, and no way to honor an erasure request.

PII and GDPR in Practice: Website Tracking

The gap between PII and GDPR thinking shows up most clearly in web analytics and advertising. Consider an online store based in Chicago that ships to Ireland.

Its analytics stack sets a first-party cookie with a random visitor ID, records IP address, and passes an advertising ID to a remarketing pixel. Under a US PII analysis, none of that is a name or an email, so it might be treated as anonymous traffic data. Under GDPR, every element is personal data, and each element needs a lawful basis plus disclosure.

Non-essential cookies also engage a separate law. Article 5(3) of the ePrivacy Directive requires consent before storing or accessing information on a user's device, regardless of whether the information is personal data. GDPR then supplies the consent standard: freely given, specific, informed, and unambiguous under Article 4(11), with no pre-ticked boxes per Recital 32.

Regulators have enforced this repeatedly. France's CNIL fined Google 150 million EUR and Meta 60 million EUR in January 2022 for making cookie refusal harder than acceptance. The GDPR cookie consent rules and the practical setup are worth reviewing separately if you run tracking scripts.

Steps to Bring Tracking Into Scope

1. Scan your site to produce a complete list of cookies, tags, and third-party requests. Most sites carry trackers nobody on the current team added.
2. Classify each one as strictly necessary or non-essential. Only strictly necessary cookies escape the consent requirement.
3. Block non-essential scripts until consent is recorded. A banner that only appears while tags already fire is not compliance.
4. Record consent with a timestamp and the version of the notice shown, since Article 7(1) requires you to demonstrate that consent was given.
5. Disclose everything in your cookie policy and privacy notice, naming the third parties that receive data.

TermsBox handles steps one through four with a compliance scanner and consent banner, then keeps the resulting cookie policy in sync when the scanner detects a new tracker.

Mapping Your Personal Data: A Practical Method

Article 30 records are the natural output of a data mapping exercise, and the exercise itself is what surfaces the GDPR and PII gap in your own systems. Work through it in this order:

1. List every system that touches user data: website, analytics, CRM, email platform, payment processor, support desk, ad platforms, backups, and internal spreadsheets.
2. For each system, list the data fields it stores, including the ones nobody chose deliberately such as server access logs.
3. Apply the Article 4(1) test to each field: could this, alone or combined with other data you or a third party holds, single out a person? If yes, it is personal data.
4. Flag Article 9 categories separately, since they need their own lawful basis and usually a data protection impact assessment under Article 35.
5. Record the lawful basis, purpose, retention period, and recipients for each processing activity.
6. Note international transfers and the safeguard used, such as Standard Contractual Clauses or the EU-US Data Privacy Framework.

Server logs deserve specific attention. They almost always contain IP addresses and user agent strings, which makes them personal data with a retention period you need to define and justify.

Handling Data Subject Requests Across Both Frameworks

When someone asks what you hold about them, the scope of your answer depends on the definition you use. Under Article 15, a data subject access request covers all personal data, not just the profile fields in your account database.

A complete response typically has to reach:

• Account and profile records.
• Order, billing, and support history.
• Marketing preferences and email engagement data.
• Analytics and advertising identifiers linked to that person.
• Inferred segments, scores, and internal notes about them.
• Backup copies, where technically retrievable.

You have one month to respond under Article 12(3), extendable by two further months for complex requests, and you cannot charge a fee for the first request. The subject access request process is worth documenting before the first one arrives, because a month passes quickly when data is spread across seven systems.

Erasure requests under Article 17 raise the same scope question. Deleting the user row while leaving their advertising ID in a remarketing audience is an incomplete erasure.

Writing a Privacy Notice That Reflects GDPR Scope

Your privacy notice is where the classification work becomes visible to users and regulators. Articles 13 and 14 set the required contents, and vague language is a common enforcement finding.

Your notice must state:

• The identity and contact details of the controller, and of the data protection officer where one is appointed under Article 37.
• The categories of personal data processed, described specifically enough to be meaningful.
• The purpose of each processing activity and its lawful basis, including the legitimate interests you rely on where relevant.
• The recipients or categories of recipients, including processors and ad partners.
• International transfers and the safeguards applied.
• Retention periods, or the criteria used to determine them.
• The full list of data subject rights, plus the right to lodge a complaint with a supervisory authority.

Write the categories in the language your users use. "We collect device and usage information including your IP address, browser type, and the pages you view" is clearer and more defensible than "we collect technical data." A privacy policy generator that asks about your actual trackers and third-party services produces a notice matching what your site does, which is the part that matters when a regulator compares the two.

Review the notice whenever you add a tool. A new chat widget or heatmap script changes both the categories of data and the list of recipients.

Common Mistakes When Applying GDPR to PII

• Treating hashed data as anonymous. Hashing is pseudonymization. A hashed email uploaded to an ad platform for audience matching is still personal data.
• Assuming B2B data is exempt. A named contact at a company is a natural person with full GDPR rights, even at a work email address.
• Relying on consent for everything. Consent must be freely given and withdrawable. Contract or legitimate interests often fit better for core service operations, and the Article 6 basis has to be chosen honestly.
• Forgetting internal data. Employee records, CCTV footage, and recruitment applications are personal data with the same obligations.
• Ignoring processors. Article 28 requires a written data processing agreement with every vendor that processes personal data on your behalf.
• Skipping the identifiability test on analytics. "Aggregated in the dashboard" does not mean the underlying event data is aggregated.

Each of these has produced enforcement action somewhere in the EU. The Irish Data Protection Commission, the ICO in the UK, and CNIL in France all publish decision summaries worth reading for your sector.

Frequently Asked Questions

Is PII the same as personal data under GDPR?

No. PII is a US legal concept covering data that directly identifies a person, while GDPR Article 4(1) defines personal data as any information relating to an identified or identifiable natural person. GDPR's definition is broader and includes IP addresses, cookie IDs, device fingerprints, and location data that US PII frameworks often exclude.

Are IP addresses considered PII under GDPR?

Under GDPR, IP addresses are personal data. The Court of Justice of the European Union confirmed this in Breyer v Germany (C-582/14, 2016), ruling that dynamic IP addresses are personal data for a website operator who has legal means to identify the user with help from the internet service provider.

Does GDPR apply to my company if we are based outside the EU?

Yes, if you offer goods or services to people in the EU or monitor their behavior. Article 3(2) of the GDPR extends its territorial scope to organizations with no EU establishment, and Article 27 may require you to appoint an EU representative.

Is anonymized data still covered by GDPR?

Truly anonymized data falls outside GDPR entirely, per Recital 26, because the person can no longer be identified by any means reasonably likely to be used. Pseudonymized data, where you keep a separate key that can reverse the process, remains personal data and stays fully in scope.

What are the penalties for mishandling personal data under GDPR?

Article 83(5) of the GDPR allows fines up to 20 million EUR or 4 percent of global annual turnover, whichever is higher, for breaches of core principles, lawful basis rules, or data subject rights. Lower-tier violations under Article 83(4) carry fines up to 10 million EUR or 2 percent of turnover.

Do I need to list every type of personal data in my privacy policy?

Articles 13 and 14 of the GDPR require you to tell people what categories of personal data you process, why, on what lawful basis, and who receives it. You need meaningful category-level detail such as identity data, contact data, device identifiers, and usage data rather than an exhaustive field-by-field inventory.