In GDPR terms is the hash of a user ID considered personal data? “‘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. Edit 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.
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.
I believe in this case, your company (OrgX) is a data processor and your customer's organization (OrgY) is the data controller. OrgY is responsible for establishing a lawful basis for sending you (OrgX) the personal data for their employees. Note that consent is just one of six lawful bases outlined in article 6(1). I'm no expert, but I believe OrgY's admin can claim they have a legitimate interest in sending their employee's personal data for training sake. In either case, the data processor is not responsible for establishing the lawful basis for processing. Of course, data processors aren't completely off the hook. GDPR outlines specific requirements for data processors (see chapter 4, particularly article 28).
From ACRO's Subject access - further guidance web page: Why do I need to supply proof of ID? We need to be confident that we provide your personal data to the correct person, which is why we ensure we have sufficient proof of identity before we disclose any information. It also helps us to ensure we make a correct match on the PNC. As for this proof of ID (personal data) provided when submitting a Subject Access Request, ACRO's Privacy policy states: We gather information about site usage to help the development and improvement of services to the public, and to protect the integrity of our systems from malicious users. At the moment this information consists of: Statistical information obtained using Google Analytics. No information collected can be used to identify individual users. For more details about how this affects your privacy please visit the Google Analytics Privacy Centre. If you don’t want to send information to Google Analytics, an Opt-out Browser Add-on is also available or you can configure your browser to let you to choose which, if any, cookies are allowed to be created. Information obtained by our content management system to examine what people are searching for, what they find and occasions where no results are returned. Information collected can’t be used to identify individual users. Information provided by users through online forms; it's held in our UK-based secure data centres and is retained in line with the Data Protection Act 2018, the General Data Protection Regulation (EU) 2016/679, and our retention policies. However, I have not been able to locate publicly available copies of the retention policies referred to in the emboldened text.
It depends. Can the data controller or another person, with &quot;means reasonably likely to be used,&quot; (see clause 26 of the preamble of the GDPR) use that data alone or in combination with other data to identify a natural person? If yes, it is personal data within the meaning of the GDPR. If no, it is not personal data within the meaning of the GDPR. Anonymous data is not subject to the GDPR. &quot;The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. This Regulation does not therefore concern the processing of such anonymous information, including for statistical or research purposes.&quot; Assigning an unique alphanumeric code to a thing does not necessarily make the code and/or the thing &quot;personal data&quot;. But if you have a set of data that is or can be linked by the unique alphanumeric code (e.g. as a primary key in a set of tables) and you can use it to identify a person, then it is personal data. Either way, to be GDPR-compliant / to mitigate risk you should make some kind of record to reflect that process of thinking and what you decided. And if the answer is Yes, it is personal data, then you should record your &quot;lawful basis&quot; for processing the data and how you decided that.
Yes, this violates the GDPR if the user is in Europe. Data which is tied to a personal device can be tied to the person who owns it. From "What Is Personal Data" by the UK Information Commissioner's Office (ICO) (emphasis added): Personal data is information that relates to an identified or identifiable individual. What identifies an individual could be as simple as a name or a number or could include other identifiers such as an IP address or a cookie identifier, or other factors. If it is possible to identify an individual directly from the information you are processing, then that information may be personal data. If you cannot directly identify an individual from that information, then you need to consider whether the individual is still identifiable. You should take into account the information you are processing together with all the means reasonably likely to be used by either you or any other person to identify that individual. The bit about "all means reasonably likely" in the last bullet includes the kind of de-anonymisation tactics described in the NYT article. There are 6 lawful bases for data processing in the GDPR, and all processing must fall under at least one of them. (a) Consent: the individual has given clear consent for you to process their personal data for a specific purpose. (b) Contract: the processing is necessary for a contract you have with the individual, or because they have asked you to take specific steps before entering into a contract. (c) Legal obligation: the processing is necessary for you to comply with the law (not including contractual obligations). (d) Vital interests: the processing is necessary to protect someone’s life. (e) Public task: the processing is necessary for you to perform a task in the public interest or for your official functions, and the task or function has a clear basis in law. (f) Legitimate interests: the processing is necessary for your legitimate interests or the legitimate interests of a third party, unless there is a good reason to protect the individual’s personal data which overrides those legitimate interests. (This cannot apply if you are a public authority processing data to perform your official tasks.) Selling data isn't covered by any of the others, so consent must be obtained. Permission must be clear and positive, and you cannot predicate delivery of a service on the processing of data that isn't necessary for that service. So for instance you cannot say "You can use this service as long as we are allowed to collect and sell your data" because selling the data isn't necessary to the provision of the service. From "Consent" by the ICO: Consent requires a positive opt-in. Don’t use pre-ticked boxes or any other method of default consent. Explicit consent requires a very clear and specific statement of consent. Keep your consent requests separate from other terms and conditions. Be specific and ‘granular’ so that you get separate consent for separate things. Vague or blanket consent is not enough. [...] Avoid making consent to processing a precondition of a service. This applies to any processing of data about individuals within the EU, so just being an American company doesn't get you a free pass to ignore the GDPR if your app gets used by Europeans. The "Legitimate interests" basis is more problematic, in that the company collecting the data has to conduct a vague "balancing test" to determine if this basis applies. For direct marketing the ICO has written this, which says that direct marketing may be a legitimate interest, especially if you can show that the user has expressed interest in such adverts. For instance a location service which promises to tell you about nearby special offers would fall into this category. Against this, the impact on the user's privacy has to be considered, and location data is "special category data" because it can reveal medical information (e.g. hospital attendance) or religious affiliation (e.g. which church you go to). So unless the relationship between the recorded location data and the service is very direct its not going to pass the balancing test. The company would also need to distinguish between knowing the current location and keeping a record of historical locations; the two need separate justification. And of course nothing about this covers the sale of the data; this is considering a company which sells advertising space in it's app, not one that sells the data itself.
GDPR compliance is a matter between every customer and the business, not between different customers. How did you get the other customer's contact details? If they were provided or leaked by the business, that might be a failure of the business's obligation as a data controller to protect the personal data they are processing, possibly even a data breach in the sense of the GDPR. When you contacted the other person this was presumably a purely private or household activity, just like contacting any other personal acquaintance. In that case, the GDPR simply does not apply to any “processing” you may have done (compare Art 2(2)(c)). Things would be very different if you were promoting your own business, but that doesn't seem to have been the case. If the matter really is as plain as you described, then you can effectively ignore their references to the GDPR until you are contacted by your data protection authority, by their lawyer, or are served with court papers. None of these should happen: even if you were a “data controller” and your processing were subject to the GDPR – only the other customer and not the business would be the data subject, and only a data subject has a right for remedies like making complaints to the data protection agency and only the data subject would have standing to sue you in court for GDPR violations.
Your analysis so far seems correct. You must comply with all applicable laws. The GDPR's Art 6(1)(c) legal basis clarifies that having to provide personal data is no excuse: that legal obligation is all the legal basis you need for sharing the personal data in accordance with your obligations. However, that legal basis doesn't generally excuse you from your other data controller obligations. For example, you should still inform the data subjects about the processing as per Art 13(3).
Great question - I work for a London based company who use a large amount of location data. The process for deletion of data is not as simple as it first sounds. We recently had a deep dive with our legal team and as a result actually created a product to process deletions. Personal data from users/customer is carried for lots of reasons, not just marketing. What if you're asked to delete data that is needed to bill customers, information that may be relevant to a legal case or information that needs by law to be retained for the purposes of audit? GDPR does not make it illegal to carry personal information, it simply needs you to justify why you are keeping the information - inform the named person about this and provide them with a timescale for deletion. For example if you are required by law to store a record of emails to document the work done, but the user asks you to delete that information. You would be entitled to keep that information but only for the purposes of maintaining that audit trail. You would delete all associated customer data that was unnecessary such as CRM info, payment details etc.. but could keep the audit trail. The proper way to respond to the user's deletion request would be "your data will be kept in a secure server for the purposes of maintaining an audit trail for x amount of time. Once this time has elapsed it will be deleted. If you are unhappy with our use of this data please contact our data officer". GDPR isn't designed to catch you out - if you have a legitimate reason to keep that information then you are entitled to. The law was designed to stop marketers and advertisers hoarding huge amounts of information, as well as undermine Google/Facebook's duopoly on our personal information.