Notifications
Clear all
Topic starter
24/06/2026 9:16 pm
TL;DR: PII now includes not only names and government IDs but also device identifiers, geolocation, and behavioural data, with the article tracing how privacy law and risk thinking expanded from the 1970s to GDPR and CCPA. The practical lesson is that identity, access, retention, and masking decisions must track re-identification risk, not just obvious fields.
NHIMG editorial — based on content published by Netwrix: An All-in-One Guide to Personally Identifiable Information (PII)
By the numbers:
- According to the IBM Cost of a Data Breach Report 2024, the average cost of a breach is $4.45 million.
Questions worth separating out
Q: How should organisations classify data that may become PII when combined with other records?
A: They should classify it by re-identification potential, not by the label on the source field.
Q: Why do SaaS and cloud environments make PII harder to govern?
A: Because personal data is often copied, joined, and reused across tools that were not designed as one privacy boundary.
Q: What do security teams get wrong about non-sensitive PII?
A: They often assume it is harmless because it is not obviously confidential.
Practitioner guidance
- Classify by linkage potential, not just by field name Review datasets for combinations that can identify a person when joined with other records, including device IDs, location trails, and behavioural logs.
- Separate sensitive PII from general business data paths Put stricter access logging, encryption, and approval steps around sensitive PII workflows than around low-risk contact data.
- Apply retention limits to re-identifiable datasets Delete or archive data that no longer needs to exist, especially exports, backups, and analytics copies that can be matched back to people.
What's in the full article
Netwrix's full blog covers the operational detail this post intentionally leaves for the source:
- The article’s field-by-field examples of direct and indirect PII for compliance mapping and data cataloguing.
- The privacy-law context around GDPR, CCPA, HIPAA, and how these definitions differ by jurisdiction.
- The handling distinctions between sensitive and non-sensitive PII for access control, logging, and retention design.
- The article’s practical examples of how non-PII can become PII once datasets are combined.
👉 Read Netwrix's guide to personally identifiable information and PII handling →
PII governance and the identity gap teams are missing?
Explore further
25/06/2026 6:23 am
PII governance fails when organisations treat identifiable data as a field-level problem instead of a linkage problem. The article shows that context determines whether data is identifiable, because combinations like postcode, date of birth, and gender can reveal a person. That framing matters for identity programmes because access decisions often cover datasets, not just individual attributes. The implication is that governance must track data combinations and downstream reuse, not only data labels.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how weak identity inventory remains in practice.
A question worth separating out:
Q: Who is accountable for protecting PII across privacy and identity programmes?
A: Accountability should sit with the data owner, but enforcement depends on IAM, security, privacy, and governance teams working from the same classification rules. If the organisation cannot agree on what counts as identifiable, access decisions will be inconsistent and breach response will be slower and less precise.
👉 Read our full editorial: PII governance is expanding beyond static identifiers and records
