GDPR - What exactly should I do to prevent revenue loss? I've seen many sites blocking cookies right away and expecting users to click the "Accept cookies" button to activate them. But then I came to stack exchange to ask this question and there's a note on the footer "This site uses cookies to deliver our services and to show you relevant ads and job listings. By using our site, you acknowledge that you have read and understand our Cookie Policy, Privacy Policy, and our Terms of Service. Your use of Stack Overflow’s Products and Services, including the Stack Overflow Network, is subject to these policies and terms." There's no button whatsoever to agree with the cookies or not, so that means that by default the cookies are enable here and if the user is using the site, it means they're already agreeing with the cookies policy? Can I do the same to my website? If not, can I block the whole page then, leaving a notice in the middle of the screen telling the user something like "This site uses cookies to...." With the following options: ( ) Agree and proceed. ( ) Don't agree. Take me out of this site. So it basically means that if they don't agree with the cookies policy, they won't have access to the content either (Fair enough) and will be recommended to leave.
You must get opt-in affirmative consent to process personal data, including tracking people's use of your site or providing targeted advertising. The banner on StackExchange is likely in violation of the GDPR. Do not copy it. It does not have an explicit opt-in, only an opt out which is onerous (leave the site, then manually go in and delete any cookies they set, which may be hard to identify if they are from 3rd parties). The sites you mention that have a gateway are a more correct implementation. Consent must be acquired before processing of data begins, and it must be explicit.
You premise is correct. The processor is someone that processes data on your behalf, and since the GDPR definition of processing is extremely broad, that is about every third party subcontractor that you use for data processing, including various cloud providers. I'm afraid it will soon become a huge mess with a gazillion contracts to sign. I disagree. Yes, the GDPR says that a contract between the controller and processor must exist, but Article 28 of the GDPR does not say anything about how the controller shall document these instructions. Basically, in cases like the one you describe where John Doe relies on a web agency for having a contact form on the web, there will be a standardized (by the web agency) service agreement between the John Doe (controller) and the web agency (processor). There is nothing stopping the parties from agreeing that this service agreement that John Doe accepted as part of the onboarding procedure is also the DPA as required by the GDPR. Putting something like the following in the service agreement would do it: The parties agree that this Service Agreement between You (controller) and Us (processor) set out Your complete and final instructions to Us in relation to the processing of Personal Data and that processing outside the scope of these instructions (if any) shall require prior written agreement between You and Us. You also agree that We may engage Sub-processors to process Personal Data on Your behalf. The Sub-processors currently engaged by Us and authorized by You are listed in Annex A. I think we will se a lot of amendments in service contracts as the GDPR gets better understood, but I don't really see a flood of DPAs in addition to these amended service contracts.
I don't believe GDPR makes a distinction between 'real life' and 'online'. It's all real life. You can tell anyone that they don't have consent to keep your personal data, but that doesn't mean they always have to delete it. There are six lawful bases for processing of personal data, so if an organisation is using and can justify one other than consent then they don't necessarily have to delete your data when they ask. The six bases are listed by the UK Information Commissioner's Office: (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.) https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/#ib3
I think you could count decline-events, but not track users who declined tracking. But I also think such information isn't useful for demonstrating compliance. Therefore, you should avoid storing extra data about people who do not give consent. When consent is required for analytics. The GDPR provides a general framework for processing personal data. The ePrivacy Directive (ePD) overrides this general framework when it comes to cookies and similar technologies related to accessing information on the end user's device. Per ePD, such access is only allowed when it is strictly necessary to provide the service explicitly requested by a user, otherwise consent is required. Thus, analytics cookies require consent and setting an analytics-declined cookie is strictly necessary. But this consent requirement relates specifically to storage cookies, not to collecting analytics data. Thus, you might have a legitimate interest in collecting data with cookie-less analytics, which could involve counting cookie-consent decline events. Unfortunately, most analytics systems collect very broad categories of data and cannot be limited to a necessary subset. Even such limited analytics (unless they are truly strictly necessary for operating the site) should support an opt-out. I don't think you could legitimately gather analytics about such opt-out events. GDPR audits. Your motivation for collecting statistics about consent-decline events is to be prepared for a GDPR audit. This is probably not necessary, but it depends. It might be useful to distinguish between internal/voluntary audits and data protection audits by the supervisory authority. You might voluntarily review your compliance to convince stakeholders that you're compliant, and such voluntary audits might be part of the appropriate technical and organizational measures a data controller has implemented in accordance with Art 24, Art 25, and Art 32 GDPR. You should collect any statistics you need for this purpose, e.g. to ensure that the opt-in rate looks realistic. But since you can set the parameters of this audit, it makes no sense to collect data “just in case”. Under Art 58(1), your supervisory authority can audit your data processing and can compel you to provide any information it requires. This is similar to how a tax authority can compel you to produce business records for auditing purposes. This is closely related with your general obligation to be able to demonstrate compliance with the GDPR (Art 5(2)). More specifically, the controller is required per Art 7(1) to be able to demonstrate that the data subjects have given valid consent, but does not prescribe how to demonstrate this. How to demonstrate that valid consent was given. For demonstrating that consent was given, there are no clear best practices. However, this topic is briefly discussed in EDPB guidelines 05/2020 on consent. They recommend that you retain records about the following: that a data subject in a given case has consented how consent was obtained when consent was obtained information provided to data subject at the time that the controller's workflow meets all relevant criteria for valid consent Some of these are process-level concerns about how you ask for consent. For example, you might record video walkthroughs of your consent management solution to demonstrate how consent can be declined, given, and revoked. You should definitely keep a version history of the text and information that was displayed to users when they were asked for consent. I think you should also be able to explain in your front-end code how the result from your consent management solution is used to load relevant features (and that they aren't loaded before consent is given). If a feature or service is made conditional on consent, it might be good to have a short written analysis that consent is still freely given under the requirements of Art 7(4). But other aspects relate to the individual data subject and the individual consent-giving event. Some consent management solutions send a small record about the consent to a backend server where it is stored with a timestamp, so that it can be later traced that and when consent was given. I've also seen consent management tools that show a timeline of events to the user (when consent was requested, and when consent for which purpose was given and revoked). I think such detailed insight into an pseudonymous individual's consent status is a very powerful way to demonstrate compliance. What is not relevant here is information about data subjects who declined consent in the first place. Consent means opt-in. The default is that no consent is given. To demonstrate that consent was obtained in a valid manner, information about data subjects who didn't consent isn't necessary or useful. So I expect that you would be fine in an audit without collecting such data. In fact, the lack of a clear purpose and necessity for collecting this data could be argued to be without legal basis and violate the GDPR's data minimization principle. And even when recording information about those data subjects who did consent, the EDPB guidelines remind us that this “should not in itself lead to excessive amounts of additional data processing”.
I'd rather not, but this might be compliant if you make sure that the personal data under your responsibility remains secure and protected even if it is processed abroad. Since the UK has left the EU, it is sometimes necessary to distinguish between implications of the EU GDPR and the UK GDPR. These are functionally equivalent, but in the matter of international data transfers the practical details have diverged. In my answer that you cited, I argued that any website processes personal data, and is thus potentially in-scope for the GDPR. If you cause another organization to process this personal data outside of the UK, you are performing an international data transfer (called “restricted transfer” in UK guidance). For example, such non-UK processing occurs if you use cloud services that run outside of the UK. The UK ICO has guidance on international data transfers. As in an EU GDPR context, you can only perform the transfer if the data remains suitably protected, or one of the exceptions applies. The data remains suitably protected if the target country was attested and “adequate” level of data protection, or if you have implemented appropriate safeguards. As of 2022, the list of countries considered adequate is generally equivalent to the EU list of adequacy decisions. Notably, the US is no longer on that list after the Schrems II decision that invalidated the Privacy Shield Agreement. Since this decision was made before Exit Day, it also applies in the UK. This leaves “appropriate safeguards” for UK→US restricted transfers. In the linked ICO page, read the section Is the restricted transfer covered by appropriate safeguards?. In brief, you will need to perform a Transfer Impact Assessment, and sign Standard Contractual Clauses with the US data importer. In a Transfer Impact Assessment (TIA), you check that the data remains protected despite the transfer into a country without an adequate level of data protection. There is no official guidance on conducting a TIA, but the IAPP has a template and the EU EDPB has recommendations on supplemental measures to protect data transfers, which might reduce the risk and affect a TIA in your favor. It's worth noting that the EDPB recommendations were written in the wake of the Schrems II ruling, and can be summarized as “compliance is impossible when using US-based cloud services”. But this is your assessment, and TBH it seems the UK is a bit more relaxed than the EU in this regard. The Standard Contractual Clauses (SCCs) are a pre-formulated contract that binds the foreign data importer to handle the data properly. In essence, this translates relevant aspects of the UK GDPR into contract law. Many service providers already provide a Data Processing Agreement that includes SCCs by reference, but you'll have to make sure that these contracts have been entered in a legally binding manner. Sometimes these apply automatically as part of the terms of service, sometimes you need to explicitly sign these documents. But SCCs are one detail where UK GDPR compliance and EU GDPR compliance diverges a bit. The old EU SCC templates from 2004/2010 can no longer be used and have been replaced. For compliance with the EU GDPR, the new 2021 SCCs must be used. For compliance with the UK GDPR, you have two options. You can either use the 2022 International Data Transfer Agreement (IDTA), or you can use the 2021 EU SCCs along with the 2022 UK International Data Transfer Addendum which modifies the EU SCCs in some details. Don't want to deal with TIAs and SCCs? Switch to a hosting provider that only processes the personal data under your control in the UK, or in a country with an adequacy decision (e.g. EU, Canada, Israel).
Yes, it triggers the GDPR obligations Considerations: Can you surely identify those residing in Europe? In that case you should ask them to sign up again and confirm the consent. A lot of mailing lists are doing just that. Did they previously give consent and you can document it? If so, then you can argue that you have the required consent. Do you have business in Europe? If not then I don't think they would bother to go after you. You could just walk away from the fine. What other personal informastion are you storing? If you know who reside in Europe then you already have more info than just the email. The email address itself wouldn't be much of a documentation issue, SAR or Portability task.
Yes, you still need consent (opt-in). Cookies usually require consent, but not always. There are two relevant laws at play here: GDPR makes general rules about the processing of personal data, and ePrivacy has specific rules about cookies and similar technologies, regardless of whether the cookies involve personal data. The ePrivacy directive was implemented in your EU member state (or the UK) in national law. The national laws contain the authoritative rules on this matter. But in general: Accessing or storing any information (such as cookies) on the end user's device requires consent. Consent is defined by the GDPR. You do not need consent if the access/storage is strictly necessary for a service explicitly requested by the user (“functional cookies”). Using cookies to store site preferences such as user language is strictly necessary for a service explicitly requested by the user, so you do not need consent for this. You must still make your use of cookies transparent to the user. Setting cookies for marketing purposes is not strictly necessary to provide the service, so you always require consent for them. Registered users don't automatically give consent. You now raise the interesting question if this is also the case if the user is already registered. Yes, you still need consent (opt-in). This is due to the way how the GDPR defines “consent”. Consent is not general or vague agreement. Agreement with your terms of service or privacy policy is not consent in the sense of the GDPR. Instead, consent is defined in Art 4(11) GDPR to be (emphasis mine): 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 Art 7 GDPR adds further conditions for consent. (1) You are responsible for demonstrating that the user has given valid consent. (2) The request for consent should be clearly distinguishable from other matters (i.e. not buried in a larger document) and should be presented “in an intelligible and easily accessible form, using clear and plain language.” (3) Withdrawing consent must be as easy as giving it. (4) In general, you cannot make access to a service conditional on unrelated consent. I.e. you can't force your users to consent to marketing cookies in order to use the app. The users must have an actual choice, or the consent isn't freely given. Supervisory authorities have produced extensive guidance on the matter of consent. If you're in the UK, consider the ICO Guide to Consent and Guidance on the use of cookies and similar technologies. If you're in the EU/EEA, consider the EDPB Guidelines 05/2020 on Consent (PDF). To summarize why agreement with your terms of service is not consent to marketing cookies: Agreement to such large documents is not sufficiently specific. The consent would not be sufficiently informed. You cannot expect users to actually read all your legal documentation. You must present information in an intelligible manner, possibly with multiple layers (compare WP29 Guidelines on Transparency, endorsed by EDPB). Agreement to your terms of service is not an unambiguous indication that the user wants these cookies. If consent to marketing cookies is a condition of using your service, the consent is likely invalid. The consequence is that cookie consent is usually obtained via separate consent management tools that provide detailed explanations about different categories of cookies, and let the user select which specifically categories of cookies they want to consent to, if any. Outside of cookies, consent is just one legal basis among many. In this context, you might ask “if getting consent is so difficult, but GDPR requires that I have consent, how does that work?” It is a common misconception that the GDPR requires consent for everything – the ePrivacy requirement that most cookies need consent is one of the exceptions. In general, GDPR offers a choice of six categories of legal bases for processing in Art 6 GDPR, and consent is just one of them. In many cases, an online service will process personal data because it is necessary to fulfil a contract with the user, or because there is a legitimate interest for the processing (and the legitimate interest outweighs the user's interests). For example, reasonable security measures such as keeping logfiles can be based on a legitimate interest and do not require consent.
I understand that storing any hash or IP that can identify &quot;user uniquely&quot; is against GDPR. That is not correct. However any data which is identifiably associated with a an individual human, including any data which could be used to identify that human, is generally &quot;Personal data&quot;, and may not be processed (which includes storing it) without a lawful basis, if the GDPR applies. Any of the six lawful bases allowed by the GDPR may be used, including consent, and the legitimate interest of the data controller. The GDPR does not generally specify that particular technological solutions are permitted or forbidden. If this usage pattern could reasonably be used to identify a particular person, or to single out a person from among a group of people, it is probably personal data, and a lawful basis would be required. Otherwise, not. As for whether such a person is &quot;identifiable&quot; if use of this technique permits the Data Controller to identify two visits at separate times as having been made by the same person, when the later visit is still in progress or is recent, the IP for that visit will still be available, and thus could be associated with the first visit as well. And even if that is not done, such a technique could permit building a profile of such a person, including the actions taken on different visits. I think that would be enough to make this &quot;personal data&quot;.