We will treat the most common questions about consent management and its minimal requirements stated by privacy laws, jurisprudence, and the guidelines from national DPA’s. We will treat three different possibilities.
Table of Contents
To summarize, the minimal approach described by privacy laws is consent per purpose or category. Please keep reading to know how we will give you the option to ask consent per service and why consent per cookie is technically impossible.
Consent per Category or Purpose
According to the ePrivacy Directive, consent should be asked for non-functional cookies. It does not prescribe how that should be done. So for any clarification about this topic, we need to look at the GDPR, the jurisprudence, and the guidelines from national DPA’s.
GDPR
Article 6(1)(a) GDPR confirms that the consent of the data subject must be given in relation to “one or more specific” purposes and that a data subject has a choice in relation to each of them.
Recital 43 says separate consent will be needed for different processing operations wherever appropriate – so you need to give granular options to consent separately to separate purposes unless this would be unduly disruptive or confusing. And in every case, a consent request must specifically cover all purposes for which you seek consent.
DPA’s
The European Data Protection Board (EDPB) consists of representatives from the data protection authorities of each EU member state. It adopts guidelines for complying with the requirements of the GDPR.
Source: Guidelines 05/2020 on consent under Regulation 2016/679 | European Data Protection Board
On page 12 they explain granularity:
If the controller has conflated several purposes for processing and has not attempted to seek separate consent for each purpose, there is a lack of freedom. This granularity is closely related to the need of consent to be specific, as discussed in section 3.2 further below. When data processing is done in pursuit of several purposes, the solution to comply with the conditions for valid consent lies in granularity, i.e. the separation of these purposes and obtaining consent for each purpose.
and on page 14 they make it clear that consent for one purpose may cover different operations:
If the controller is relying on Article 6(1)(a), data subjects must always give consent for a specific processing purpose. In line with the concept of purpose limitation, Article 5(1)(b) and recital 32, consent may cover different operations, as long as these operations serve the same purpose. It goes without saying that specific consent can only be obtained when data subjects are specifically informed about the intended purposes of data use concerning them.
For example, this means that one can ask consent for the purpose of statistics and that this covers the services and the cookies that serve that purpose.
And also:
Consent mechanisms must not only be granular to meet the requirement of ‘free’, but also to meet the element of ‘specific’. This means a controller that seeks consent for various different purposes should provide a separate opt-in for each purpose, to allow users to give specific consent for specific purposes.
United Kingdom
The ICO states on their website that you need to ask consent to separate purposes.
Source: What is valid consent?
France
In September 2020 the French DPA CNIL states that consent should be asked for each independent Purpose category.
Source: https://www.cnil.fr/sites/default/files/atoms/files/recommandation-cookies-et-autres-traceurs.pdf
Spain
To determine just how granular the cookie consent options need to be, is up to website publishers. As a minimum, the AEPD explained that users should be able to exercise their consent choices in relation to cookies split into groups according to the purpose they serve.
Consent per Service
Although minimal requirements state that consent per purpose or category is needed for granular consent, granular consent per service will be available in Complianz from 6.1 onward.
Obviously, consent per service is a more granular approach than consent per category. Besides the legal requirements, there are guidelines for obtaining consent we like to follow and conform with for our clients, and website visitors as well.
The guidelines state that obtaining or revoking, consent should be as easy and clear as possible, without delay or using design elements that might confuse your website visitor about its purpose.
For us, this meant complicating the banner and cookie policy with more granular consent options would create situations whereby asking consent between list A or B, would confuse visitors who are not knowledgeable about the specific services.
A
- Functional
- Statistics
- Marketing
B
- PayPal
- Matomo
- HubSpot
Why we will add consent per service
From 6.1 onward, we will support consent per service. The reason is two-fold; popular demand by our users and a unique feature to support consent per service.
We only add features if it serves our clients and their website visitors positively. In this case, we will also introduce our CookieShredder. In combination with consent per service, this new granular approach can add privacy benefits for your users.
The CookieShredder is a unique feature for Consent Management that will remove all cookies, real-time based on your user’s consent level. For example:
In the future your website visitor will be able to consent on reCAPTCHA while using a form. After completing the form they can choose to revoke and remove the used cookies immediately and continue using your website without delay.
Consent per Cookie
We sporadically get feature requests for Consent per Cookie. We’d like to explain how our CookieShredder and Consent per Service is the closest we can get technically to granularly controlling cookies and blocking and releasing individual cookies.
A user-unfriendly example
The first question will always be; does it benefit your website visitors. And in the case of granular consent per cookie, there’s no clear reason why this would matter to your users. Besides the technical jargon, list of exhaustive cookie information to work through to make an informed decision. Why would a website visitor choose one cookie over another specific to one service? We don’t know.
A technical example
When a YouTube video is embedded on a webpage. The video is loaded from youtube.com, by inserting an iFrame (or any other way of loading external resources).
This external resource, when loaded, will set 3 cookies on youtube.com based on interaction. It will remember when the video is loaded, the start time, your userID, etc.
For security reasons alone we cannot manipulate cookies on third-party domains, nor do we know exactly for each interaction when or why a cookie might be set, or if there are dependencies and so forth.
This is why we choose to block the service entirely, which blocks the cookies as a result. Controlling cookies is technically impossible.
Revoking per Cookie
What we can do is remove cookies in real-time. Maybe your website visitor chose to enable a service that sets cookies on your domain, he will also be able to remove these cookies after an interaction. This is possible with the CookieShredder combined with consent per service, as explained above. Removing cookies, as controlling cookies on third-party domains will not be possible.
