GDPR - Withdrawn user consent I have been reading alot about user consent management according to the GDPR and one problem I can't see solved anywhere is managing withdrawn consent. The user gives his consent to use his data and save personal information like his E-Mail address, IP address, ... If the user withdraws his consent I would have to somehow store this decission in my database to make sure I always have proof of a prior consent and at which date the user has withdrawn his consent. But how do I keep track of a withdrawn consent if I can't save any personal information to identify this person anymore. Isn't this a contradiction? Always having the ability to prove everything but being forced to delete all saved data records? Is there any part of the GDPR I am missing, that solves this specific problem?
This could be covered by point 1(c) of Article 6: Processing shall be lawful only if and to the extent that at least one of the following applies: ... (c) processing is necessary for compliance with a legal obligation to which the controller is subject; ... It might also fall under point 1(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. It is difficult to know whether any particular processing of data falls under either of these points because of the lack of relevant court decisions. The latter is particularly slippery, since whether any interest is &quot;legitimate&quot; is at least partly subjective, and whether any interest of the data processor overrides the data subject's interests, rights, or freedoms, is even more so. I should also note that point 1(a) is the point that requires user consent, so the other points explicitly take the place of consent rather than being somehow required alongside consent: (a) the data subject has given explicit consent to the processing of those personal data for one or more specified purposes, except where Union or Member State law provide that the prohibition referred to in paragraph 1 may not be lifted by the data subject;
From a German perspective, it would be absolutely normal and expected that you're providing identity &amp; contact information publicly. Per §5 TMG (Impressumspflicht / Anbieterkennzeichnung) this is required for German tele-media offerings, such as websites or email providers, even if non-commercial. Whereas for you as an upstanding and diligent email provider an abuse@... address should be enough, the German context expects a street address where you could be served with a lawsuit… There absolutely are privacy and free speech issues with this compelled self-doxxing. But by running an email service, you're not just acting as a private person. Your privacy interests and the transparency and security interests of other people have to be balanced. Now since you are not in Germany, the TMG does not apply to you. You have no legal obligation to provide this information. However, the ISP also has no legal obligation to to deliver your email. The ISP does have an obligation to apply appropriate organizational and technical safety measures. It seems that one organizational measure they have found appropriate is that they will only deliver emails from providers that provide public contact information, as would be the norm in Germany. I am not entirely sure how the GDPR applies here. The GDPR doesn't really allow or prohibit disclosures of personal data, it just requires that every purpose of processing for personal data has a legal bases per GDPR Art 6. One such legal basis is a legitimate interest, which boils down to a balancing test between your rights and freedoms and other people's interests. I'm also not sure if the contact information should be classified as personal data in this context, because the contact info primarily relates to your role as an email provider. I'm also not sure if the ISP is processing your personal data in the sense of the GDPR when they merely require you to publish it on your own site. They would be processing it as soon as they scrape, store, or otherwise use this info.
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?
The GDPR doesn't generally distinguish public from non-public personal data. If you have a good reason to contact the professor, do send them an email. GDPR does not prevent this. If you're sending this email for “purely personal or household purposes”, then GDPR doesn't apply anyway. There are rules in the ePrivacy Directive against unsolicited emails, but these specifically relate to emails for direct marketing purposes. A company is not allowed to send out spam marketing, regardless of whether they obtained the email address from a public data source. Companies can send email marketing to their own existing customers, or to people who have given consent. Consent is defined in a fairly restrictive way (as a specific, informed, freely given, and unambiguous indication of the data subject's wishes), so that mere publication of an email address cannot be interpreted as consent to receive marketing from a particular company.
How to properly ask for consent is an evolving issue. Your general consent flow is very common, but I don't think it's entirely compliant. Legal background on consent Consent is one of the Art 6 GDPR legal bases for processing. The ePrivacy directive (ePD) also mandates consent for accessing information on a user's device, where such access is not strictly necessary for a service explicitly requested by the user. For example, this means that analytics cookies require consent. Consent is defined in Art 4(11) as: any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her Further conditions for consent are given in Art 7, such as that “It shall be as easy to withdraw as to give consent”. The EDPB guidelines 05/2020 on consent provide extensive interpretation of the GDPR that should be considered as effectively binding. First layer: accept / change preferences The first consent layer provides general information about the purposes that consent is being sought for. This seems to be mostly compliant, but I have some doubts. Consent must be freely given, and withdrawing consent must be as easy as giving it. I would therefore recommend having a “continue without consenting” option that is given roughly equal prominence to the alternatives. Consent must be informed. Even in the first layer, you must give basic information. In the EDPB guidelines, the following items are identified: controller's identity purposes of processing what type of data will be collected existence of the right to withdraw consent if relevant: that the data will be used for profiling/automated decision making if relevant: possible risks if international data transfers are made under Art 49(1)(a) I think this makes it difficult to collected an “agree to all” style consent that covers all purposes. It would be better to clearly distinguish between the analytics and advertising purposes even in your first layer. Consent must be specific to a purpose. You try to make this possible via a second layer where granular choices can be made. This isn't entirely bad, since you also need to make the consent flow simple enough as to avoid click fatigue. But since you only have two processing purposes, it would be better to show them separately on the first layer. You cannot generally make access to the app conditional on unrelated consent. The statement “This app uses tracking identifiers” suggests that there is no choice. It would be better to make it clear that the user can voluntarily consent to such processing. Together, this would mean that a design like the following could be more compliant. Text in [brackets] indicates buttons or links. Your privacy choices To support and improve this app, you can choose to give us access for the following purposes: Analytics: understanding how you use this app We would like to collect information on how you interact with the app, and store cookies on your device for this purpose. [more information] [decline / agree] More relevant advertising We will always show ads, but if you want we can build an interest profile to show you more relevant ads. [more information] [decline / agree] You can always change your choices in the app settings, but past use of your data remains legal after withdrawing consent. ExampleApp is provided by ExampleDeveloper Ltd. [full privacy notice] [continue] Second layer: detailed information about all services Your second layer sounds good, as it provides granular controls and more detailed information. As already mentioned, I would move some of this to the first layer. But one of your questions pertains to the defaults on this screen: It is OK if I set all of the options to enabled the first time that the user goes to the preference screen (enabled by default) ? No, this is not OK. Consent means opt-in, and requires an affirmative action by the user. You cannot have pre-checked checkboxes. The default is that no consent was given. If you have an “enable all” button, I would also expect a “disable all” button. Else, consent might not have been given freely. You also cannot rely on the consent until consent has been actually given. So you must not start collecting analytics in the background while the user is still on the consent choice screen. In addition to being non-compliant by itself, loading pre-ticked checkboxes increases the risk that your application accidentally considers the consent as already being given, which could easily lead to illegal processing if there's a bug in your app. You might have processing purposes that are based on a legitimate interest instead of consent. These can be enabled by default, but you generally have to make it possible for the user to object. Your relationship with third parties When using third party services, it is crucial to understand if they are a processor who is contractually bound to only use the data on your behalf, or a separate processor. You must disclose processors (or at least categories of processors) in your privacy notice, but not really during the consent flow. The GDPR does not distinguishing between doing processing activities yourself versus outsourcing them to a processor. In both cases, you are the controller, and only you are asking for consent. Thus, it's also superfluous to show third party privacy notices. It's your obligation as the controller to provide all necessary information. If you are collecting consent for other controllers with whom you have joint processing activities, you must make this much more prominently. You would have to disclose in the first layer that you are sharing the data with other controllers who can use the data for their own purposes. This sharing is part of the processing purpose. This is quite tricky to do correctly when it comes to ad networks, since ad networks generally won't be your data processor and can have many intransparent members. Demonstrating consent As the data controller, it is your obligation to be able to demonstrate that valid consent has been given. This implies process-level obligations such as being able to show that your consent flow is non-coercive and makes it possible to decline consent. This also implies individual-level obligations such as being able to show when a given user has given or withdrawn consent for which purpose. If you have a backend anyway, it could be sensible to store information there about consent/withdraw events. When the user returns to the consent management screen through the app settings, you could show a timestamp like “you consented to this purpose on 2021-08-22 17:14:23”. I have recently written a more detailed discussion about demonstrating consent.
This is clearly personal information (PI) , and indeed personally identifiable information (PII). and so is Personal Data under the GDPR. Under Article 6 of the GDPR any processing must have a lawful basis. There are 6 possible bases. The most likely ones here would be (a) consent, or (f) legitimate interst, but the private association may claim some other basis as well. They should tell you what basis or bases justify their processing of this information, which includes storing it and publishing it. Under Article 13, Paragraph 1(c) the association should have informed you of the purposes for which information was collected when it was first collected. Under Article 15 paragraph 1 you are entitled to request and obtain from the association (or any other Data Controller) a statement of what PI about you they hold. along with this they must supply various other information including; (a) the purposes of the processing; (b)the categories of personal data concerned; (c) the recipients or categories of recipient to whom the personal data have been or will be disclosed, in particular recipients in third countries or international organisations; (d) where possible, the envisaged period for which the personal data will be stored, or, if not possible, the criteria used to determine that period; (e) the existence of the right to request from the controller rectification or erasure of personal data or restriction of processing of personal data concerning the data subject or to object to such processing; (f) the right to lodge a complaint with a supervisory authority; and other specified information. Article 17 paragraph 1 provides that: The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay ... if one the the specified conditions applies, particularly: 1(b) the data subject withdraws consent on which the processing is based according to point (a) of Article 6(1), or point (a) of Article 9(2), and where there is no other legal ground for the processing; 1(c) the data subject objects to the processing pursuant to Article 21(1) and there are no overriding legitimate grounds for the processing, or the data subject objects to the processing pursuant to Article 21(2) Article 21 paragraph 1 provides that: The data subject shall have the right to object, on grounds relating to his or her particular situation, at any time to processing of personal data concerning him or her which is based on point (e) or (f) of Article 6(1), including profiling based on those provisions. The controller shall no longer process the personal data unless the controller demonstrates compelling legitimate grounds for the processing which override the interests, rights and freedoms of the data subject or for the establishment, exercise or defence of legal claims. Thus I would suggest that you send a written communication to the association, stating that you: Request access to all PI which they have about you, as permitted by GDPR article 15 paragraph 1; Request that they delete any such information from the public website and any other publications, as permitted by GDPR article 17 paragraph 1; State that you object to further processing of this information under GDPR article 21 paragraph 1; Request information on the name and contact info of the relevant supervisory authority under GDPR article 15 paragraph 1; State that you expect these requests to be complied with promptly, in no event later than 30 days. Mention your prior request for the public info to be deleted, and that several months have already elapsed. Give the exact date of the prior request. I would suggest sending these requests, together in a single email, specifically mentioning the relevant GDPR provisions. I would suggest sending a copy of this by registered mail, and retaining a copy, along with the identifying number of the registered letter. In the letter, mention the email. If the association does not promptly respond in a way you consider satisfactory, you may wish to file a complaint with the relevant data protection supervisory authority. You may also wish to consult a lawyer with experience in this area to determine if you have any legal recourse if the association does not comply.
[I'm not so well-versed on US and Russian law, thus I will limit my answer to EU law.] Your specific use of a user identifier, as I understood from your question, can be classified as personal data, so in your case, the GDPR seems to apply. This means that you need to have a) legitimate purposes to process that personal data (e.g. crash reporting) and b) a legal justification for each purpose of processing: it could be based on consent or another legitimate purpose (inc. your own legitimate interests). Consent might not be the best option for you, but it's up to you to decide. In any case, you need to assess the risks to the data subjects (your users) before you decide. How likely is it that you will get breached, and what potential harm will that cause to your users? These are some guidelines; my recommendation is that you read the law and the guidelines by the Article 29 Working Group and European Data Protection Board, or hire some good experts on this. There is no easy answer, or one size fits all solution. The GDPR isn't so hard to understand or implement, but it does require some change in mindset. With the new law, processing personal data carries a higher risk of penalties, so you should do it only when it's absolutely necessary, and with respect to the rights of your users.
Per GDPR Art 79, you can sue data controllers if you consider your rights to have been violated. Where you have suffered damages due to GDPR infringements, you also have a right to compensation per Art 82. However, your rights may not have been violate as far as the GDPR is concerned. Under the GDPR any kind of personal data processing needs a clear purpose, and that purpose needs a legal basis. One possible legal basis is consent, but there also are others (such as legitimate interest). Just because you didn't consent doesn't mean that your rights have been violated. Where processing is based on legitimate interest, you can object to that processing of your personal data – but your rights must be balanced against that legitimate interest (Art 21). If your friends post a photo and you only appear in the background, your friends' legitimate interest to post that photo likely outweighs your rights. In practice, suing Facebook because of GDPR infringement is not a sensible way to achieve the outcomes that you likely want. First, this is expensive. Second, it is arguable whether Facebook or your friends should be the defendant. Third, removal of existing data won't prevent the processing of new data in the future. It would be more sensible to treat this as an interpersonal rather than a legal problem, and to talk with your friends so that they don't include you in their photos that they would like to share online. I've focussed on photos because their situation is fairly clear. Voice snippets might not count as personal data when you are not identifiable in them. Personal assistant apps should not be listening continuously, but only start recording when a wake-word is recognized.