PII Classification and Sensitivity

Access Control Models covered mechanisms for restricting access — scoped to something. This article covers the step that has to happen first: identifying which data is actually sensitive, so those mechanisms have something concrete to scope around.

Personal data is broader than the obvious identifiers#

Personal data includes the directly identifying fields most people think of first — name, email, national ID number — and a second, easier-to-miss category: quasi-identifiers, fields that are not identifying alone but become identifying in combination. Latanya Sweeney's well-known finding demonstrated that gender, birth date, and postal code together uniquely identify roughly 87% of the U.S. population — none of those three fields looks sensitive individually, and the combination re-identifies almost everyone.

A tiered classification scheme#

Most governance programs sort data into a small number of sensitivity tiers, each implying a different set of controls:

Public        no restriction — safe to share externallyInternal      employees only, no external accessConfidential  restricted to specific roles (e.g. PII, contracts)Restricted    highest sensitivity — regulated data, strict audit trail

The exact tier names vary between organizations; the structure — increasing sensitivity mapped to increasing control — is close to universal. A column's tier is what Access Control Models' roles and attribute rules actually reference when deciding what a given role can see.

Classification belongs in the contract#

Data Contracts covers schema, semantics, and guarantees as the contents of a contract. Sensitivity classification is a natural fourth: tagging email as confidential and signup_date as internal directly in the same artifact that already declares each field's type and meaning, rather than tracked separately somewhere it can silently fall out of sync with the schema it describes.

Automated scanning has real limits#

Pattern-based scanners — regular expressions for email addresses, national ID formats, credit card numbers — can classify a large schema quickly and catch what a manual review might miss from sheer volume. They also reliably miss what a pattern cannot express: a free-text notes or support_ticket_body field can contain a customer's address or phone number typed in prose, invisible to any column-level pattern match. Automated scanning is a useful first pass, not a substitute for reviewing free-text and loosely structured fields by hand.

Common mistakes#

Classifying only the obviously-sensitive columns#

Missing quasi-identifiers that combine to re-identify someone is the most common classification gap — no single flagged column, and therefore no control applied, even though the combination is genuinely sensitive.

Treating classification as a one-time pass#

A schema that gains new columns after the initial classification effort accumulates unclassified fields by default — classification needs to be part of the ongoing schema change process, the same way Data Contracts needs an owner who updates it deliberately rather than lets it go stale.

Trusting automated scanning for free-text fields#

A regex-based scanner cannot read prose. Any field capable of holding unstructured human-entered text needs a different classification approach — sampling and manual review, at minimum — rather than the same pattern-matching applied to structured columns.

Further reading#

• Personal data — the general category this article's classification scheme organizes.
• Quasi-identifier and k-anonymity — the formal treatment of how combined fields re-identify individuals.
• Data classification (data management) — the general practice this article's tiered scheme is one instance of.
• Information security — the broader field this article's classification work serves.
• Data Contracts — where a classification tag belongs, alongside a field's type and meaning.

See also#