# PII and data classification Identifying which data relates to people or is otherwise sensitive, labelling it with a classification level, and handling it according to that level, including pseudonymising or anonymising it where possible. > [!NOTE] > > **Before reading** > > [Governance roles]() · [Data contracts]() ## Why it matters Privacy laws, such as the EU's GDPR, attach obligations to personal data: a lawful purpose, limited access, security, retention limits and the right of people to see and erase their data. None of these can be met for data the platform has not identified. Classification is the step that makes every other privacy and security control possible. ## How it works Personal data, often called PII (personally identifiable information), is any information relating to an identified or identifiable person. Direct identifiers, such as name, email, phone number or customer number, identify someone on their own. Indirect identifiers, such as postcode, date of birth and gender, can identify someone in combination. Some categories, such as health data, are especially sensitive and carry stricter rules. Personal data is not only in obvious columns: free-text fields, JSON payloads, log lines and file names often contain it. Classification assigns each dataset and column a level that decides how it is handled. A common scheme has four levels: public, internal, confidential and restricted. Personal data is usually confidential or higher; payment card data and sensitive categories are restricted. Each level maps to rules: who may access it, whether it is masked, where it may be stored, how long it is kept, whether it may leave the platform. Masking, showing a reduced form of a value depending on who asks, is covered in [Row-level security and masking](). Classification is done at the source of each dataset and inherited downstream. Raw and clean tables are classified when they are onboarded, by the steward with help from automated scanning, which flags columns whose names or values look like emails, phone numbers or card numbers. Lineage then carries tags to derived columns: if fct\_customer\_orders includes email, it inherits the tag. Scanning helps but misses context, so a person confirms. ``` flowchart LR ON[New dataset
onboarded] --> SC[Automated scan:
names and value patterns] SC --> ST[Steward confirms
classification per column] ST --> TAG[Tags in catalog
and contract] TAG --> POL[Policies: masking,
access, retention, residency] TAG -->|lineage| DS[Derived tables
inherit tags] ``` Reducing identifiability is the next step. Pseudonymisation replaces identifiers with pseudonyms, such as a keyed hash or a random token, while the means to reverse it, the key or mapping table, is kept separately and protected. Analysts can still count and join by customer without seeing who the customer is. In EDPS v SRB (C-413/23 P, 4 September 2025) the EU Court of Justice held that pseudonymised data may not be personal data for a recipient who, because of the measures in place, cannot re-identify people by means reasonably likely to be used. For the organisation that holds the key it remains personal data, and its obligations, including telling people who receives their data, are unchanged. Anonymisation removes the possibility of identification altogether, by aggregating, generalising or adding noise; truly anonymous data is outside the GDPR. True anonymisation is hard: rare combinations of attributes, such as a postcode with a birth date, can re-identify people in apparently anonymous data. Minimisation comes before both: data that is not needed should not be collected or copied. A column dropped at ingestion needs no classification, masking or erasure. ## Key terms - Personal data (PII): information relating to an identified or identifiable person. - Direct identifier: a value that identifies a person on its own. - Indirect identifier: a value that can identify a person in combination with others. - Classification level: a label, such as confidential, that decides handling rules. - Pseudonymisation: replacing identifiers with pseudonyms while the re-identification key is kept apart. - Anonymisation: making identification no longer possible. - Data minimisation: collecting and keeping only what is needed. ## Example The shop's clean\_customers, classified: | Column | Kind | Level | Handling | | --- | --- | --- | --- | | customer\_id | Direct identifier (internal) | Confidential | Replaced by customer\_pseudo\_id in tables for broad analysis | | name, email, phone | Direct identifiers | Confidential | Masked except for support, privacy and the CRM sync service | | street, postcode | Indirect identifiers | Confidential | Masked; region derived for analysis | | birth\_date | Indirect identifier | Confidential | Shown as year only | | card\_token | Payment provider token, copied from payments | Restricted | Shown as last four digits except to the payments team; full card number never ingested | | segment, region | Not personal on their own | Internal | No masking | For analysis, gold tables replace customer\_id with customer\_pseudo\_id, a keyed hash of customer\_id (not the dimension's surrogate customer\_key). Analysts can count repeat customers by region without access to who they are; the key is held by the privacy team. ## Pitfalls - Looking only at column names. Personal data hides in notes, payloads and logs. - Treating hashed emails as anonymous. Without a secret key, likely values can be hashed and matched. - Classifying gold tables but not raw. The raw layer usually holds the most personal data. - Tags that do not drive policies. A label with no masking, access or retention rule attached changes nothing. - Keeping data because it might be useful. Every extra copy of personal data is a liability. ## Learn more - GDPR, Article 4 (definitions) and Recital 26: https://eur-lex.europa.eu/eli/reg/2016/679/oj - EDPB, Guidelines 01/2025 on pseudonymisation (version for public consultation): https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2025/guidelines-012025-pseudonymisation\_en ## Related [Privacy lifecycle]() · [Residency and regions]() · [Governance as code]() · [Catalog and lineage]()