PII

PII is a market term, common because so much tooling and documentation originates in the United States, and it works well enough as shorthand for data that identifies an individual: name, national identifier, contact details, and so on. It is useful for describing the category of information a control protects. But it is not the legal concept that governs processing in the EU. The GDPR speaks of personal data, defined in article 4, and that definition is deliberately wide: it includes any information relating to an identified or identifiable person, which extends to online identifiers, IP addresses, cookie identifiers and data that has been pseudonymised but can still be linked back.

Using PII as the scope in a European context quietly narrows it, and that narrowing has consequences. A team designs controls around “PII” understood as the obvious fields and leaves out the online identifiers, device data and pseudonymised records that are still personal data under the regulation, so the processing that carries obligations is not covered. A data protection officer catches this on first reading. The other omission is the special categories in article 9 (health, biometric, political and similar data), which carry stricter obligations and are easy to miss if the scope was set by the narrower term. The label chosen at the start decides what the assessment protects.

We scope data-protection work against the regulation’s definition, not the market shorthand: what personal data the organisation processes, including online identifiers and pseudonymised records, and whether any of it falls into the special categories. Data classification is the practical starting point, and where reducing exposure is possible we point at tokenisation. Findings tie back to the correct legal concept and to the canonical entry, so the scope reflects what actually carries obligations. This is part of how we scope a data-protection assessment.