PII (Personally Identifiable Information)

What is PII?

PII, short for personally identifiable information, is any data that can single out a specific person, on its own or combined with other data you hold. A name, a national registry number or a work email address points straight at someone. A customer number, an IP address, or a mix of postcode, age and job title gets you there indirectly.

The term comes from United States practice, where NIST and federal agencies use it to decide which records need extra protection. European teams say PII constantly, but the term with legal weight here is 'personal data', defined more broadly. What matters is rarely the label: it is whether a real person can be recognised from what you hold.

PII versus personal data under GDPR

The United States has no single federal privacy law, so PII is defined per rule and agency. The most cited reference, NIST Special Publication 800-122, describes PII as any information that can distinguish or trace someone's identity, plus any information linked or linkable to that person, such as medical, financial or employment data.

Under GDPR the matching concept is personal data. Article 4(1) defines it as any information relating to an identified or identifiable natural person, where an identifiable person is one who can be identified, in the Regulation's words, 'directly or indirectly', in particular by reference to identifiers such as a name, an identification number, location data or an online identifier.

The GDPR definition is deliberately wider. Recital 30 names online identifiers, including IP addresses and cookie identifiers, as data that can identify people when combined with other information. So an IP address in a web server log, which a narrow reading of US PII might wave through, is in many cases personal data in Europe. In the EU, personal data is the operative term and PII is informal shorthand for the same ground.

What counts as PII, and what does not

Whether something is personal data is a matter of context, not of the column name. Recital 26 sets the test: a person counts as identifiable when someone could identify them by 'means reasonably likely to be used', taking account of objective factors such as the cost and time it would take and the technology available.

Data that usually counts:

• Direct identifiers
  Name, email address, national registry number, staff or customer number, passport number.

• Indirect identifiers
  IP address, device ID, licence plate, a precise location trail, date of birth.

• Combinations
  An age band alone rarely identifies anyone. Add postcode, employer and job title and it often does, which is why removing the names does not make the data anonymous.

• Free text
  Support tickets, case notes and email bodies routinely hold names, addresses or health details that nobody modelled as a structured field.

Genuinely aggregated figures usually fall outside. Revenue per region across thousands of customers is normally not personal data, as long as no individual can be read back out of the totals. That changes the moment a filter drills down to one household or a single rare record.

Special category data

Not all personal data carries the same weight. GDPR marks out a smaller set as special category data under Article 9, and processing it is prohibited unless a specific exception applies. Article 9(1) covers data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, together with genetic data, biometric data used to uniquely identify someone, data concerning health, and data concerning a person's sex life or sexual orientation.

For a data team this changes the handling, not only the label. Special category fields warrant stricter classification, tighter access, fuller logging and shorter retention than an ordinary business contact.

Pseudonymised, anonymous, and why anonymisation is hard

Pseudonymisation replaces direct identifiers with codes while keeping a route back through separately held information. Anonymisation changes the data so thoroughly that no one can realistically be singled out again. The legal consequence is sharp: pseudonymised data is still personal data, because the extra information can restore the link, so GDPR keeps applying. Genuinely anonymous data falls outside GDPR altogether, and that gap is exactly why anonymisation is hard. Recital 26's 'reasonably likely' test means you must defend the claim against outside datasets and future technology, not only against the columns you dropped, which is why approaches such as differential privacy exist. The mechanics of both sit in the anonymisation and pseudonymisation entry.

Where PII shows up in data and AI work

PII rarely arrives labelled. It hides in a drill-through that exposes customer names under clean aggregates, in a log line that records an email or IP address for debugging, in an AI prompt that forwards a whole email thread to a third-party model, and in a test database seeded with real production records.

So serious projects start with classification: which columns hold personal data, which free-text fields might hide it, and who actually needs the detail. Most analysis does not need it. From there the usual controls apply: data masking, data minimisation, a clear data retention policy, and, for higher-risk processing, a data protection impact assessment (DPIA). All of this sits inside your wider data governance, so an erasure request can actually be followed through.

None of this is legal advice: whether a given field is personal data, and what you may do with it, depends on context. High-risk or novel processing is worth reviewing with privacy and security specialists early.