Notifications
Clear all

Why do we split between PII and non-PII satellites?


Posts: 743
Topic starter
(@patrick-cuba)
Honorable Member
Joined: 2 years ago

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):

  • birthdate
  • SSN
  • ID book number back in South Africa
  • Combination of the above along with address, first name, last name
  • Passport
  • 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

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.

Reply
Topic Tags