Skip to main content
Insight

The nuance of "accepting" vs. "reading" a privacy policy

Phil Lee
12/09/2016
Almost every website under the sun uses the words "I accept the privacy policy" somewhere on their website. But using these words may carry unforeseen - and unintended - consequences for the business under the GDPR. So what should you do instead? Read this post to find out.

5 simple words: “I accept the privacy policy”.  Normally displayed at the bottom of a website registration form, immediately above or below the submit button, with the underlined words linking off to the privacy policy.  There might even be a tick box next to these words for the user to indicate, affirmatively, that he or she does indeed agree to the privacy policy.  What could possibly be more harmless?

For many businesses, sticking this kind of consent language on a web page is a no-brainer.  It allows them, they think, to demonstrate that the users who chose to register with their website agreed to their privacy policy and all of its contents - and no one’s going to criticise them for getting consents from their registrants, right?   Sure, some privacy professionals say that consents collected this way might not be valid, on the basis that no one ever reads a privacy policy and so users can never meaningfully consent to its contents,  But to many this criticism seems theoretical at best - after all, how many businesses have ever been taken to task by regulatory authorities for using such an approach? 

Consequently, this style of privacy policy “consent” remains pervasive around the web but, looking forward to the GDPR, businesses may be well-advised to think again.  Under the GDPR, the very notion of consent - and its consequences - has been considerably strengthened.  Businesses who rely on consent as the legal basis for their processing under the GDPR may therefore find themselves attracting additional compliance hurdles they weren’t expecting.

To highlight a few examples:

  • Consent must be auditable:  The GDPR says that any business relying on consent must “be able to demonstrate that the data subject has consented to processing of his or her data”.  The most obvious way to demonstrate a user’s consent is to keep a record of their consent, but this may require re-engineering back-end systems to make sure they accurately record this consent.  It’s not just a matter of recording a simple “yes” or “no” either: from a practical perspective, the business will also need to know which version of the privacy policy the user consented to so that the scope of their consent (and hence what the business can and can’t do with the data) can be validated.
  • Deletion requirements are strengthened with consent:  The GDPR says that it must be as easy for individuals to withdraw consent as it is to give it.  Consent, once withdrawn, has the consequence under the GDPR of triggering the right to erasure (aka the “right to be forgotten”) - meaning, essentially, that the business has to erase the user’s data once they withdraw consent.  That in itself may not sound so bad, but there may be many legitimate reasons why a business needs to retain user data even after the user has withdrawn consent - for example, to retain a record of user transactions for accounting purposes.  To be fair, the GDPR does say that the data has to be deleted only “where there is no other legal ground for the processing” - but, if such another ground does in fact exist, doesn’t that suggest the processing was never really consent-based anyway?
  • Consent triggers data portability rules:  If users consent to use of their data, then they are also entitled to a right of “data portability” under the GDPR - meaning that the business must provide them with the ability to extract their data from its service “in a structured, commonly used and machine-readable format”. Further, the business may also have to help the user transfer that data to another third party business.  Again, this may require some engineering effort and, inevitably, some businesses will have concerns about helping their user base to migrate data to competitor platforms.
  • Privacy policy consents are even less likely to be valid than before:  While the above type of privacy policy consent may have questionable validity under the Directive, it comes under even greater challenge under the GDPR.  In addition to requiring that consents must be “unambiguous”, the GDPR also says that “Consent is presumed not to be freely given … 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” (emphasis added).  This means that online service providers who rely on user consent now face even greater risk that their consents are invalid.  In addition, they face greater consequences given the significantly enhanced enforcement powers that exist under the GDPR.

Of course, in certain cases consent may be entirely appropriate once the context, nature and purpose of the data processing has been taken into account.  The point of this post is not to criticise consent, but rather to encourage businesses not to default to consent without understanding its consequences and considering the alternatives.  After all, the GDPR provides five alternative (non-consent-based) grounds for allowing businesses to lawfully collect and use data, and some of these may carry less of a compliance overhead - for example, businesses that process data on the basis of their “legitimate interests” are not compelled to fulfil data portability requirements. 

For those businesses that choose not to rely on consent under the GDPR, the language linking to their privacy policy will need to change from “I accept the privacy policy” to “I have read the privacy policy” (or similar).  A very simple change - but one that could make a world of difference to an organisation’s responsibilities and risks under the GDPR.  Choose your words - and your data processing strategy - carefully!

Sign up to our email digest

Click to subscribe or manage your email preferences.

SUBSCRIBE