The Definition of Consent
Although consent is a key concept in Data Protection, discussions of it often seem confused and legal interpretations inconsistent. For example the European Commission has in the past called both for a crackdown on the over-use of consent and for all processing of personal data to be based on consent! A new Opinion on the Definition of Consent from the Article 29 Working Party, probably the most authoritative body short of court cases, falls firmly into the “over-use” camp: “If it is correctly used, consent is a tool giving the data subject control over the processing of his data. If incorrectly used, the data subject’s control becomes illusory and consent constitutes an inappropriate basis for processing” (p2), and “Relying on consent may … prove to be a ‘false good solution’, simple at first glance but in reality complex and cumbersome”(p27). Fortunately consent is only one of six grounds for processing personal data that are provided by UK and European legislation: others include that processing is necessary for the performance of a contract between the parties, necessary to fulfil a legal obligation, and necessary for the legitimate interests of the data controller or a third party (see, for example, Schedule 2 of the UK Data Protection Act 1998). The Opinion aims to encourage those currently using consent as their justification to consider the possibility of “other legal grounds perhaps being more appropriate from both the controller’s and from the data subject’s perspective”.
The Working Party also suggest that in some cases a hybrid approach may be needed, with different grounds justifying different processing within the same transaction. Their example, of buying a car, is a little more complex than the federated access management situation I discussed recently. For a car purchase, some processing is necessary to create a valid contract between the parties, some (e.g. registering the new owner) is required by law, some (e.g. providing details to third parties who may service the car) takes place in the legitimate interests of those third parties, and some (e.g. collecting e-mail details for related advertising) is based on the buyer’s consent, which can be withdrawn at any time. Since each of those grounds gives the buyer different opportunities to stop processing, the distinction needs to be explained clearly to them.
To determine when consent may be the right choice, the Opinion starts from the definitions in the Data Protection Directive (95/46/EC) that, in order to be valid, consent must be “freely given, specific and informed” (p6) and that the person consenting must give an “unambiguous indication” that they have done so. Each of those requirements is then considered in turn:
- Freely-given: “Consent can only be valid if the data subject [the person whose information is being processed] is able to exercise a real choice, and there is no risk of deception, intimidation, coercion or significant negative consequences if he/she does not consent”, and the “individual data subject … is subsequently able to withdraw the consent without detriment” (p13). The Opinion notes that questions about the validity of consent may arise when the data subject is under the influence of the data controller, for example as their employee, and where refusal of consent may have financial, emotional or practical consequences (p14). Consent will not inevitably be invalid in these circumstances but using a different justification, if possible, may lead to fewer difficulties.
- Specific: “Consent must be given in relation to the different aspects of the processing, clearly identified. It includes notably which data are processed and for which purposes … There is a requirement of granularity of the consent with regard to the different elements that constitute the data processing: it cannot be held to cover ‘all the legitimate purposes’ followed by the data controller. Consent should refer to the processing that is reasonable and necessary in relation to the purpose.” (p17). Although consent does need to be obtained separately for different uses of personal data, it does not have to be sought every time the same use occurs: “It should be sufficient in principle for data controllers to obtain consent only once for different operations if they fall within the reasonable expectations of the data subject” (p17).
- Informed: Informing the user is a requirement of most of the purposes of processing, not just consent, however the above requirement that consent be specific clearly means that valid consent is impossible unless appropriate information is provided. The information must be “clear and sufficiently conspicuous so that users cannot overlook it” (p35) and presented in a form appropriate to the context (dense legalese is unlikely to be considered clear). As with the UK Information Commissioner’s Good Practice Guide on Privacy Notices, layered notices are suggested for the on-line environment so the user can follow links to more detailed information if they wish. However there is a warning against burying significant features of the processing (for example that may involve disclosure to third parties, or take place overseas) in linked pages that the user can choose not to read (p23).
- Unambiguous indication: the Opinion notes that the Directive allows consent to be expressed by “any” action, so long as there is no doubt that it indicates consent. The Working Party see this as allowing for many different approaches to provide user-friendly interfaces. Consent can, therefore, be inferred from a user’s action – such as requesting a particular service – so long as there is no doubt that the user understood and intended the consequences of that action (p21). Thus consent cannot be inferred from an action that might have been taken for another reason (such as entering the range of a Bluetooth transmitter with a device enabled to receive messages (p12)), nor can it be inferred from a failure to act (e.g. not responding to an e-mail warning that processing will take place unless you advise otherwise (p24) or failing to untick a checkbox on a web form (p24)).
Finally the Opinion warns against viewing consent as an easy option: “consent … does not relieve the data controller from his obligation to meet the other requirements of the data protection legal framework, for example, to comply with the principle of proportionality under Article 6.1(c), security of the processing ex Article 17, etc.” (p34), “and it does not legitimise processing that would otherwise be unfair according to Article 6 of the Directive” (p9). Consent remains an important part of data protection law, but it’s far from the whole story.
Thanks for the synopsis, clears up a lot of long-standing doubts I’ve been harbouring -except ‘legitimate interests’ question; but let’s leave that for antother day
Hi Glen
I suspect the “necessary in the legitimate interests” question is one we’ll have to pay quite a bit of attention to, even though it brings in the new question of whether those interests are overridden by the user’s fundamental rights. See my paper on privacy and incident response for examples of how that might work. It does have the advantage that the answer ought to be the same for all users, unlike the alternative justification of “necessary for the performance of a contract” , which raises questions of whether a particular site is actually necessary for a particular user to do their education/research/etc.
I’m planning to update my REFEDs paper in the light of developments but will probably wait till the draft DP Directive appears, expected some time this autumn.
Andrew, an interesting post, and I agree with by far most of it. I however would like to argue that even in cases where consent does not provide legal grounds for processing, this does not mean that you should not ask for it. Reasons being at least informing the user, consistent user experience and simply because, at least in a pilot we did, user appreciate it. See also http://maarten.wegdam.name/2011/07/27/consent-from-the-eu-legal-perspective/ for more detail.
Maarten
Thanks. I very much agree that we should tell users what will happen to their data – users ought to expect that and for most of the “necessary” purposes its a legal requirement to do that anyway. So if your blog posting said “a notification process is useful whatever grounds are used” then I’d fully agree.
But “consent” is a term that has a very specific meaning in the Directive and gives the user very specific rights. If you refer to your notification process as “obtaining consent” then you will be burdening yourself with all those rights, some of which you won’t be able to fulfil. At worst you could end up breaking the law when someone says “I withdraw my consent” and you say “sorry, you can’t”. Much better to be clear from the start what the actual grounds for processing are.
So I’m afraid that I agree with most of your blog posting, but I disagree with both your conclusions: notification is a requirement in (nearly) all cases even if the user doesn’t want it, and misusing the word consent when you are actually using a different ground could have significant legal and reputational consequences.
Andrew, I think I understand your point: using the word consent when the user from a legal perspective is only notified and not asked for consent is not a good idea from a legal standpoint. But that would, in case of a federated access management situation, mean that per service or even attribute you would have to make it clear to the user if:
- he is notified and clicking “ok” does not mean he consents (although e.g. closing the browser does mean that the actual data exchange will not happen)
- he is giving consent
It will provide a user experience challenge to do this in an understandable and user friendly manner. The only work-around that I can quickly think of is to avoid the word consent, and e.g. use “release” (as you used in a screenshot in an earlier blog post on attribute release).
That’s right: the problem is that “consent” is the legal equivalent of a reserved word
.
But as far as I can see none of the guidance forces us to use the word “consent” next to some boxes and something else next to others – it just requires that the user is clearly informed of the choices they have and their consequences. So what I was trying to do with the draft interface was give the visual clue that an attribute with a checkbox is being released based on the user’s choice (checkboxes have been around long enoug that I think it should be intuitive that checkboxes can be ticked/unticked they wish) whereas those without a tickbox have to be released unless the user decides, as you say, to close the browser and not visit the site. Tickboxes were the best I could do, but I’m not a user interface person so I’m hoping that some of them can come up with a better implementation of the basic idea.
Andrew
One of the things that confuses me in all of this is the definition of IP address as ‘personal information’. I find it hard to logically follow through the argument that the address of a machine I happen to be using, be it in a library, my institution, an internet cafe or my actual machine. I also wonder how this all fits with the rows around illegal downloading and firms using IP addresses to ‘identify’ people, who often aren’t the culprit. Can you offer any insight on these issues?
Nicole
The short answer is that the Article 29 Working Party have decided that there are sufficient cases where one machine does map to one person that you have to treat a label of a machine as a label of a person. The long answer is in their Opinion on the Concept of Personal Data. My own view is that the problem is the binary nature of the question – under current law information has to be either (heavily-regulated) personal data or (unregulated) non-personal data. For why both of those options are unsuitable for a wide range of identifiers, see my paper on Pseudonymous Identifiers and the Law. I’ve been trying to promote a more suitable approach through the various consultations around the revised Directive.
And on the copyright side the UK’s Digital Economy Act is very careful *not* to say that an IP address identifies a person: instead it creates a presumption that the person to whom the IP address is assigned has some sort of control over the person who is alleged to have committed an infringement using that address. Most of the “rows” are over the accuracy of that presumption.
I recently came across this at JISCLegal:
http://www.jisclegal.ac.uk/ManageContent/ManageContent/tabid/243/ID/2094/Do-we-require-student-consent-in-order-to-outsource-their-email-to-a-third-party-such-as-Google-or-Microsoft.aspx
It addresses the question “Do we require student consent in order to outsource their email to a third party such as Google or Microsoft?”.
So I’m now even more confused than I usually am.
Richard
This seems to derive from an example in the ICO’s Data Protection Guide. However the same Guide also has a statement of what I believe is the correct position – that you can export data so long as either you have assured yourself that the organisation you are outsourcing to provides adequate protection (e.g. because it’s in an “equivalent” country, or covered by US Safe Harbor, or a standard contract, etc.) or that you have the consent of all users. So you only need consent if you don’t have adequacy. We’re trying to fix the apparent contradiction in the ICO documentation and then update JISClegal to match.
Further to this, I see that the JISClegal Theme on Clouds has an answer to the outsourcing question that gives consent as just one of a number of options. The cloud paper itself actually suggests that consent is not a good option to choose