GDPR: How to obtain consent?

Picture of closrr_admn

closrr_admn

Within the GDPR, consent constitutes one of six possible legal grounds for lawful personal data processing under Article 6(1). For most commercial controllers and processors, however, it likely represents the principal option.

(All emphasis to GDPR text are added unless otherwise specified)

Article 4 defines consent as follows:

‘consent’ of the data subject means 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;

Recital 32 further specifies:

Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject’s agreement to the processing of personal data relating to him or her, such as by a written statement, including by electronic means, or an oral statement. This could include ticking a box when visiting an internet website, choosing technical settings for information society services or another statement or conduct which clearly indicates in this context the data subject’s acceptance of the proposed processing of his or her personal data. Silence, pre-ticked boxes or inactivity should not therefore constitute consent. Consent should cover all processing activities carried out for the same purpose or purposes. When the processing has multiple purposes, consent should be given for all of them. If the data subject’s consent is to be given following a request by electronic means, the request must be clear, concise and not unnecessarily disruptive to the use of the service for which it is provided.

So let’s look at the requirements for consent:

  1. Freely given
  2. Specific, Informed, and Unambiguous
  3. Clear affirmative [action]

Freely given

From Recital 42:

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.

Recital 43:

In order to ensure that consent is freely given, consent should not provide a valid legal ground for the processing of personal data in a specific case where there is a clear imbalance between the data subject and the controller, in particular where the controller is a public authority and it is therefore unlikely that consent was freely given in all the circumstances of that specific situation. Consent is presumed not to be freely given if it does not allow separate consent to be given to different personal data processing operations despite it being appropriate in the individual case, or if the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance.

Article 7:

4. When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract.

For consent to be considered freely given, therefore, it must be truly optional for the data subject. If data controllers withhold or offer a degraded version of service for subjects who refuse or later withdraw consent, such consent would not be valid.

Let’s look at an example. A news site restricts its premium content to those who register for a free account. During account registration, the site provides a checkbox for visitors to permit sharing their personal data (including email address and browsing habits) with the site’s advertising partners. Two scenarios:

  1. Checking vs. not checking the said box results in identical user experience. The news site pitches checking the box as a way for the user to help support premium content, but provides the same content to users who choose to not consent to personal data processing. This should qualify said consent as “freely given”.
  2. Not checking the box renders the premium content inaccessible or limited to the user. As this can be interpreted as a detriment to the end user, consent would not be considered “freely given”.

This is not to suggest that the GDPR categorically bans services that depend on the processing of personal data for a large majority of their users to operate. In our news site example, the controller may still be able to justify lawfully processing of its users’ personal data while placing premium content behind a “personal data paywall”, but the legal ground for doing so would no longer be consent, but one of the other five conditions as outlined in Article 6 (1). Our expectation is that this would most likely fall under legitimate interests in subparagraph (f). We discuss legitimate interests at greater depth here.

Specific, Informed, and Unambiguous

These requirements collectively prevent controllers from using generic and confusing legalese to obtain consent for broad data processing capability. Recital 39 states:

39. Any processing of personal data should be lawful and fair. It should be transparent to natural persons that personal data concerning them are collected, used, consulted or otherwise processed and to what extent the personal data are or will be processed. The principle of transparency requires that any information and communication relating to the processing of those personal data be easily accessible and easy to understand, and that clear and plain language be used. That principle concerns, in particular, information to the data subjects on the identity of the controller and the purposes of the processing and further information to ensure fair and transparent processing in respect of the natural persons concerned and their right to obtain confirmation and communication of personal data concerning them which are being processed. Natural persons should be made aware of risks, rules, safeguards and rights in relation to the processing of personal data and how to exercise their rights in relation to such processing. In particular, the specific purposes for which personal data are processed should be explicit and legitimate and determined at the time of the collection of the personal data. The personal data should be adequate, relevant and limited to what is necessary for the purposes for which they are processed. This requires, in particular, ensuring that the period for which the personal data are stored is limited to a strict minimum. Personal data should be processed only if the purpose of the processing could not reasonably be fulfilled by other means. In order to ensure that the personal data are not kept longer than necessary, time limits should be established by the controller for erasure or for a periodic review. Every reasonable step should be taken to ensure that personal data which are inaccurate are rectified or deleted. Personal data should be processed in a manner that ensures appropriate security and confidentiality of the personal data, including for preventing unauthorised access to or use of personal data and the equipment used for the processing.

In plainer text, then, controllers will no longer be able to hide data processing behind generic statements like “we may process your personal data to improve our services”. Instead, in order for consent to be deemed valid, controllers must clearly spell out, inter alia:

  1. What type of personal data will be processed? (is it name, email, address, and/or browsing behavior?)
  2. Why are such data processed? (to remember your preferred language choice, to show you more targeted ads, to check for fraud, to share with our partners who will then sell you their services?)
  3. ho will be processing the data? (identity of the controller, processor, and any third party partners and contractors)
  4. When will processing take place? (including data expiration date)

Clear Affirmative [Action]

Recital 32 states that “Silence, pre-ticked boxes or inactivity should not therefore constitute consent.” This essentially states that consent must be opt-in, instead of opt-out. Websites will therefore no longer be able to rely on a small banner stating “We use cookies. By continuing to use the site, you indicate you agree to our terms.” with only a “dismiss” button or “ok” link to collect consent from site visitors. So how should controllers ensure they are in compliance? Let’s revisit Recital 32’s affirmative examples:

This could include ticking a box when visiting an internet website, choosing technical settings for information society services or another statement or conduct which clearly indicates in this context the data subject’s acceptance of the proposed processing of his or her personal data.

So a voluntary checking of an unchecked box would be deemed sufficient; so would a user who visits the settings page of an app or site and indicate that they provide permission. The ambiguity, however, comes to what “statement or conduct” would be clear enough to indicate the data subject’s acceptance.

We will post relevant official commentary on this as we encounter them. Meanwhile, below is one possible approach to web cookies that we believe may pass the threshold to “clearly indicate” acceptance, while ensuring consent collection is not so onerous that few would bother providing it.

Web cookies

Instead of a small text banner on the side that can easily be ignored or overlooked, implement a gated popup upon site visit that highlights the permissions that you seek, with a link to a detailed page for users to learn more. Before the user is able to interact with the site content, he or she would be required to take one of three possible actions on this gated popup:

  1. Click “Accept”. This dismisses the popup, and constitutes consent for the controller.
  2. Click “Visit settings to decline”. This dismisses the popup, and opens up a new window to a technical settings page for data subjects to decline or revoke previously granted consent.
  3. Click “x” to dismiss the popup. This lets the user to access the web content, but does not in itself grant the controller consent. The website must wait for the user to click accept on a future site visit before processing his or her personal data.

 Additional requirements

Article 7(3) states that:

3. The data subject shall have the right to withdraw his or her consent at any time. The withdrawal of consent shall not affect the lawfulness of processing based on consent before its withdrawal. Prior to giving consent, the data subject shall be informed thereof. It shall be as easy to withdraw as to give consent.

To ensure compliance on the last part, where giving consent should be as simple as withdrawing it, we recommend following emerging industry best practices. Until such best practices emerge as GDPR goes live, we suggest integrating the technical settings for withdrawing consent as part of your “privacy policy” page, which permits data subjects to go to the same place to understand and manage

Expert help, at your service

If you find all this overwhelming and don’t know where to start to address your GDPR compliance solution, we can help. Once you are ready to go, we’ll help you get up in running in days, so you don’t have to integrate a bunch of security compliance software tools or hire more people.

Note: I am not a lawyer, not even an aspiring lawyer. This blog does not constitute legal advice, only my interpretation and summary of certain requirements of the GDPR. Readers are encouraged to obtain legal advice from a qualified professional in respect to their organization’s obligations.

Share it if you think this is interesting

Facebook
Twitter
LinkedIn
WhatsApp
Email

Related articles