“‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person”.

Taken from https://gdpr.eu/eu-gdpr-personal-data

If I cryptographically hash (e.g. sha-512) my user's ID and give it out to a third party, do I have to delete that data when the user deletes their account? Is it considered personally identifiable data and therefore under GDPR? Or is it considered anonymized sufficiently?

There's no way for the third party to go from the hashed user ID to data on my service but knowing a user's ID I can always check if the data on the third party's platform is about them.


Somebody asked

It occurs to me that the OP is not just sending the id to the third-party; what would be the point? That other data might be able to identify the individual even without the id

In my case, the other data definitely can't identify the user it's data related to crashes on their device.


1 Answer 1


You quoted the definition of personal data from Art 4(1) GDPR. This definition of identifiability is further explained in Recital 26:

[…] To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. […]

If the user ID is unique, then the hashed user ID will be unique as well. Thus, the hashed ID will enable “singling out”, and would still count as identifying in the sense of the GDPR.

You also claim that there's no way to reverse the hash. This is not quite correct. Assuming that the hash function itself is secure, then the only way to crack the hash is to brute-force the input. The difficulty of brute-forcing depends only on the entropy of the input data, not on the size of the output hash. It is thus comparatively easy to crack hashes of short low-entropy strings like sequential integer user IDs, IPv4 addresses, or weak passwords. In contrast, it would be difficult to crack long random user IDs, such as UUID version 4 identifiers created from a cryptographically secure RNG (CSPRNG).

Even if the hashes can't be cracked, they are not anonymous – you can link them to the original user ID, after all. The GDPR only considers data anonymized if there are no “reasonably likely” means to re-identify the data subject. If this de-identification is reversible, it's called pseudonymization instead.

If storage allows, a better technique to generate pseudonymous IDs is to create a table that maps the true ID to a CSPRNG-random ID. Unlike a hash, the random ID cannot leak extra information about the original ID. This pseudonymization technique could perhaps also be turned into irreversible anonymization by deleting the ID mapping, assuming that no “singling out” can happen.

Pseudonymization is a very good security measure. It is explicitly mandated whenever appropriate in Art 32 GDPR. So you should probably use it. It's just that GDPR continues to fully apply to processing of the pseudonymized data.

Since the pseudonymized data is the data subject's personal data, you may be required to delete it when receiving an Art 17 request for erasure. You may also be required to forward the request to others with whom you shared the data. However, the right to erasure has many conditions and exceptions. If you actually need to keep the data for a particular purpose, chances are good that you can keep it.

  • 2
    It occurs to me that the OP is not just sending the id to the third-party; what would be the point? That other data might be able to identify the individual even without the id.
    – Dale M
    Nov 23, 2022 at 21:50
  • @DaleM the point is that you're only allowed to process data necessary for the purpose it was collected. If the user id isn't necessary (even if the identity can be determined from other data, which isn't always the case) you can't process the user id. E.g. I could have a need to process medical data to create a map of diabetes incidence based on postal codes. I need the postal code (an identifiable data point) and medical data related to diabetes (medication prescriptions, maybe), but I shouldn't get the names of the actual patients.
    – jwenting
    Nov 24, 2022 at 7:32
  • @amon if the user ID is an auto-incrementing relational database identifier, wouldn't this itself be considered to be a pseudoanonymous identifier? There is no risk to reidentification if it is given to third parties, unless it is provided with other elements of the underlying data set that would allow singling out. Jan 31, 2023 at 21:10
  • @AllylIsocyanate Yes, such surrogate keys are an example of a pseudonym. But pseudonymous data is still surrogate data. And such IDs inherently link the records of one person together, allowing that person to be singled out in a dataset – no additional information needed. While pseudonymization reduces some risks, it doesn't give license to ignore the GDPR when processing pseudonymized data. Only with true anonymization would identification become effectively impossible, and that is really difficult (though some techniques like Differential Privacy can help).
    – amon
    Feb 1, 2023 at 21:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .