GDPR &amp; EPR regards maintaining email blacklist Note a user call YIVI had previously stated that you could store a hash of the users email address to avoid the requirements of General Data Protection Regulation (GDRP) and ePrivacy Directive (EPD). This is false as hashed email addresses are still considered personal information under the regulations as it is still may be possible for the data controller to identify the actual email address associated with the hashed value i.e. the data controller still has personal information stored of the user. Pseudonymized data is still unequivocally considered personal data under the GDPR, as noted in Recital 26. GDPR Recital 26 states &quot;Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person. &quot; Under GDPR &amp; EPD a persons hashed or un-hashed email address can be considered personal information. GDPR &amp; EPD require user consent before storing a users personal information. Websites need a way of blacklisting malicious users i.e. add the users email address to a blacklist to prevent them logging into the website. Similarly when a user deletes their account on a website their email address may be added to a blacklist to prevent another account being opened with the same email address for various security and management reasons. Under GDPR a user has the right to be forgotten and can request that their personal information be deleted. Are we allowed to keep the users email address in a blacklist if they request that their personal information be deleted ?
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.
IP addresses are personal data. That means you need a legal basis to process them, but not necessarily consent from the user. That IP addresses should be treated as personal data in most contexts is clear, regardless of whether you can associate the IP address with a user ID. That you make such an association affirms that both the IP address and user ID are personal data in your context though. As the answers in the questions you linked indicate, there are alternative legal bases to consent. The GDPR offers a choice of six legal bases (Art 6(1) lit a–f). In most cases, you would instead rely on a “legitimate interest” for logging. But it's not enough to claim that you have a legitimate interest. You must have a clear purpose for which such logs would be necessary, and you would then have to weigh this legitimate interest against the interests, rights, and freedoms of the affected data subjects. If such logs are necessary for security and anti-abuse purposes, your legitimate interest test is likely to prevail. However, you must limit retention of the logged data and the included information to what is actually necessary. For example, keeping user IDs in there might not be necessary. If the association of IP addresses and user IDs is not necessary for a legitimate interest, then you would indeed need consent. Discussion on why IP addresses are personal data. You see many answers and opinions that IP addresses might not be personal data. Some of these are technically correct, but most are misinformed or outdated. I know only a single well-informed person that still disagrees. For everyone else such as the EU Commission, IP addresses are clearly personal data. Under the GDPR, personal data is any information that relates to an (indirectly) identifiable natural person. In the context of log files we can assume that the entries usually “relate” to a person, namely the person making the request. The exception would be requests triggered by automated systems. The more interesting question is whether the person to which the log entry relates is identifiable. While the GDPR does provide further guidance on the concept of identification in Recital 26, it does not provide clear unambiguous criteria. Thus, there is lots of debate about what that precisely means. One approach is to sidestep that debate and and notice that the GDPR's definition of personal data explicitly notes that a person might be identified “in particular by reference to an identifier such as a name, an identification number, location data, an online identifier” (Art 4(1)). Another but otherwise unrelated part of the GDPR mentions “internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags” as examples of online identifiers (Recital 30). We can also look more deeply into Recital 26 and see that “singling out” already counts as identification. We can use the IP address to single out one person's log entries from the set of log entries, so this could be interpreted as meaning that any stable user ID renders the data personal data – and an IP address is sufficiently stable in this context. Another part of Recital 26 says that we must consider “all the means reasonably likely to be used” for identification, even if this involves additional information from third parties. This phrasing is virtually identical to the GDPR's predecessor, the EU Data Protection Directive. On the basis of that DPD, the EU's top court (ECJ/CJEU) was asked to rule on the question whether dynamic IP addresses are personal data (the Breyer case, C‑582/14, judgement from 2016-10-19). It said yes. “It did not say yes”, some people will object. And they are technically correct. When someone rents an internet connection from an ISP, the ISP will have logs that connect the user's real-world identity to the IP address they were assigned at a time. You don't have access to the ISP's logs. But, if that user violated your rights (e.g. a cyberattack or copyright infringement), then you could (depending on civil vs criminal matters) report this to the appropriate authorities or to petition the court and they would have the right to order the ISP to disclose this information. The CJEU said that if this chain (you → authorities → ISP → user identity) is grounded in law, then the IP address would be identifiable. But whether there are suitable laws to compel the ISP to disclose this data would be up to national laws, and the CJEU doesn't concern itself with that. Spoiler: such laws are pretty common. To summarize typical objections: The IP address doesn't relate to a person: Can be a valid objection, but is not typically the case for user-facing web services. The Recital 30 argument is not valid because it's about profiling, not identification, and it only says that IP addresses may be used for profiling, not that they are always identifying: Technically correct, but I think that Recital 30 merely expresses the implied understanding that of course an IP address is an online identifier and permits identification by itself. “Singling out” does not apply because SOME_REASON: Indeed, this is an ill-defined term with no case law to guide us. However, regulators such as the EDPB and their predecessor WP29 routinely use “singling out” to mean being able to distinguish one person's data from other people's data. An IP address lets us do that. The Breyer judgement is not applicable because the defendant in that case was the German state, and the state has other legal means than ordinary website operators: Nothing in that case was specific to the website operator being a state or other authority. If the website operator can contact the appropriate authority and if they have the right to order the ISP to disclose the relevant data, then the IP address is identifiable. The CJEU didn't say “yes” in Breyer, it said “if”. So I'll take that as a “no”: The CJEU concerns itself with the interpretation of EU law, not with national laws. Specifically in the Breyer case, lower courts confirmed that German law has the necessary means. In other EU member states, further checks would be necessary but it would surprise me if there wouldn't be equivalent subpoena powers. If the ISP doesn't have the data, then the IP addresses are anonymous: Indeed, the CJEU scenario collapses if there is no additional data to be linked with the IP address. However: The CJEU used this scenario as an example to show that IP addresses can be identifiable. If that particular scenario fails, there could be other scenarios that still allow identification. The question of whether IP addresses are identifiable had of course been the subject of wider debate at the time. That the GDPR explicitly mentions IP addresses can be seen as a reaction to this debate. Thus, in a sense, the Breyer case is moot. It is still useful as an explanation of how broad “reasonably likely means” must be interpreted.
TL;DR In theory there's nothing wrong with your method, it's just a way to authenticate the user, and without authentication a user has no right to request anything anyway. But in practice it looks like your method doesn't have a way to deal with situations where users lose or forget their authentication data and want to be able to recover their account. Failing to deal with that in a modern system might be considered an unacceptable bad practice and so be against the GDPR principles of security and privacy by design. EXTENDED VERSION I might be wrong or not understand the question correctly, but I don't see how this is different from many other common cases where encryption is not involved. Think about it, you aren't able to give the user their own personal data unless they provide the ID and encryption keys. How is this significantly different from the fact you aren't able to (or rather you should not) show a user their own data unless they provide their own username and password, or they convincingly authenticate themselves in any way? Just like you can't ask Facebook to show you all the data collected about Donald Trump only by claiming you are Donald Trump, you can't be required to give a user their own data unless they provide the encryption key. It can be seen as your way to authenticate users (among other things). Edited: multiple IDs/keys I didn't understand your method involved multiple IDs and keys. In theory, the situation is still the same, only with multiple pieces of data for authentication, like the user had to remember multiple usernames and passwords. Failing to provide all IDs and all keys will result in a partial authentication. But with such an approach a potential problem becomes more evident: your authentication scheme might be against the GDPR principles of "security and privacy by design and by default". Basically, your methods might be considered bad practice because they fail to deal with the common issue of lost or forgotten passwords. If a user tells you they have lost a USB drive containing all their IDs and keys and they don't have them anymore, what do you do? You can't delete their data because you aren't able to know what their data is, without another way of authenticating. And their data is now at risk, because somebody else might have their IDs and keys. If you had an email address associated with all the user's IDs and data, then you might be able to confirm their identity (for example sending an email with a link) and delete all their data. As you see, things can get pretty complicated, it all depends on the details of your implementation, and just adding or removing one detail might change the whole scenario.
I'm not entirely sure why you have to store the data of the invited user? You can simply hash the email address. Hashes are meaningless without the original input so that would allow you to store the data. Sending email means that you're processing personal data. In your use case it would fall under Art 6 (f): Legitimate Interest. (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. I do advice you to also follow these guidelines in the submission of the email: https://sendgrid.com/docs/Classroom/Deliver/Address_Lists/peer_initiated_email_invitation_requirements.html
Yes. Article 4 GDPR Definitions (1) ‘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; Recital 26 Not applicable to anonymous data The principles of data protection should apply to any information concerning an identified or identifiable natural person. Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person. 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. 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.
If the GDPR applies, then the e-privacy directive (EPD) (formally Directive 2002/58/EC of the European Parliament and of the Council of 12 July 2002) almost surely also applies. However, this being a directive rather than a regulation, the implement6ing laws may vary in different countries. The relevant provision is Article 5 paragraph (3) which reads: Member States shall ensure that the use of electronic communications networks to store information or to gain access to information stored in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned is provided with clear and comprehensive information in accordance with Directive 95/46/EC, inter alia [among others] about the purposes of the processing, and is offered the right to refuse such processing by the data controller. This shall not prevent any technical storage or access for the sole purpose of carrying out or facilitating the transmission of a communication over an electronic communications network, or as strictly necessary in order to provide an information society service explicitly requested by the subscriber or user. This governs cookies and any other local data, that is, data stored on or read from the user's equipment. What this means is: A site operator must disclose, in detail, what cookies or other local data the site stores on or reads from the user's device. Even strictly required data (cookies) must be disclosed. A site may not store or read any local data until after consent has been obtained. The user must have the option to consent to or refuse consent to individual data items separately. Giving consent may not be a condition of permission to use the site. Consent must be opt-in, not opt-out, that is the default must be &quot;No consent&quot;. Local data (including cookies) that is &quot;strictly necessary&quot; for the operation of the site is exempt from the requirement of consent, but not from the requirement of disclosure, and that means specific disclosure. It must be at least as easy to cancel consent later as it was to give consent initially. Do my Stripe cookies count as essential cookies? If the Stripe cookies count as essential, is it legal to provide no option to turn them off? Have I met my legal requirements in terms of disclosure? The terms and conditions and privacy policy were generated by Termly. I don't know stripe well enough to be sure, but they might. What do they do that is essential for operating the site? Yes. No, not if the disclosures in the question are the only ones you make. As I understand it, you must provide at least a link to a page that shows each specific cookie that you read or set, and what data is stored in that cookie, even for strictly required cookies. Update: I should mention t6hat although the above describes my understanding of the current legal requirements, I have read that enforcement of those requirements does not seem to be a priority for the relevant authorities at this time. Other aspects of data protection, such as proper security to avoid data breaches, and having a proper legal basis for processing, and other GDPR requirements, as opposed to e-Privacy requirements, seem to get more attention and resources from the relevant authorities. Having read the comment by the OP, it does seem that at least some of the stripe cookies are strictly required and need not have consent. The stripe cookie policy linked to is better than many sites currently offer. It does not go into fully specific detail, but it may be that the dashboard does, and that together the two are fully compliant. Linking to this policy (and if possible directly to the stripe cookie dashboard) would seem to me to cover most of the issues here.
There are a few different grounds under which PII can be handled. Perhaps the most discussed at the moment of GDRP introduction is consent, because of the wave of consent-seeking. But there are a number of other grounds. "Necessary for contract execution" is a trivial one, to deliver a pizza you'll need an address. The relevant ground for sanctions lists is also pretty obvious in hindsight, you may process PII in order to comply with legal obligations. Note that this is still an integral part of the GDPR, not an exception to the GDPR. That means you need to apply all the basic GDPR rules. You need to explicitly store where you got the PII from, for which purpose, and you need to document how you're using it. Note that this might be hard - why do you need to store this data? Why can't you just check the list as the moment it's relevant? The GDPR for a large part depends on you justifying your actions, not just in hindsight but already up front.
The GDPR has an exemption for purely personal or household activity. Creating a family tree seems purely personal as long as you don't publish it. You're also allowed to freely share the tree as long as it stays within that purely personal scope. Your proposed restriction of only showing data of blood relatives seems excessively strict. But assuming that this exemption wouldn't apply, there'd probably still be no problem. The GDPR does not require you to always obtain consent. It requires that the purposes for which you process personal data are covered by some legal basis. Consent is one such legal basis, but legitimate interest is another. You can likely argue that you have a legitimate interest to create a tree of your (extended) family. The legitimate interest must be weighed against the rights and freedoms of the affected persons. For example, contact information could be used for stalking. The balance of the legitimate interest check can be changed if you adopt suitable safeguards. Your idea of only sharing data with close relatives would be such a safeguard, but it might not be necessary. When you rely on legitimate interest, the affected person can object to further processing, furthermore they can request to be erased from your records. A request for erasure can be denied if there are overriding grounds to keep the data. E.g maybe only contact information has to be deleted but names, dates, and relations might be kept. You should notify persons when they are included into your records. It is your obligation as the data controller to make these decisions. If someone disagrees they can sue you or lodge a complaint with a supervision authority. Note that dead persons are not natural persons in the sense of the GDPR, and have no privacy. However, national laws may provide such protections.