0

In our web application, we have the requirement to log users' activities. The user's information can be extracted from jwt token. And due to privacy reasons, the user's employee id or email are not allowed to be used as identifiers in the log.

One of the options I am thinking about is to create a user table in the persistent layer, and store the uuid identifiers there. But due to some reasons, I don't want to go down this route because the process is very complicated.

Another option I have is to encrypt the user's email and use the hex ciphertext as the identifier. That way I don't need to keep the user -> identifier mapping in the persistent layer.

What do you guys think?

user1285245
  • 423
  • 3
  • 9

1 Answers1

0

Data that is itself unintelligible (e.g. a hash of an email address) but still serves as an identifier of a real person is pseudonymous data (as defined in GDPR).

How you handle this is heavily dependent on your precise situation. If identifiers are logged (pseudonymous or not), this only represents an exposure if the logs are made available to someone other than the data controller (e.g. Google if you're using Google Analytics). So you could approach this by limiting who gets to see the logs rather than what you put in the logs.

The two approaches you describe don't appear to be significantly different in outcome; either way you store data that can be linked to an individual via other data that you hold. Whether you store hashes/UUIDs or generate them dynamically makes little difference.

Synchro
  • 35,538
  • 15
  • 81
  • 104