Should registered users accept cookie consent in GDPR? I want to use cookie consent for saving user language, currency and affiliate marketing purpose. Can I store data without consent of the registered users? They are registered so do I need to take consent from them.
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.
Your title is not necessarily consistent with your example. Can a website demand acceptance of non-essential cookies to allow access? As you have found, GDPR prohibits conditioning the provision of service on consent to the processing of personal data. Cookie walls without alternative means of access are generally considered violations of the GDPR. Can a website demand acceptance of non-essential cookies to allow free access? The situation of a &quot;consent or pay&quot; scheme (or &quot;cookie paywalls&quot;) is more uncertain and has not been clearly settled at the EU level. There are data protection authorities that do not consider such scheme necessarily a GDPR violation (Austria, France) if a reasonable alternative access, without requiring non-essential cookies, is provided. For what it is worth, the French data protection authority (CNIL) held initially that all cookie walls are illegal, but on appeal from publishers and advertisers, the French supreme administrative court annulled CNIL's initial guidelines for being too absolute. German and Italian authorities are still examining the validity of such scheme. More reading: Consent or Pay: Privacy Considerations with Cookiewall-Paywall Hybrid Solution, https://securiti.ai/blog/cookie-paywall/ Is the use of a cookie wall allowed in European Countries, https://www.iubenda.com/en/help/24487-cookie-walls-gdpr
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.
GDPR does not require consent. It requires a legal basis. Consent is only one legal basis among many. Some other legal bases are: legitimate interest (implying an opt out solution) necessity for performance of a contract If your customers pay you to deliver email updates, that contract is the legal basis for sending email updates. The only wrinkle is that as you describe your service, the emails aren't an essential part of the service. Alternatively, you might assert that there's a legitimate interest to deliver updates via email so that updates aren't missed. In that case you must allow the users to object, e.g. via ab unsubscribe link in the email and via their account settings. Because a prior business relationship exists, there's a strong case for legitimate interest – even if this were marketing emails (!). Legitimate interest requires you to balance the legitimate interest with the data subject's rights and freedoms though. Your updates are most likely not marketing, so any advice you might read relating to marketing emailings is irrelevant. GDPR applies because you are established in the EU. The regulation applies in relation to all your users, not just EU users. If and when Brexit happens you will still be covered by the Data Protection Act, which transcribes the GDPR's requirements into UK law. However, processing data from EU users will then count as an international transfer which requires extra compliance work, at least until the EU issues an adequacy decision for the UK.
The GDPR does not prescribe how exactly consent must be managed, as long as consent was obtained in line with the GDPR's principles. Similarly, the EDPB does not provide concrete recommendations in its guidelines on consent, mainly noting that Controllers are free to develop methods to comply with this provision in a way that is fitting in their daily operations. I would not be too concerned with edge cases like failing HTTP requests, at least not any more than for other HTTP endpoints. If the user indicated consent, and you act on that indication of consent in good faith, that's probably fine. However, remember that you must provide a equally easy way for the user to revoke consent later. If the user changes their mind, they can use the mechanism that you offer to inspect their consent status, and revoke it if they want. But again, how to do that is largely up to you.
You are missing something. The fact that you have a tick box and its state is saved in the database is enough. The burden of proof is only "on a balance of probabilities", so someone arguing that they didn't consent would have to demonstrate that you falsified the database entry somehow. In terms of GDPR requirements in general you don't need a greater level of proof than this, the key thing is that you have a robust system in place to obtain proof (such as not allowing data into the database without a tick in the box).
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”.
First take a look at Article 13(1) of Directive 2002/58/EC Article 13 Unsolicited communications The use of automated calling systems without human intervention (automatic calling machines), facsimile machines (fax) or electronic mail for the purposes of direct marketing may only be allowed in respect of subscribers who have given their prior consent. Notwithstanding paragraph 1, where a natural or legal person obtains from its customers their electronic contact details for electronic mail, in the context of the sale of a product or a service, in accordance with Directive 95/46/EC, the same natural or legal person may use these electronic contact details for direct marketing of its own similar products or services provided that customers clearly and distinctly are given the opportunity to object, free of charge and in an easy manner, to such use of electronic contact details when they are collected and on the occasion of each message in case the customer has not initially refused such use. Note that this is a Directive, so it is not directly binding, but each EU member state has created it's own laws containing this. I also quoted paragraph 2 for completeness, but based on your description, it does not apply. Article 95 GDPR explicitly specifies it does not change any obligations from Directive 2002/58/EC. So it looks very clear to me the situation you describe is not legal. Article 14 GDPR allows you to request all information regarding this, which included information how they have exactly obtained your name and email address.