Pure-reference catalog of personally identifiable information (PII) categories across GDPR, CCPA/CPRA, NIST SP 800-122, and HIPAA. Defines what counts as personal data under each regime, enumerates the explicit identifiers each regulator lists (GDPR Art. 4(1) and Art. 9 special categories; CPRA sensitive personal information; NIST direct-identifier vs linkable distinction; HIPAA Safe Harbor 18 identifiers), and maps overlapping fields across jurisdictions so a masking pipeline knows which regulator's rules apply. Use as the authoritative source when authoring or reviewing masking rules, classifying a dataset's risk level, or scoping which fields a PII detector must catch.
75
94%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
This skill is the canonical category catalog that downstream
masking workflows
(pii-masking-pipeline-builder)
and detectors
(presidio-pii-detection)
reference for scope. It enumerates four regimes:
This is a pure reference - no execution steps. Workflow skills consume it.
presidio-pii-detection).The full enumerations - GDPR Art. 4(1) identifiers and Art. 9 special categories with the Art. 4(5) pseudonymisation distinction, the CCPA/CPRA statutory categories and CPRA sensitive personal information, NIST SP 800-122 linked-vs-linkable and the six confidentiality-impact factors, and the HIPAA Safe Harbor 18 identifiers - are in references/regime-catalogs.md. The cross-jurisdiction map below is the fast scoping tool; consult the catalogs for the per-regime detail behind each column.
The fastest way to scope a masking pipeline is to enumerate fields present in the dataset and look up which regimes flag each:
| Field | GDPR Art. 4(1) | GDPR Art. 9 | CCPA/CPRA | CPRA SPI | NIST 800-122 | HIPAA Safe Harbor |
|---|---|---|---|---|---|---|
| Full name | ✓ | - | ✓ (A) | - | ✓ | ✓ (#1) |
| ✓ | - | ✓ (A) | - | ✓ | ✓ (#6) | |
| Phone | ✓ | - | ✓ (A) | - | ✓ | ✓ (#4) |
| SSN | ✓ | - | ✓ (A, B) | ✓ | ✓ | ✓ (#7) |
| Passport / driver's licence | ✓ | - | ✓ (A) | ✓ | ✓ | ✓ (#11) |
| IP address | ✓ (Recital 30) | - | ✓ (A) | - | linkable | ✓ (#15) |
| Cookie / device ID | ✓ | - | ✓ (A) | - | linkable | ✓ (#13) |
| Birth date | linkable | - | ✓ (A) | - | linkable | ✓ (#3 - months/days) |
| Precise geolocation | ✓ | - | ✓ (G) | ✓ | ✓ | ✓ (#2 - sub-state) |
| Race / ethnicity | ✓ | ✓ | ✓ (C) | ✓ | - | - |
| Religion | ✓ | ✓ | ✓ (C) | ✓ | - | - |
| Sexual orientation | ✓ | ✓ | ✓ (C) | ✓ | - | - |
| Health condition | ✓ | ✓ (Art. 4(15)) | ✓ (B) | ✓ | ✓ | - (covered by PHI rules) |
| Genetic data | ✓ | ✓ (Art. 4(13)) | ✓ (B) | ✓ | - | - |
| Biometric (face, fingerprint) | ✓ | ✓ (Art. 4(14)) | ✓ (E) | ✓ (if uniquely identifying) | ✓ | ✓ (#16, #17) |
| Account login + password | ✓ | - | ✓ (A) | ✓ | ✓ | ✓ (#10) |
| Credit-card / IBAN | ✓ | - | ✓ (A, D) | ✓ | ✓ | ✓ (#10) |
| Medical record number | ✓ | - (covered in B) | ✓ (B) | ✓ (health subset) | ✓ | ✓ (#8) |
| Browsing history | ✓ | - | ✓ (F) | - | ✓ | ✓ (#14) |
| Purchase records | ✓ | - | ✓ (D) | - | ✓ | - |
| Inferred profile / score | ✓ | - | ✓ (K) | - | linkable | - |
"linkable" = field alone may not identify, but combined with other fields it does (NIST §2.2).
| Confusion | Reality |
|---|---|
| "PII = SSN, name, email." | These are subsets. GDPR personal data includes online identifiers, location, biometrics, inferences. Use the full Art. 4(1) list. |
| "CCPA only covers consumers." | CCPA "consumer" includes employees and job applicants under CPRA (Cal. Civ. Code § 1798.140(i)). |
| "HIPAA only covers hospitals." | HIPAA covers covered entities (providers, plans, clearinghouses) and business associates. Business associates inherit HIPAA obligations via BAAs. |
| "IP address isn't personal data." | GDPR Recital 30 lists IP addresses as online identifiers. CJEU Breyer (C-582/14) confirmed dynamic IPs are personal data when linkable. |
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Single-list scoping | Only catches one regime's identifiers; leaks the others. | Use the cross-jurisdiction map above as the union scope. |
| Treating PHI as "just sensitive PII" | HIPAA Safe Harbor has 18 specific identifiers - birth date months, vehicle IDs, certificate numbers - that GDPR lists don't enumerate. | Apply HIPAA Safe Harbor when the dataset is PHI. |
| Mapping CCPA to GDPR Art. 9 only | CPRA SPI includes financial + government identifiers Art. 9 doesn't. | Apply CPRA SPI as a separate scope layer. |
| Stopping at "direct identifiers" | NIST §2.2 says linkable info is PII. Date-of-birth + ZIP + sex re-identifies most individuals. | Include linkable fields in scope. |
| Pseudonymisation = anonymisation | GDPR Art. 4(5) keeps pseudonymised data personal. | Document which masking outputs are pseudonymised (in scope) vs anonymised (out of scope). |
| Ignoring inferred profiles | CCPA category K covers inferences. A "risk score" derived from PII is itself PII. | Treat inferred / derived fields the same as their sources. |
presidio-pii-detection)
finds patterns that look like PII; it cannot guarantee
category-completeness. Reviewer must spot-check.synthetic-pii-generator (in the qa-test-data plugin) - generates fake PII for test fixtures (different scope; this
reference defines what to mask in existing data).pii-masking-pipeline-builder,
presidio-pii-detection.