Date:

The Curious World Of Cookie Compliance: Cookies As “Personal Data”

Cookies have been in the glare of the compliance spotlight ever since the new cookies laws came into force earlier this year, which force organisations to be transparent about their use of cookies. The “new” laws are only part of the picture though. A lot of people forget that laws affecting cookies existed before 2012, in particular the “old” Data Protection Act 1998 (DPA). In this post we skip over the basics of how you should be treating cookies under the DPA.

What do we mean by cookies?

In line with the EU’s and Information Commissioner’s Office’s general approach, where we refer to cookies in this post, we are doing so for convenience. The themes explored in this post apply to all similar tracking technologies which involve small files or bits of code being uploaded to a user’s machine and accessing periodically. These include flash cookies (or locally shared objects) and clear gifs.

As a starting point, you therefore need to understand what your website runs and will run going forward, before turning to how the law treats the relevant technology and resulting information.

Are cookies “personal data” under the DPA?

The short answer is “Normally, yes”.

That said, the answer is not clearly set out in any relevant legislation.

Nor does it come from the ICO guidance on the new cookies laws, which largely duck the issue. The ICO just say “Where the setting of a cookie involves the processing of personal data, those using them will need to make sure they comply with the additional requirements of the DPA.”  

Instead, we have to look to the EU’s Article 29 Working Party (A29WP) for a steer. They set their stall out back in 2008 in some guidance around search engines and have stuck to it ever since.

“When a cookie contains a unique user ID, this ID is clearly personal data. The use of persistent cookies or similar devices with a unique user ID allows tracking of users of a certain computer even when dynamic IP addresses are used.”

Cookies are generally used to track behaviours and therefore normally include a unique ID for the relevant device on which they are placed. As a result, they are, in and of themselves, “personal data” in most cases.

Your organisation therefore needs to be thinking about the requirements of the DPA wherever they are used.

Why does the A29WP take this view?

The fundamental point is that the A29WP position is consistent with the general EU and UK approach on what is “personal data”.

In essence, the concept revolves around a person being actually identified or identifiable.

The correct way to approach identification is not to think about names, addresses etc per se, but instead to think about people being “singled out” or “distinguished” from the general public.

Organisations use a lot of ID numbers in their everyday activities to distinguish people, and link information on a person to those IDs. The EU has always taken the view that it would be absurd to treat such numbers as anything other than personal data when their core purpose is identification.

For obvious reasons, ID numbers used in the world of IT, such as in cookies, do not get any special treatment.

Is the data derived from cookies also “personal data”?

It should come as no surprise to learn that that the answer is also “Normally, yes.”

Cookies can be used for lots of different purposes, but stereotypically drive behavioural data, in particular about what areas of the internet hold our interest.

This kind of data unquestionably “relates to an individual” (the first part of the technical legal definition of personal data).

At its most detailed level, it is also linked to something which allows an individual to be “identified” (satisfying the final part of the definition of personal data), namely the cookie itself.

This linkage means that the cookie-derived data is also personal data.

This proposition might sound simple, but it does require a little thought. For example, the linkage will not apply in all cases. You might receive behavioural data derived from cookies from, say, third party advertising networks you have allowed to publish ads on your site. If that data is highly aggregated and you can’t relate it back to individual cookies (say because you never see the cookies themselves), then it won’t be personal data in your hands, but would be in the hands of the advertising network.

So what if cookies and cookie-derived data is personal data?

If you use cookies and the data derived from them in circumstances where they amount to personal data, then the DPA applies to your usage.

The DPA applying triggers lots of other obligations. We obviously can’t digest all of them here, but to illustrate:

  1. You need to look pro-actively at what kind of information you derive, especially if the data allows you to segment your users as this can have significant compliance complications. For example, if you segment by health (e.g pregnancy) or likely sexual preferences, this is “sensitive personal data” under the DPA and requires “explicit” consent from a user. This in turn means you to be thinking about tick boxes or agree buttons, and even clearer privacy notices, rather than implied consent to cookies and related information as advocated by the ICO.
     
  2. You need to comply with the first DPA principle and provide privacy wording in your privacy policy or cookie policy around what cookie-related data you obtain, and the purposes for which you use it. The recent criticism of Google by CNIL (the French data protection regulator) highlights the danger of being too general in this area.
     
  3. You can only use the data for specific purposes, and can’t later do anything which is incompatible with those purposes. This requirement is set out in the second DPA principle. It means you can’t chop and change usage of cookie data as you like. For example, if you’ve just been using cookie data to tailor your site, you can’t all of a sudden link it with your full customer relationship management database and use it for sophisticated customer profiling, without going and getting existing user consent, which would be highly impractical.
     
  4. You need to make sure the behavioural data remains accurate, and give users the right to rectify it if they believe it is wrong. This is required by the fourth and sixth DPA principles.
     
  5. You need to consider how long you will store the cookie and cookie-derived data for. In line with the fifth DP principle, you need to delete or anonymise the cookie and related data once no longer needed for the purpose for which it was obtained.
     
  6. If a user or customer puts in a subject access request (SAR) relating to all of their personal data, you will have to provide them with a copy of the related cookie data you hold on them, in an intelligible format, as required by the sixth DPA principle. Very few organisations think about this angle in our experience. A straight extract from your database will probably not suffice, because only a technical IT expert could understand it. As a result, you’ll need to think about how best to portray this information.
     
  7. You might also want to think about the light in which your organisation will be portrayed by such an SAR. If you take an aggressive stance in your privacy wording around cookies and behavioural tracking for fear of looking like “Big Brother”, you could be found out through a SAR, with negative reputational consequences. Have a look at our posts around trust to understand some of the current industry thinking concerning this element of your user relationship.
This information is intended as a general discussion surrounding the topics covered and is for guidance purposes only. It does not constitute legal advice and should not be regarded as a substitute for taking legal advice. DWF is not responsible for any activity undertaken based on this information.