Subject access requests: Some goods news for data controllers?

Posted by Simon Stokes on
The Data Protection Act 1998 (DPA) gives individuals the right of subject access.  If an individual makes a subject access request (SAR) to a data controller, the data controller must:

- Tell the individual whether any of that person's personal data is being processed by or on behalf of the data controller;

  • if that is the case, give the individual a description of:
  • the personal data
  • the purposes for which the personal data is being or is to be processed, and
  • the recipients or classes of recipients to whom the personal data has or may be disclosed, 

- And provide the individual with:

  • the information constituting any of that person's personal data
  • any information as to the source of the personal data, and
  • a description of any automatic processing of the personal data for the purpose of making decisions about the individual.

The data controller can charge the individual a fee of up to £10 and has 40 calendar days from receipt of the SAR and payment of the fee to comply with its obligations.

Organisations normally comply with SARs by searching for and providing the individual with copies of all hard-copy and electronic documentation held by the organisation that contain the individual's personal data (data the individual is not entitled to receive (e.g. third party data) is normally redacted).

SARs can be both costly and time-consuming, and are also open to abuse.  It is not uncommon for individuals to use the right as a fishing expedition to obtain information they may be able to use against the organisation in litigation.

These issues were considered in the case of Elliott v Lloyds TSB Bank Plc & Anor, which was decided by the Leeds County Court earlier in 2012.  In Elliott, Mr Elliott made various allegations against the bank following the failure of his business and sought litigation disclosure.  

When disclosure was refused, he made a SAR in an attempt to obtain the same information.  The bank gave Mr Elliott a significant amount of his personal data in response.  

However, Mr Elliott wanted the bank to undertake further searches and took the bank to court.

The Court decided the following two key issues:

  • firstly, whether the bank could refuse Mr Elliott's SAR on the grounds that it was made, in part, to obtain information that would otherwise only be available through litigation disclosure. The Court decided that the 'but for' test should be applied.  If it could be shown that 'but for' the litigation the SAR would not have been made, the SAR would be an abuse of process and the bank would not have to comply with it.  If, however, Mr Elliott had mixed motives for making the SAR so that it had been made partly to obtain information that would otherwise only be available through litigation disclosure and partly because Mr Elliott was concerned that the bank had misused his personal data, then the bank would have to comply with the SAR.  The Court came to the latter conclusion and decided that the bank must comply with the SAR, and
  • secondly, whether the bank's obligation was limited to conducting a proportionate search for Mr Elliott's personal data.  The Court decided that the obligation on the bank was to provide Mr Elliott with the personal data it found after conducting a proportionate search.

The Elliott case is not the first on this subject and follows a couple of earlier cases, Durant v FSA and Ezsias v Welsh Ministers.

Is the Elliott decision good news for data controllers?  Yes, sort of.  Firstly, the case shows that organisations do not have to comply with SARs made for the sole purpose of getting around the litigation disclosure process.  

The problem is that it will be fairly easy for individuals to argue that a SAR is made partly because they suspect their personal data is being misused, which means organisations will still have to comply with most SARs.

Secondly, the case shows that organisations are required to carry out proportionate, not endless, searches for personal data.  However, what is proportionate will depend on the circumstances.  

In Elliott, the threshold was set fairly high as the bank had already carried out an extensive search and had given Mr Elliott significant amounts of his personal data by the time he took them to Court.

The Elliott case also shows the extent to which the Courts will follow guidance issued by the Information Commissioner's Office (ICO):

  • Firstly, the ICO's view on SARs and legal proceedings is that data controllers must comply with SARs regardless of whether the individual is contemplating or has begun legal proceedings.  In Elliott, the Court rejected this interpretation and said that if the sole purpose of the SAR was to obtain documentation or information that may assist in a claim against a third party, that is an improper purpose and the data controller is not required to comply with the SAR; and
  • Secondly, the DPA contains an exemption saying that data controllers do not have to supply copies of personal data under an SAR if doing so would involve disproportionate effort.  The ICO's view on this is that the exemption only applies to providing copies of the personal data and not to the search for personal data.  In Elliott, the Court rejected this interpretation and said that the exemption applies to both providing copies of the personal data and to the search for personal data.

The Elliott case therefore shows that the ICO's guidance is not binding on the Courts and that the Courts will have the final say when it comes to interpreting the DPA.

In conclusion, the Elliott decision is useful for organisations and shows that the Courts are continuing to take a sensible approach to SARs.  However, it does not relieve organisations of their obligation to comply with SARs and should be relied upon with caution.

About the Author

Leading the firm's technology practice in London, Simon specialises in information technology law, including outsourcing, cloud services, protecting software IP and licensing of market leading data analytics software.

Simon Stokes
Email Simon
020 7814 5482

View Profile