GDPR - What&#39;s classed as an opt in for Google Analytics cookie and do I need to do it? I'm wondering if anyone can shed any light on this for me please. I've been doing alot of research about GDPR lately and how it is going to effect my websites using Google Analytics. From what I can understand, any website which uses Google Analytics needs to first get the users consent before storing a cookie on their browser? I have implemented this in a cookie notice when the user first goes to the site and by default no tracking is enabled. Once they click agree, the page reloads with Analytics tracking. However, since I have implemented this onto my websites the drop in traffic is huge and really makes it hard to optimise and understand how the website is performing. My question is, Is it ok if in my cookie notice text said something like this.. 'By clicking agree or continuing to use this site you agree to our privacy policy' This way if they completely ignore the notice (which a lot of people do) and navigate to another page, then at least I am able to track more visits. Is this still considered clear consent?
Update: On 1 October 2019 the CJEU ruled in Case C‑673/17 (Verbraucherzentrale Bundesverband vs. Planet49 GmbH) that cookies require explicit consent regardless of personal data is being processed. (Where the exceptions don't apply). (paragraphs 68-70 of the ruling). That does probably invalidate my answer below. However, because I have based my answer on information provided by the Dutch DPA, I will not update my answer until that DPA has responded on this. 'By clicking agree or continuing to use this site you agree to our privacy policy' Neither of theses options is considered clear consent. Continuing to use the site, is implied consent, which is not sufficient. Also it does not give you the option to reject. Clicking agree to agree the privacy policy is not specific enough. You must offer a separate opt-in box for everything for which you need consent. The privacy policy is just a text in which you explain your privacy policy. It is not a contract which needs agreement. Also keep in mind that withdrawal of consent must be as easy as giving it. So you must be able to return to the settings and change them. Having said that, it is possible to configure Google Analytics in a way you don't need consent; Accept the Data Processing Amendment Go to Admin Choose Account Settings Scroll down to the data processing amendment Accept it Click Save Disable Data Sharing Go to Admin Choose Account Settings Scroll down to the data sharing settings Uncheck all checkboxex Click Save Disable Data Collection for Advertising Go to Admin Choose Account Settings Choose Property settings Choose Tracking info Choose Data collection Turn off these two options Click Save Disable the User-ID feature Go to Admin Choose Account Settings Choose Property settings Choose Trackinginfo Choose User-ID Turn off these options Click Save Anonymize your visitors IP Address Add { ‘anonymize_ip’: true } to the tracking code on your website Even though you don't need consent, you still need to add a few lines to your privacy policy: You are using Google Analytics cookies. You have a data processing agreement with google. You have enabled IP anonymization/masking. You have disabled data sharing. You are not using any other google services in combination with Google Analytics. The Dutch DPA has a more complete manual, but unfortunately it is not available in English.
Yes, a site may check for a cookie indicating past consent before prompting for consent to read and store cookies When people speak of the &quot;Cookie law&quot; they usually mean the ePrivacy Directive, (ePD) more formally the Privacy and Electronic Communications Directive 2002/58/EC. The full text of the directive is here First of all, being a directive and not a regulation, the ePD is not itself legally binding. Instead it instructs the legislatures of member states to implement it, which they generally have done. So the actual binding law is the law of a particular country, which could vary from the wording of the directive. However, in this case, my understanding is that the implementations do not vary significantly. An updated and revised ePrivacy Regulation (ePR) has been proposed, which would replace the ePD and complement the GDPR. But there has been dispute over the proposed terms of the ePR, and it has not yet been passed. Article 5 section (3) of the ePD 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 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. Notice that this covers both writing (storing) and reading (gaining access to) cookies and other information stored on a user's device. Cookies ar one form of such locally stored information (LSI). Note that the GDPR, which replaces Directive 95/46/EC, is used to define &quot;consent&quot; in the ePD. In general, one must have consent to read or store, and consent must be sought only when the user has been given &quot;clear and comprehensive information ... about the purpose&quot; of the stored information. The relevant exception for this question is that information (including cookies) which is &quot;strictly necessary&quot; to provide a service specifically requested by the user. Here the user has requested access to the web site, and may have previously agreed to accept cookies. The site must prompt for consent if the user has not previously consented (and the site will store cookies not strictly needed), and should not if the user has. Therefore, it is strictly necessary to check for and read if present a cookie indicating that such consent has previously been granted. If such a cookie is not found, no consent has been granted. Strictly required LSI should not have a dual purpose where one purpose is not strictly needed. For example, an &quot;I accept cookies&quot; cookie should not also be used for tracking. That should be done (if at all) with a separate cookie, and only after consent is received. Note that there should be an easily found and easily used method or link on the site (preferably on each page of the site) to review the purposes of stored or accessed LSI, and to withdraw previous consent. If consent is withdrawn, the cookie indicating that consent has been granted should be erased, as should any cookies or other LSI not strictly needed to provide the services requested by the user. Keep in mind that the legal distinction is not between cookies that contain &quot;technical&quot; information and those that do not. That is not relevant. Nor is the distinction between cookies that might be used to identify a person and those that do not. The legal distinction is between cookies (or other LSI) that are strictly needed to provide the services requested by the user, and all other LSI. Strictly needed LSI does not require consent, all other LSI does. For example, a random string, used to determine the number of unique visitors, but not linked to any identifying info about the user, does not help to identify an individual user. But it is not strictly needed, so it can only be stored with consent. Data that are associated with an identifiable natural person (human being, not a firm or organization), are governed by the GDPR (where it applies). There must be a lawful basis for processing such data, which includes reading them from LSI, and storing them. Consent is one of the six possible bases for such processing, but consent need not be obtained if another lawful basis applies. When consent is the basis, it must be easily withdrawn by the user. Note that this applies to all data (PI) that is associated with a person, not just data that can readily be used to identify the person (PII). Note that other workflows are also lawful. For one example, if a site is a strictly membership site, it could prompt for a login before reading or storing any LSI, and then read previous preferences stored on the server by that user to determine whether consent for cookies has been granted. Conclusion A cookie indicating that consent to access and store cookies hs previously been given by a particular user can lawfully be read before a user is prompted for consent, under the ePD and its implementing laws.
No. That is spelled out pretty clear in Article 11. In fact, if you want follow accepted data minimisation principles (and you should), you should not log anything about cookies at your or a third party's website.
The GDPR as such puts obligations on the Data Controller (DC), that is the person or firm or other entity who determines the purposes for which data is processed. The entity that hires the developer and operates the web site is responsible for compliance with the GDPR and other laws and regulations, such as the e-privacy directive and its implementing laws. However, it is highly likely that in commissioning a web site the DC would specify that it be designed to aid compliance with the GDPR and other relevant laws, and if the developer did not do that it might be a breach of contract. Indeed, even if GDPR-friendliness was not explicitly required by the contract between the developer and the DC, the implied warranties of merchantability and fitness for the purpose would probably apply. A designer who, knowing the site is to be hosted and operated within the EU, failed to design it to facilitate GDPR compliance might well be in violation of those warranties. But that would depend on the specifics of Italian law. But note that GDPR compliance is not a matter of web site design, but of the ongoing practices of the operation of the site. There are various ways to comply with the GDPR, no specific technology or design need be used. The DC must so operate the site as to comply. If the DC fails to do that, penalties could be imposed on the DC, not on the developer.
Congrats, you've done well to minimize your processing of personal data. But I think you're still processing personal data, and are subject to the GDPR. Serving a website necessarily involves processing an IP address. This IP address will typically be personal data. While you are not storing the IP address, the GDPR's definition of “processing” extends beyond storage and pretty much covers doing anything with that IP address. As far as I know this is not an entirely settled matter, but it's better to err on the side of caution and to assume that you are in fact performing a processing activity. Even a static web page can easily lead to additional relevant processing of personal data, for example if the HTML embeds resources from third party domains. Since your website is clearly targeted at the public, it does not fall under the GDPR's exception for “purely personal or household” purposes. So I think you do need a (minimal) privacy notice that contains at least the items mentioned in Art 13 GDPR. The main reason why some people try to avoid posting a privacy notice is because it must disclose your identity and contact details. But in Germany, that information has to be provided anyway due to the Impressumspflicht. As part of your GDPR compliance obligations, you must protect how data is processed by others on your behalf. A hosting provider will typically act as your data processor. For this to be legal, you need a contract / data processing agreement that fulfills the conditions in Art 28 GDPR. This contract binds the data processor to only use the data as instructed by you, and not for their own purposes. European hosting providers sometimes include the necessary terms in their terms of service / AGB, but you should check to make sure. Netcup expects you to accept their data processing amendment in your account settings. In the hypothetical case that you were not processing any personal data at all, the GDPR would not apply and it wouldn't require you to post a privacy notice. Other laws might still have information obligations, notably the German TMG and TTDSG.
It doesn’t make you exempt from the GDPR if that’s what you’re asking The hash you produce is linked to one (or a small number) of computers and it therefore serves as an ID number. Because that ID number is linked to the owner of the computer it is personal information and if you are collecting it, you must comply with the requirements of the GDPR - valid legal reason, deletion when no longer required, deletion on request, data security etc.
Is it GDPR compliant that I can't access the account that I created and the personal data that I shared because "I haven't completed their internal pre-qualification process"? Article 15 defines a “Right of access to the data subject” but it's difficult to see how this could be construed as a right to log into a specific website. Common sense suggests this would be a very bad idea. If they are willing to provide the data through another means (say a report or data dump of some sort), the obligation would seem to be met. In fact, article 15(3) even states that data controllers should merely provide the information in a “commonly used electronic form” (i.e. not necessarily through access to their systems or whatever form they are using internally for the processing). Have you asked for that and would you be satisfied by that resolution? Is it GDPR compliant that their answer to my deletion request is "We will delete the data..." The text of article 17 (right to erasure) explicitly specifies that such a request must be honored without “undue delay”. Article 12, which defines some of the modalities for the rights to access, rectification or erasure by the data subject, also provides that controllers shall “provide information on action taken on a request […] without undue delay and in any event within one month of receipt of the request”. You haven't provided any time frame and I don't think there is anything wrong with acknowledging the request by promising they “will” do it but in light of article 12, it seems you would indeed be entitled to know once they have actually taken further action. However, you implied you might want to access the data first and it's not clear to me whether you explicitly invoked the GDPR in earlier communications. So I would clarify and reiterate my request (access or erasure) and ask them for explicit confirmation once it has been satisfied.
The scope of the GDPR is entered when personal data is being processed in a structured manner. Personal data is any information relating to identifiable data subjects (definition in Art 4(1)). &quot;Peter attended the meeting on the 14th&quot; is personal data. &quot;That woman with the blue handbag said she wanted to return on the 25th&quot; is personal data. However, aggregate statistics do not relate to individuals, and are typically not personal data. &quot;On the 14th, we had 25 attendees&quot; is not personal data. Not all use of personal data is within the scope of the GDPR. For example, the GDPR would not apply if two organizers talk about who attended the meeting. However, Art 2(1) says the GDPR applies when personal data is processed wholly or partially with automated means (e.g. computers, smartphones), or forms a filing system or is intended for a filing system (e.g. keeping notes on attendees, keeping attendance lists) If GDPR applies, the organization would be responsible for ensuring compliance with its rules and principles, summarized in Art 5. Primarily, this means: having a clear purpose for processing selecting a suitable Art 6 legal basis for that purpose (e.g. consent or a legitimate interest) only processing the minimum data necessary for achieving that purpose determining and implementing appropriate technical and organizational measures to ensure compliance and security of the processing activities preparing for data subject rights, in particular by providing an Art 13 privacy notice when collecting data from the data subjects There are of course some complexities in the details. When the legal basis is &quot;consent&quot; (opt-in), the organization would have to ensure that this consent was freely given and sufficiently informed. Per Art 7(4), consent would not be freely given if that consent was a condition for access to the meeting. Using &quot;legitimate interest&quot; (opt-out) can be more flexible, but it requires performing a balancing test to show that the legitimate interest isn't outweighed by the data subjects' interests, rights, and freedoms. Roughly, relying on a legitimate interest is appropriate when the data subjects can reasonably expect the processing activity to occur. Regarding point 1, keeping general counts and aggregate statistics about attendees is probably OK since it wouldn't be personal data. If you are very conscientious about this, you could round all counts and use categories like &quot;0-4 attendees, 5-9 attendees&quot; for each facet, which makes it more difficult to make inferences about individuals. But the fundamental point is that all your data should relate to attendees as a whole, never to individuals. Regarding point 2 and 3, this is a question of legal basis. Since you gather names through informal conversations, I think that attendees would be weirded out if they learned that you kept detailed records on their attendance. So I think that you probably wouldn't have a legitimate interest here. However, being upfront with this and offering an opt-out could change this. On the aspect of keeping detailed notes on data from informal conversations, I'd like to point out H&amp;M's EUR 35 million fine back in 2020 (summary on GDPRHub.eu). In a callcenter, managers used to have conversations with employees. These conversations touched on anything from vacation experiences to health problems, marriage problems, and religious beliefs. All of that is fine. What was not fine is that the managers went full Stasi and kept detailed notes about all of this on a shared drive and used that information for management decisions. This went on until a configuration error made those files accessible to all employees. This violated all the points in the basic compliance process outlined above: the records had no clear purpose, no suitable legal basis, contained way more data than necessary (and even Art 9 special categories of data like information on health or religious beliefs which have extra protection), did not have appropriate measures to prevent unauthorized access, and did not fulfill data subject rights like the Art 13 right to be informed. In case this non-profit is a church or religious organization that had its own comprehensive data protection rules before the GDPR came into force in 2018, those can continue to apply per Art 91. This could probably address some issues of legal basis, but cannot circumvent the GDPR's general principles.