What is the lawful basis for running Know Your Customer (KYC) checks on startup investors? Suppose you have a startup that raises money from a number of angel investors, many of whom are investing as natural persons. What is the lawful GDPR basis for processing the investors' personal data, including their name, address, and photo IDs? My guess would be either Contract or Legal Obligation (to comply with AML regulations). A subscription agreement cannot be drafted without the investor's personal details. However, it can be drafted without a photo ID, but the photo ID is necessary to check the identity of the investor against an AML database. Note: this question is about a UK company and so about the UK Data Protection Act, but since that is basically a copy-and-paste of GDPR, this question applies to EU companies as well.
england-and-wales 'Know Your Customer' (KYC) is a synonym for 'customer due diligence' checks. The Money Laundering Regulations refer to 'customer due diligence' and not to KYC, so searching the regs for Know Your Customer or KYC will have no results. But you can search the Financial Conduct Authority's handbook for &quot;Know Your Customer&quot; or &quot;KYC&quot; and eventually arrive at useful information. The Regulations create legal obligations to apply 'customer due diligence measures' that necessarily involve the processing of some personal data. As Dale M said, one of the six lawful bases for processing personal data is 'legal obligation' (Article 6(c) GDPR): &quot;processing is necessary for compliance with a legal obligation to which the controller is subject&quot;.
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.
Among other things, GDPR regulates what you may do with the data within your systems. You can use it for the contracted purpose, or in accordance to law, or with informed and revokable consent, or for some other enumerated purposes. Even with consent, you have to take security measures to avoid the misuse of the data. Remember the software shrink-wrap licenses? &quot;By opening the package, you agree to the terms inside.&quot; GDPR makes the equivalent in the cloud world impossible. You have to document exactly what you do with the data, and for any use that is not necessary to perform the service the customer can opt out. In the scenario you describe, it is possible that you are not the data controller under GDPR but the data processor, and that you have a duty to keep the data from separate controllers apart. And delete any batch at the end of contract. If you want to do this professionally, you need to consult a lawyer for your specific plans.
I think this shows a misunderstanding of the meaning of the GDPR. A data subject has the right to demand information, correction, deletion etc. about some of their data held by some institutions, depending on the legal basis for the data processing. One John Smith does not have the right to see the data of any other data subject named John Smith, and he cannot even demand to know if there are other John Smiths in the database. The data controller has to make reasonable steps to ensure that an individual who seeks account information is in fact the individual who is the data subject. In the case of an email, that's usually easy -- if John Smith can access the mail account jsmith@sample.org, one can assume that he is the John Smith who opened the account. If not, then not. If the data controller has the birthplace and birthdate in their records, they can possibly match that against some government-issue identity document, too, but why would they have that data?
Think of a website that has gives no option for the users to delete what they have posted -but still the users can delete their account completely. That's easy - this is exactly how all StackExchange sites (including this one) work :-). See for example: How does deleting work? on meta.SE. Is it against the right to erasure mentioned here as a part of GDPR? No, it is not (otherwise StackExchange would be in rather big trouble). The "right to be forgotten" is subject to limitations. Most importantly, it only applies to personal data. Personal data is defined as (GDPR, art.4): any information relating to an identified or identifiable natural person (‘data subject’) If what you posted contains no personal information about you, it is not "relating to" you. The details are complicated (as usual, see e.g. The GDPR: What exactly is personal data?), but "personal data" is things about you (your name, your address, your sexual history, maybe even your IP address). On the other hand, if someone asks how to solve a programming problem, and you write an answer explaining what API to call, that answer is not personal data. In addition to that, even personal data may be retained if the data controller has a need to retain that information. This is also covered in article 4. For example, the controller may retain information "for the establishment, exercise or defence of legal claims" - otherwise you could buy something online without paying, and then ask the seller to forget about your purchases so they cannot collect the outstanding payment. So, in summary: A website will need to allow users to delete or hide personal data that they posted - such as their user profile information, or personal information in their posts. That does not mean they are allowed to delete entire posts - it is enough if personal information is redacted or anonymized. The website may be allowed to retain that information (hidden) if they can show legitimate interest - for example billing information, or posts that are the subject of a lawsuit. The StackExchange network, for example, covers this by allowing users to: disassociate posts from their account delete their account entirely (thus effectively disassociating all posts from personal information) asking a moderator for redaction of personal data
This depends on the context – GDPR rarely restricts the use of specific kinds of data (see Art 9) but instead regulates the processing of this data, and the purposes for which it is processed. Personal data is any information relating to an identifiable person (Art 4(1)). So to show that some information is not personal data, you must show either that it doesn't relate to the identifiable person, or that it's not possible to identify the person. Whether a person is identifiable depends on the means of identification that are reasonably likely to be used, taking into account the cost and effort of these means (Recital 26). This recital also mentions that singling out a person is a kind of identification. If you have lots of birthdays so that there are no unique birthdays, or if the birthdays are stored without contextual information that would allow identification, this can indicate that it's not personal data. Some examples to illustrate my views: Scenario 1: you are collecting statistical data in a shopping mall and are collecting birthdays from passer-bys, without any additional information. This information is anonymous and not personal data, since you have no reasonable means to identify the persons. Scenario 2: in an office, there's a publicly visible calendar on the wall with the birthdays of all staff members. However, the calendar doesn't say whose birthday it is. This information is likely personal data, since it's reasonably possible to infer the correct person based on contextual information. At least HR would also have the birthday for all staff members on file, so that the company clearly has the means to identify anyone. (This doesn't mean such a public calendar is illegal, just that there must be a legal basis.) It is more difficult to determine whether information also relates to an identifiable person, i.e. whether this information is about that person. This depends not just on what the information is, but how the information is used. AFAIK there has yet to be EU-wide guidance by the EDBP, but the ICO has listed some hints. I think that a birthday of an identifiable person will almost always relate to that person.
The site would combine the data in novel ways, which is processing the data. Processing personal data which is publicly available is still processing personal data. You would have to take GDPR into account. That does not mean the processing is forbidden, but you need a legal basis for doing it. In many ways, having the informed consent is the easiest legal basis, but there are others. The data subject would have the right to demand information about the data you hold, and to demand the correction of wrong data. There is not necessarily a right to demand deletion, but if consent is withdrawn and you have no other basis for data processing, you have to delete. Note also that the consent basis would mean you have to actively contact the people whose consent you seek before the processing starts, and document how you do it. That makes pay-per-request models difficult. But consider that the news media can process some data about some people without the consent of the subjects of their activities. They just need to balance privacy and other legitimate interests all the time.
GDPR &amp; EPD require user consent before storing a users personal information. Wrong. User consent is one of the ways that justify storing personal information, but there are others. You may check art.6 to see the several reasons that allow to store personal information. In this case, it seems reasonable to justify it under the paragraph f (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Of course, that means that the data has to be used for this purpose. Avoiding spammers and other banned users would be such a purpose, but you should ensure that you do not send those e-mail address commercial information or even a Christmas greeting. In any case, be careful with anything you store. If along with the e-mail you stored more info, this could be interpreted as excessive and beyond the scope of paragraph f. For example, imagine storing &quot;User wrote nazi statements&quot; explaining why the e-mail is banned; EU laws are very restrictive about storing information about political or religious beliefs.