GDPR - Confirm company terms and conditions by button click This May the General Data Protection Regulation (GDPR) will be applied across the EU. I read somewhere that users have to always 'opt-in' after this law is effective. Since I'm concerned about conversion for a website, is it OK to let users confirm by using a button? For example, like Mailchimp does:
The basic requirements for the effectiveness of valid legal consent are defined in Article 7 of the GDPR and specified further in Recital 32. There is no form requirement for the consent, so using a button is not a problem. However, I do not think the MailChimp-button you reproduce as an example is good enough. It asks for a blanket consent to stuff that is buried in MailChimp's “Anti-spam Policy &amp; Terms of Use”. But according to the GDPR, what the data subject consent to can’t be buried in the ToU – it must spelled out in clear, plain language. Requests must be granular, asking for separate consent for separate types of processing. “When the processing has multiple purposes, consent should be given for all of them” (Recital 32). Blanket consent, as used by MailChimp, is not allowed. The other clear requirement from the GDPR is that opt-in is mandatory. Pre-ticked and opt-out buttons are explicitly banned: “Silence, pre-ticked boxes or inactivity should not therefore constitute consent” (Recital 32). ‘No’ must become your data default, but if the user chooses to opt-in by clicking a button, this is valid consent. The MailChimp-button complies witrh this. The GDPR also requires you to keep a records of the consents given (so make that part of the user profile), and to withdraw consent at any time &ndash; so you make make provisions for that as well in your implementation of consent.
You are responsible for what data is being processed by your website. When you embed third party components on your website (e.g. iframes, scripts), you are at least jointly responsible with the third party providing these components. You are only responsible for what happens on the website (i.e. what processing is under your control), not for what the third party provider does with collected data on their services. However, note that information will be transferred to Google's servers regardless of whether the visitor has a Google account! The Fashion ID case is relevant case law establishing and explaining these points. Since you are (jointly) responsible, you need a legal basis for collecting personal data through the tracking snippet and sharing it with the third party (here Google). For example, the legal basis could be a legitimate interest, or could be consent. A legitimate interest requires that you balance this interests against the interests, rights, and freedoms of the data subject (the site visitor). If the data subject wouldn't reasonably expect this tracking, you cannot rely on a legitimate interest. Consent can always work, except that it is a freely given, informed opt-in – likely unsuitable for conversion tracking. Which legal basis to use is primarily your responsibility. You argue that the tracking snippet does not collect personal data. However, this argument is not well supported. Under the GDPR, personal data does not only include directly identifying information such as an email address, but also any information “relating” to an identifiable person. Identification includes the ability to single out someone, e.g. by a browser fingerprint. For purposes of conversion tracking, Google will clearly try to collect data that allows the visitor to be singled out, thus collecting personal data. Furthermore, specific kinds of information are regulated by the ePrivacy directive. This includes “traffic data” and “information stored on a terminal device”, regardless of whether this information is personal data under the GDPR. Under ePrivacy, such information can only be used as strictly necessary to provide the service requested by the user (and conversion tracking is not strictly necessary), or when the user gives their consent. Depending on what information is collected by the tracking snippet and on whether you are subject to ePrivacy, you would have to collect consent anyway. There is also the issue that Google Ads is an US-based service, and transferring data to the US is largely illegal since the 2020 Schrems II ruling. The US do not provide an adequate level of data protection, so that transfers would require additional safeguards. Standard Contractual Clauses (SCCs) for Controller to Controller transfers are not sufficient by itself. Of course those extra safeguards are effectively impossible to implement and no one is doing this correctly, but it's worth considering that there is additional legal risk. Explicit consent can provide a legal basis for transfers even to a country with inadequate protections, but that mechanism is intended for occasional transfers. In conclusion: you have wrongly concluded that no personal data would be involved you are jointly responsible with Google for whatever data is processed by the conversion tracking snippet you need a legal basis for sharing this data with Google legitimate interest may be sufficient, depending on what data is involved (consider ePrivacy) and depending on the result of your legitimate interest balancing test alternatively, you may require every visitors consent to track their conversions – unlikely to result in good data additionally, such use of Google Ads may run into issues around international transfers due to the Schrems II ruling this kind of stuff is difficult, and no one is really doing this correctly :/
If you are not processing the personal information of EU citizens yourselves then you are unlikely to be classed as data processors under GDPR (check Article 3: Territorial Scope, p.32-33). If you were to operate a Software-as-a-Sevice (SaaS) solution then you would be a data controller/processor (or both) and GDPR would certainly apply if you have EU citizens as customers/users. While I can't see any reference to software vendors in the GDPR text, as a software vendor it would be in your interest to ensure your products meet the criteria set out in Article 25 (Data Protection by design and by default, p.48) in order to help your customers to comply, such as: Implement appropriate technical measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects. Implement appropriate technical measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons. These along with similar organisational measures are the responsibility of the data controller, but unless your software helps them to comply they may be forced to consider alternative solutions which reduce their overall risk. If your software already has a number of such controls in place it may be worth putting a white-paper or similar communication together which can inform your customers of how your software helps them to comply. There does not appear to be any direct liability to the software vendor through GDPR. If a data breach is the result of a design flaw or implementation bug in the software and your customer gets fined as a result, they may be likely to pursue you on grounds of the software not being fit-for-purpose and lacking the appropriate technical controls required to ensure data privacy. In this event, your defence will rely upon records of designing and implementing controls, records of software testing and remediation, and having in place suitable procedures to ensure security patches can be quickly deployed to your customers when required. Further clarification as requested: If your organisation doesn't process the personal data, doesn't have any third parties process it on your behalf (includes hosting companies) or have any access to it ever, then you're neither a controller or processor. However, if your customers ever send you personal data or grant you temporary access to personal data as part of troubleshooting issues with your software, then you would be a processor in this context and would need an appropriate contract in place and would need to ensure the appropriate technical and organisational controls are implemented to comply with GDPR and reduce risk of a personal data breach. Additionally, if international data transfers take place as part of this (e.g. sending/accessing files over the Internet) you would need to ensure your organisation is able to provide an equivalent level of protection for the rights of the data subjects - for example if you are in the U.S. you would likely need to voluntarily join up to the EU-U.S. Privacy Shield or use the EU's Model Contract Clauses within your contracts in order for it to be legal for EU-based businesses to use you as a data processor. For more information about international transfers read the EU's Data Transfers outside the EU page. Ref: GDPR
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.
The law of each country where you offer the app for download applies, and you have to consider: Privacy Policy (GDPR in EU, CCPA in California, APPI in Japan, LGPD in Brasil, and more - check each country to be on the safe side) Disclaimer versus AGB/Terms and Conditions (e.g. Germany), not required but recommended Impressum (Germany, Switzerland, Austria) Value Added Tax (VAT) which is taken care of e.g. by Google Play for most countries but not all (e.g. not for Japan) in case the app is not free Consumer Protection Law - applicable (and different) everywhere There might be more, but these are the important ones I am aware of.
The goal of the GDPR is to ensure a single market for personal data processing throughout the EU. Since all EU/EEA member states now have equivalent levels of data protection, it doesn't matter in which member state data is stored or processed. Member states cannot generally limit this single market via national laws. Furthermore, secure processing may be possible outside of the EU/EEA as discussed in Chapter 5 of the GDPR. Some countries such as Japan have been asserted an adequate level of data protection so that no special safety measures are necessary. For other countries, a transfer of personal data may be possible under so-called Standard Contractual Clauses which detail the responsibilities of the data exporter/importer. However, the recent Schrems II ruling has invalidated the (partial) adequacy decision for the United States, and has strongly hinted that SCCs only work if the parties are actually able to honor their responsibilities under the SCC (which is not the case with some surveillance laws). Data protection is likely not ensured for processing in the US or by US-controlled companies (even if the processing usually takes place within the EU). Given the sensitivity of health data, this means you should likely avoid using the typical public cloud providers (regardless of availability region). Depending on where your company is based, you might also be disqualified as a data processor by EU data controllers. So the GDPR has no data residency requirements that limit the processing/storage to Germany, but some data residency requirements to keep the data in the EU. However, there may be non-GDPR obligations that mandate how the data can be processed, but I'm not familiar with those (the German regulatory landscape for tele-health is very uneven, differs between German states, but is also improving a lot recently). Since you're processing health data, you should pay special attention to Art 9(3) GDPR which is expanded in German law by §22 BDSG to list a catalogue of possible safety measures you should consider, but none of them are related to data residency. §78 BDSG has further details on transfers into non-EU countries, such as emphasizing that human rights must be guaranteed in the target country.
The conditions for lawfulness of processing are spelled out in Article 6 of the GDPR. As for it being legal for website operators to log the IP-addresses of visitors, this is covered by the following paragraph (also pointed out by phoog in a comment). The paragraph says it is legal to process personal data if 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. (my emphasis) You are not the only web site that logs IP addresses for the purpose of security. Every web site I've ever worked on - from those controlled by large corporations to tiny NGOs - do this. This security practice will not be impacted by the GDPR (if it were, I am sure we would have heard about it by now). there is the EU cookie law too If your website are going to be accessible to European citizens and not only accessible by your friends and familiy, you have to comply with the EU cookie directive of 2002 (a exemption for "personal websites" does not exist).
The consent presented in the question is a text-book example on how to not secure consent under the GDPR. The GDPR requires concent to be explicit, specific, freely given, and informed. This particular privacy policy does not measure up to any of these requirements. The GDPR goes to great lengths to regulate consent. For instance, in Article 7 (2) is says: Any part of such a declaration [of consent] which constitutes an infringement of this Regulation shall not be binding. So if the consent obtained is not explicit, specific, freely given, and informed, and the company relies on consent to ensure lawfulness of processing, it is breaking the law (and may be fined under the GDPR). The big problem with this privacy policy is this sentence: Your continued access to or use of any of the Services shall be deemed your acceptance of the Privacy Policy. As you've noted, the GDPR requires consent to be explicit. What "explicit" means is spelled out in Recital 32, which (among other things) says: Silence, pre-ticked boxes or inactivity should not therefore constitute consent. And Recital 32 goes on state that consent must be specific: When the processing has multiple purposes, consent should be given for all of them. The full privacy policy lists 16 different purposes for which personal data is collected, but do not seek specific consent for any of them. Consent under GDPR must also be freely given. Recital 42 says (among other things): Consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse or withdraw consent without detriment. Here the company states that continued use of the service "shall be deemed your acceptance". The only way the data subject can refuse consent is to not use the service, which is to the detriment of the data subject. This also makes the consent invalid. Finally, the GDPR also requires consent to be informed. What this means is spelled out in Recital 42, which (among other things say): For consent to be informed, the data subject should be aware at least [...] the purposes of the processing for which the personal data are intended. Here the data subject is supposed to consent to some unknown, future change which may be to allow different purposes of the processing. This also invalidates the consent.