PII in IAM: governing what identifies your users
Personally Identifiable Information lives inside every system your IAM stack touches. Here’s how to classify it, protect it, and govern access to it before a regulator asks you to.
What counts as PII?
PII is any data point or combination of data points that can identify a specific individual, either directly or when linked with other information. The IAM-relevant definition matters: your identity store is a PII database by definition.
| PII Category | Risk Level | Examples |
|---|---|---|
| Direct Identifiers | Uniquely identifies a person | Full name, SSN, passport number, email, biometric data |
| Indirect / Quasi Identifiers | Can re-identify when combined | Date of birth, ZIP code, IP address, device fingerprint, job title |
| Online Identifiers | Digital footprint data | Username, cookie IDs, OAuth/OIDC subject claim, session tokens |
| Special Category PII | Highest protection required | Ethnic origin, political opinions, religious beliefs, genetic data |
Five IAM rules for PII
- Least privilege by default. No user should have broader access to PII than their role requires. Start with no access and grant up; never grant down.
- De-provision on event, not schedule. When an employee changes role or leaves, PII access must be revoked immediately — not at the next certification cycle.
- MFA on every PII-scoped system. Password-only access to systems holding personal data is unacceptable. Enforce phishing-resistant MFA for anything Tier 2 and above.
- Certify access regularly. Run access certification campaigns against PII-tagged entitlements. If a reviewer misses the window — auto-revoke, don’t extend.
- Log everything. Every read, write, and export on PII-holding systems needs an audit trail. Regulators don’t just ask what happened — they ask who had access and when.
PII governance isn’t a compliance project with a finish line — it’s a continuous operational discipline. Every new app onboarded, every role change processed, every service account provisioned is an opportunity to get it right or leave a gap.
The good news: the IAM stack you already have — your IGA platform, your PAM tool, your identity provider — contains the controls you need. The work is connecting those controls to your data classification model and making enforcement automatic, not manual.
Start with your identity store. Classify what you hold, tighten who can access it, and make sure de-provisioning happens the moment a role changes. Everything else builds from there.
Gabriel Magarino
Gabriel Magarino – Senior Security Manager | IAM Evangelist - Experienced leader with over 20 years in the IT and cybersecurity industry, specializing in Identity & Access Management. Expert in Okta, One Identity, SailPoint (IdentityIQ & IdentityNow), OneLogin, Delinea, and CyberArk. Passionate about exploring IAM and emerging technologies, coaching, and training IAM teams. Holds a Master’s in Computer Science and multiple certifications, including Okta Professional & Administration, One Identity Architect & Instructor, SailPoint Identity Now, ITIL, Scrum Master, among others. Currently pursuing a PhD with a focus on Computer Science and Artificial Intelligence.