The General Data Protection Regulation is a strong privacy and data protection framework. One of the most important and large changes are the concepts of consent. GDPR increases the bar for consent management. I would not say that GDPR puts the consent requirements “high”, but the requirements are certainly higher than previously. GDPR consent must be specific, informed and unambiguous - and there must be an understanding that the user understands what he is opting in. GDPR consent is opt-in.
One of the important issues facing organisations is establishing whether the current consent practices are up to date and in line with GDPR. For many of them, this is not the case. The transition period to the GDPR-level will be interesting. If organisations find themselves currently processing data based on non-compliant consent frameworks, consent will need to be refreshed.
And with GDPR, consent needs to be well designed.
What is consent?
Consent is in principle a mechanism of building trust between the user and an organisation.
Consent is a component of information management. It is a formal tool allowing to process (collect, store, use, etc.) user data. For users, requirement of consent offers choice. Users have the ability to express their preference: allow the processing of their data, or not. In practice, to date, users have little choice. Organisations had no motivation for improvement in this respect. With GDPR, this will gradually change.
UK’s Information Commissioner’s Office (ICO) is one of the more vibrant european Data Protection Authorities. What they say about consent in regards to GDPR should be listened to carefully by organisations in Europe and beyond (if their business concerns people based in Europe). ICO has just released their guidelines on consent, and they are very interesting.
I provide an analysis.
GDPR consent
GDPR views consent as “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“.
Users must be made aware of the consequences of their decision and how their data is or will be used. Consent needs to be granular. This means that different types of consent are possible for performing different tasks if data can be or is used in a number of distinct ways. This supports the notion of purpose limitation as well as (partly) data minimization. This requirement is also meant to reduce the risk of secondary use of data, where data collected for one original purpose is later used for other unrelated purposes.
For example, if data is used to measure the traffic or to detect cyberfraud or cyberintrusion, but is later used also to profile users for other purposes - without their knowledge, awareness or choice.
Consent cannot be included in those lengthy Terms of Service. GDPR will also disallow any suggestions for making consent-related decisions. You can’t tick the “I agree box” for users. Organisations obviously cannot assume that consent is given implicitly.
Consent should not be treated as a paperwork scheme “making life hard”. It actually can increase user trust and confidence. Let’s be honest, would you trust someone who wants to use your data without your awareness or choice? Or someone who has difficulties explaining how they got your data? In this case, consent frameworks actually build trust on a scale of entire economies.
Having good consent management system is also a risk-reducing facility, as organisations processing data without consent are risking reputational damage or the full GDPR-level fines: 20,000,000 EUR or 4% total world annual turnover, whichever would be higher.
Consent is not always needed
Consent is not the only basis for using data, as ICO points out. It is only one possible data processing basis. In some cases, consent may be inappropriate.
Other options justifying the processing of data is following scenarios:
- contractual agreement with an individual in place
- lawful requirement allows processing (if law requires organisation to process user data)
- life-threatening events justify processing, human life protection , health, etc.
- using data when there is another legal framework, for example in public interest by a public body (we’re speaking UK law here!)
- “Legitimate interest”. Using data for “legitimate reason” if it not exceeds harm to users
In many cases, the options listed above do not apply. In those other cases consent is typically required. Important note: don’t misunderstand GDPR consent for ePrivacy consent (often known as the “cookie law”). In this sense, consent may result from different regulations; the ICO guidelines are devoted to GDPR.
As a side note, the final version of the future ePrivacy regulation is not yet known, so there is a good share of uncertainty in the region of consent. I would advise extra care at least within the next two years. Consent area is just very active. **It is very wise for ICO not to provide any guidance related to ePrivacy at this point. **
Do not ask for consent if you process the data anyway
Consent should not be asked for if data is to be processed anyway based on other lawful basis. In this case asking for consent would be misleading and will just create an impression that “there is no choice”. Because in that case - there is not. GDPR definitely defines situations where users have no choice. Organisations should not seek consent in these kind of cases.
Valid consent
Now the most interesting part. What makes consent valid? The rationale here is using consent where it is not needed or actually impossible (e.g. when data processing happens anyway) deteriorates the concept of “choice” and “consent”.
Freely given
Users must have an actual choice.
ICO identifies an important point, if an organisation includes consent as a precondition to access services, this should not be treated as consent. In the realm of GDPR, consent cannot be a precondition to use services. The same situation applies if there is a power imbalance, for example the organisation is in position of power such as being the employer of a user. In this case, GDPR treats this situation as invalid for consent.
ICO hints at specific risk of collecting consent where there is really no choice. In these cases, different data processing basis should be seeked.
This is important because if organisation will base processing on invalid consent, data would be processed unlawfully (and could result in GDPR-level fines).
Specific
Consent should be specific to the actual purposes for which the data will be used. It is much better to offer consent choices for a number of ways data is or may be used, rather than to provide one catch-all “I accept and agree” tick box. But if this is the way consent is asked, it should cover all the processing activities in a clear way. This is the minimum. So the best possible way would be to list the different data use purposes, and the different processing activities.
Withdrawable
There should be an option to withdraw the consent from some or all data processing activities. Subsequently after withdrawing consent - processing should stop as soon as possible - if there is no other basis to continue. In some cases, this would also require removing some or all data relating to the user who has withdrawn the consent. In this sense, consent is an important element of the principle of the right to be forgotten. Important note to organisations: you need to inform users about the option of consent withdrawal, and where relevant - specify how this is possible.
Consent can be withdrawn at any point, at user discretion. This process should be simple - from the user point of view. ICO suggests that withdrawal should be made possible over the same channel used to grant consent. Then if it’s given via website - withdrawal should also be via website. ICO also suggests that (during compliance verification) it may be a good idea to be able to demonstrate that consent is as easy to withdraw as it was to give.
Clear and simple
It should be clear to users in what ways and what kind of their data will be used in practice. This should be concise, so it’s better to forget about 20 page consent agreements.
ICO highlights that if we’re speaking about electronic consent means - like, on a website or in a smartphone app, consent should be concise and well-tailored. This is a user experience issue.
Time limited
Consent should be time limited, taking into account the details of processing. This is specific to the type of processing and is very important, as it defines the frequency of consent refreshing.
When the types or extents of data processing might change, this change should be explained to users. In some cases consent may need to be refreshed. It’s not possible that consent is valid for all future uses of data. There is no concept of an evolving consent.
Reading consent form is not enough
It must be easy see what the individual has consented to. What’s more, there must be an understanding that the individual actually agree with the consent details. GDPR consent requires clear affirmative action. GDPR consent is opt-in consent. Users must make an action in order to treat it as a valid consent. So the understanding here is that, for example merely displaying information about the default settings is not enough.
Adult provision
GDPR enforces stricter consent requirements for children. In the UK, children under 16 years of age (UK might decide to change this to 13 years old) cannot express consent to data processing. As such, the consent would be invalid.
This is important because in such cases age-verifications systems must be in place.
This is quite complicated, so it’s best to assume that if you are not absolutely sure you’re doing it right - the way you process consent is invalid. Just to be on the safe side.
Collection, storage
As previously noted, consent should be made separate from other general terms of service. This is reasonable since consent management is so important, it is just easier to manage a specific type of data. Consent forms should be clear to understand and they should include what is the reason of data processing (purpose) and how the data will be used (processing activities).
ICO makes a very interesting observation that is worth to cite in verbatim:
“There is a tension between ensuring that consent is specific enough and making it concise and easy to understand. In practice this means you may not be able to get blanket consent for a large number of parties, purposes or processes. This is because you won’t be able to provide prominent, concise and readable information that is also specific and granular enough.”
Sounds reasonable. Requirements of “concise and simple” just contradict with “blanket-consent”.
ICO also suggests to use just-in-time notices. Asking for consent when at the time the date is actually requested (and when the person is e.g. typing them). Apple's iOS permissions work in a similar manner - a permission prompt appears when an application wants to, say, access your photos. This is also considered a good consent design choice.
I am also citing in verbatim the examples of consent mechanisms that ICO identifies:
- signing a consent statement on a paper form
- ticking an opt-in box on paper or electronically
- clicking an opt-in button or link online
- selecting from equally prominent yes/no options
- choosing technical settings or preference dashboard settings
- responding to an email requesting consent
- answering yes to a clear oral consent request
- volunteering optional information for a specific purpose – e.g. filling optional fields in a form (combined with just-in-time notices) or dropping a business card into a box.
Each is good for specific occasions. Electronically - buttons, links and settings are examples of the most relevant ones. It is well worth to remember that ePrivacy regulation will add additional consent requirements for specific types of data use.
But GDPR bans opt-out consent mechanisms. In other words, you cannot implicitly assume that a consent is granted.
Consent recording
Organisations must be able to prove that consent has been given. This is a transparency requirement. Organisations need to be able to prove that they indeed have the right to process user data. This is a concept of audit trail, in line with accountability and transparency principles.
This requirement means that in practice, organisations need to deploy consent management systems. In this way, it is possible to quickly verify which user has consented to which kind of data processing activities, when was the consent given (important for consent refresh), what they actually consented to (i.e. the consent form and its contents could have been amended since then!), and the actual way the consent has been granted (was it oral? Written down? Electronic?), etc.
ICO is even providing examples:
- Bad: keeping a spreadsheet with a user-record field of “consent granted”
- Good: keep the consent form and proof
In the previous example, the “spreadsheet technique” may indicate that a consent has been given, but organisation still must be able to prove that the consent has actually been given.
In case of online consents, one possible way to go is to generate a PDF file with the consent text and proof of user action - and to store it.
This example from ICO guidelines is actually a bit bogus:
“For online consent, you may be able to use an appropriate cryptographic hash function to support data integrity. “
ICO is not providing any details here, but I guess they are speaking about proving that consent has been granted on a particular date/time.
Sure, I guess you can also use bitcoin as means of smart contract mechanisms to prove that a consent has been granted.
Summary
GDPR makes consent very strict. Organisations might view this as an additional burden. But in reality it will allow to establish consent as one of the trust factors connecting users and organisations offering services.
The way consent management is used in practice is a question of deployments. There are already some contending consent management systems, although at this point I am not recommending any specific product. The fact that ICO is not recognising the existence of commercial consent management systems is also telling.