Websites, mobile apps, IoT devices, smartphones and just about any other products, systems or processes will, in a majority of cases, might soon need to redesign and re-engineer how user consent is being processed. Why? Because of the European General Data Protection Regulation.
The GDPR makes consent a bit closer to being a genuine consent which is great for users. But this regulation also means a lot of challenges and new requirements for business and institutions.
I’m well aware of struggles and numerous adaptation campaigns in several European countries due to GDPR, and it’s fair to say consent is one of the most frequent points of challenges.
Fortunately, there are now (somewhat official) Guidelines on consent (I previously wrote about ICO’s point of view here). As with many other Guidelines, they are rather general and actually analyzing and implementing them requires careful consideration of particular use cases. In this post, I provide a critical analysis. You can find the raw guidelines document here.
I’m highlighting a starting point at the beginning.
It is organization’s responsibility to prove that the collected user consents are valid. This is a fair starting point. If an organization cannot prove that consent is valid, this is a good indication that consent re-collection is needed. In practice, expect some organizations doing so anyway, just to be on the safe side. So yes, some pre-GDPR consents will be invalidated after GDPR comes into force.
Some early advice:
- Look at how consent is processed in your organization. Is the process in-line with GDPR? If no, consents must be recollected
- There’s no consent process in your organization? Chances are you aren’t meeting the previous point
- You process based on consent but you don’t have consents? Seems you don’t have any process in your organization at all. Build it. Recollect consents. In this order.
- How to design consent messages/prompts, and how to make sure the user has understood what it all means - this is a matter of consent engineering
What makes consent a consent
In order to understand when consent is valid, a number of requirements must be met.
Freely given
Users cannot be forced to provide consent. It is up to the user to make the choice. Consent cannot be the sole prerequisite to enter into an agreement. Otherwise, consent is not valid. There is no way to, e.g., bundle a number of services into a package and simply provide an “I agree” tick-box.
A Tamagotchi-like cat app does not need access to all contacts in the address book in order to operate.
One of the most important tasks, in order to prepare for GDPR, will thus be a careful analysis of all contracts and systems to see if consent was a prerequisite for using these. These kind of consents may mean that organization will be processing data without any justification (if based on invalid consents) following May 2018.
Pay attention to the important concept of power imbalance. Employers cannot force employees to consent to e.g. provide consent to process their personal data for arbitrary reasons. Same for various institutions, ministries, universities, and so on. This kind of things invalidate consent.
Granularity
There are good reasons to split services into sub-services, each of these requiring specific consent - for different purposes. In this way, it is convenient to obtain particular consents for a particular data use purpose.
The best example are overly generic consent forms such as “we will use the data to improve our services” (what services, how?), or “we will use the data for scientific research” (what kinds of research?).
This point may also concern permissions to use specific components of smartphone or browsers. If you don’t need to use something, don’t.
Consent withdrawal
GDPR requires offering an option to easily withdraw consent. Users will be able to simply inform organizations that they are no longer desiring to have their data processed. Organizations must support these requests in a timely manner. Furthermore, users must be well aware of this option. There also should be no associated costs (here: not necessarily monetary) with such a user decision.
Specific
Consent for private data processing is only valid if it’s granted for particular use cases. In other words, data must be collected with a specific purpose. This is called purpose limitation. Purposes must be clearly communicated to users. This requirement is another one that supports “granular” consents.
Example? One thing this protects from is an internet service provider selling user data to third-parties in order to provide personalized services. Banks are unable to use consent as means of making users to share data with other organizations, too.
This is again a great place to speak about browsers and smartphone apps. If I allow a website to access geolocation via my browser, this means only that - no other data should be provided without my knowledge. This is when things will be complicated for e.g. web browsers.
Informed
This important point is about transparency. Users must be made aware of the purposes of data collection, how the data will be used, and so on.
Returning to the example of a website asking for a permission to use geolocation - via a web browser. But take note that Geolocation API (https://www.w3.org/TR/geolocation-API/) is not providing any way to state the purpose for which access to geolocation is needed. There are more of such issues with web browsers. Since it really seems that no current browsers support options to display purpose description when a request to access low-level sensor is made. In other words, web browsers are not currently privacy and transparency requirements of GDPR. Websites need to make their custom, non-standard workarounds. Browser prompts are not consents.
There is a lot to do about transparency engineering in general, indeed.
Minimum consent information
The minimum that a consent request should contain:
- the controller’s identity,
- the purpose of each of the processing operations
- type(s) of collected/used the existence of the
- right to withdraw consent
- whether decisions are to be made based solely on automated processing
- Transfers to third-countries? Must be specified as well
What I’m pointing out here: there are some standard requirements for consent interfaces. But that’s still very high-level.
How to actually do this?
Lots of requirements may seem intimidating at first, but how to actually deliver a consent prompt/request to users? This is the point of interest of consent engineering. There are indeed a lot of ways consent request can be constructed, and the best way to summarize this very broad concept is... Use the best way that suits your purpose and is efficient from user’s perspective. Sounds bogus and may even be disappointing? Organisations will actually need to figure out ways for efficient consent management/delivery that is fulfilling GDPR needs. This, in turn, requires some actual analytical thinking, as there are no one-size-fits-all solutions here. Unsure? Seek help.
Some points of interest
- Consent must be written in clear and concise language
- Must be easy to understand; no 50-pages of legalese buzzwords - if users don’t get it, that’s not consent
- Must be tailored to specific individuals (if this is known in advance). Don’t generally assume users are trained lawyers.
- Are you sure that the certain audience type will be your users? Adapt your consent. For example, if you’re relatively sure children will be reading those - adapt consent requests accordingly
Users must be able to clearly see “who”, “what”, “why”, “when” to understand the consequences
Unambiguous
Users must understand what is going on and that consent was not a blanket “click accept all and forget”. GDPR consent is affirmative. Forget about making users to scroll 50 pages only to click “I agree”. This is not only so ‘00, or ‘90s even. But also invalid since May 2018, too.
Organisations must also be able to prove they actually know that the user made an affirmative decision. This is a challenge. One example WP29 Guidelines linked above mention are users writing e-mails to explain the exact things they consent to. This is of course not the best way of handling consent, as it is totally unmanageable and impossible to scale. So why not record with a microphone the user’s speech when he simply says he understood what consent means? Eccentric, maybe could even work in some applications, but not exactly suited on the web.
Fortunately, organizations are free to design whatever consent management systems they wish. Still, challenges remain: how to make the consent request form to be affirmative? Require users to shake with a smartphone? Might work. One can imagine even simpler schemes, too. Pre-ticked boxes are of course out of the window, by design. However, one design quirk could be to *pre-tick “I do not consent” *- which would require the user to think some more and provide as a meaningful act. Even then it is not clear whether the user has actually read to what he is consenting to.
Lastly, there is also the question of fatigue when in need to click at uncountable number of boxes. The phenomenon of fatigue is well known in security engineering. Are you tired from constantly seeing "cookie notices" everywhere (something that the ePrivacy regulation wants to fix)? Then you get the idea. Nobody can expect users to waste their life cycles by going through custom consent forms on a daily basis. But GDPR requires organizations to be aware of this phenomenon, and address consent with this awareness.
So, one solution is to use browser settings. They’re automatic and usually standardized, this would make things easier indeed. However, current browsers are not yet well suited to mediate consent. To put it in simple terms - in practice, it doesn’t work as of 2018. I am not merely speaking about tracking preferences via the use of “Do Not Track” (which is more in-line with ePrivacy; for more information look here: 1 2). Recall the previous example that Web browsers do not currently provide ways of mediating valid consent to data such as geolocation. For example, there is no way to state the purpose via standard means.
Sooner or later, web browser vendors might need to consider reshaping some of the browser mechanisms. Perhaps even standardize some specific, broad and general consent supporting APIs. But we cannot expect this to happen during the next few years.
Demonstrating consent
GDPR puts the burden of proof on organizations - they need to be able to prove all is fine with consents; minimum requirement: that there are consent proofs at all. GDPR is not saying how exactly this should be achieved, but this must be done. Lack of clear guidance making business difficult? On the contrary, this might even be better! It’s best to leave this to organizations and allow them to find creative and innovative solutions. I would also say that consent discussion needs to be included in the data protection impact assessment (DPIA), too.
Consent management systems will often need to be used in practice. At the moment it’s often best to make a specialized one ("in-house"). Trust me, you don’t want to store all this stuff in Excel sheets, or in a directory. This is unmanageable and the added complexity might even result in not being in line with GDPR.
Consent duration
Refreshing consents is a good practice from privacy and transparency point of views. It’s a fundamental requirement. The actual refresh interval should depend on the particular use cases and the context of the used system. This interval needs to be defined and often included in the DPIA where consent is being assessed.
Consent withdrawal
Users must be able to withdraw consent. In an easy and effortless manner.
The gut rule? Consent withdrawal should be as easy as consent granting was. Use identical interfaces in both cases. So no, when users give consent using a well designed, pretty online form, you cannot require them to withdraw consent by postal mail, a phone call or a well-hidden obscure subpage.
Following consent withdrawal, all processing must stop immediately. There is no way you can process consent withdrawal for 30 days. Forget about this. This is the place where “purpose limitation” helps organizations: make sure you have the basis for using data for specific purposes. Otherwise, company loss may be bigger than it should be. Same for users.
Are consents collected prior May 2018 valid?
Yes, provided they meet all the criteria of GDPR consent. In other words: if your consents were GDPR-ready prior to GDPR entering into force in May 2018, you’re fine. Otherwise, make sure to verify this as soon as possible, or you may risk processing data without any grounds. Start with answering the following question: “can we prove we have consent to do that”? If not, consents are invalid. This would put your organizations at risk to a GDPR-level fines. You don’t want to be in this situation.
My advice: analyze all situations on a case-by-case basis.
Summary
Users must be fully aware what is happening with their data, and have full control.
GDPR will often require redesign and re-engineer how consent is handled at organizations. This will inevitably require changes to procedures, processes, systems, products, IT divisions, etc. In fact, lack of those changes may well mean that an organization is not GDPR-ready.
In practice, consent management systems will have to be developed in order to achieve a manageable and auditable system. Consent management is not only about obtaining consent data from users. It is also about storing, refreshing, easy access, and so on. Sometimes it is important to quickly find a particular proof of particular consent concerning particular users.
WP29 and ICO did not even acknowledg the existence of commercial consent management platforms. This could be very telling indeed. But indeed, a lot of organizations will probably choose to develop their internal solutions that best meet their needs.