A piece of data that cannot be used to identify a natural person, and is not linked to a specific natural person is not PI under the GDPR or most other data protection laws (such as the CCPA). Therefore, such a datum does not need a lawful basis for processing, need not be included in notices of data collection provided to the user, is not subject to erasure requests, and generally is not subject to the protections that PI must get.

However, if the otherwise non-identifiable information is linked to a user's name or other PII, such as by being stored in the same DB record or a linked record, then it becomes PI. In short if there is a reasonable way to go from ma datum to PII, it is PI.

By the way one does not "use the user password to hash a salt". One normally appends (or otherwise combines) a salt to a password, and hashs the combined string, producing a hash value. Also, it is not really good security practice to use the hash oif a salted PW for anything but login or related security verification. If it i used to identify the user in other contexts, it increases the possibility of a security hole somewhere. The GDPR requires "appropriate" security measures be taken with PI, and introducing a hole by poor practice could violate that requirement.

A piece of data that cannot be used to identify a natural person, and is not linked to a specific natural person is not PI under the GDPR or most other data protection laws (such as the CCPA). Therefore, such a datum does not need a lawful basis for processing, need not be included in notices of data collection provided to the user, is not subject to erasure requests, and generally is not subject to the protections that PI must get.

However, if the otherwise non-identifiable information is linked to a user's name or other PII, such as by being stored in the same DB record or a linked record, then it becomes PI. In short if there is a reasonable way to go from ma datum to PII, it is PI.

By the way one does not "use the user password to hash a salt". One normally appends (or otherwise combines) a salt to a password, and hashs the combined string, producing a hash value. Also, it is not really good security practice to use the hash oif a salted PW for anything but login or related security verification. If it i used to identify the user in other contexts, it increases the possibility of a security hole somewhere. The GDPR requires "appropriate" security measures be taken with PI, and introducing a hole by poor practice could violate that requirement.

Response to Comment
In response to a comment by user lam3:

The GDPR, and the Data Protection authorities set up to enforce it, distinguish between pseudonymous and anonymous . If data can be used to single out a particular individual, even if it cannot be used too link to that person's real name or other identity, it is only pseudonymous and is still PI, even if not PII, and so is still protected by the GDPR.

If a piece of data, even a random number, is used to link other data about a person, it may well thereby become an identifier and thus PI. If it is reasonably possible to follow links from a piece of data to a record o0f information about a specific person, tht data is PI, and possibly PII. If re-identification can be done indirectly, through links or other information that might be available to the Data Controller or to others, then the datws remains PI and thus protected.

Also, please read the answer by Amon, particularly the concerns about using a password in the way the question and comment seem to suggest.