Why do we split between PII and non-PII satellites?
Well, what is it about personally identifiable data that makes it different from non-PII data? They hardly (if ever) change!
PII content (and possible PII depending on jurisdiction):
- ID book number back in South Africa
- Combination of the above along with address, first name, last name
- Driver's Licence, or Identity number
- Telephone numbers
- Place of birth
- maybe more
And what about PHI data? And a combination of the above and other data that can be uniquely identifiable?
At least in Australia, Government issued identifiers cannot be used as identifying keys in an organization's IT systems, see: https://www.oaic.gov.au/privacy/australian-privacy-principles-guidelines/chapter-9-app-9-adoption-use-or-disclosure-of-government-related-identifiers/
- That means these keys must reside in a satellite table, a PII satellite table
- When it comes to article 17 of GDPR it makes it far easier in a split PII satellite to manage the “Right to be Forgotten” requests and still keep the non-identifying attributes available for aggregation use cases where applicable.
- This might be outright deletion, or
- and update to obscure the identifying content but keep the record for analytics, or
- a deletion of the private key to decrypt the data
- You can also "lock away" the PII satellite into a schema not accessible to the general business analytic users
- Keep in mind that additional precautions may be application, such as
- Dynamic Data Masking
- Go here for an excellent explanation of the above https://www.protegrity.com/platform
Of course check with your legal department how your data should be managed and obfuscated! This content is merely showing how much easier PII and PHI is to manage if you manage your satellite splits by identifying data attributes. Always consider legal, and the technology you're on, i.e. what is possible.