Supreme Court absolves Morrisons of liability for rogue employee data breach

In a landmark judgment, important from both a data protection and employment law standpoint, the Supreme Court has held that vicarious liability cannot be imposed on Morrisons in a case which concerned the unlawful publication of Morrisons’ employee personal data online by a rogue employee.

Facts

The case involved a class of 9,263 Morrisons employees or ex-employees whose personal data had been unlawfully made available online back in 2013. The information (which included name, address, gender, date of birth, phone numbers, national insurance number, bank sorting code, bank account number and salary) was published by a rogue employee, Mr Andrew Skelton, as an act of vengeance against Morrisons due to a grudge he held against his employers for disciplinary action taken against him earlier that year. Whilst Mr Skelton was entitled to access the data as part of his role, he was only permitted to share the data with the company’s auditors.

The claims brought against Morrisons were made under the Data Protection Act 1998 (DPA), under common law for misuse of private information and breach of confidence, and also on the basis that Morrisons were vicariously liable for the acts of Mr Skelton. Damages were sought for the distress, anxiety, upset and damage which had been suffered by the data subjects concerned.

The court noted that Morrisons had also spent more than £2.26m in dealing with the immediate aftermath of the disclosure. A significant element of that sum was spent on identity protection measures for its employees. Meanwhile, Skelton, the employee, was convicted of a number of criminal offences and sentenced to eight years’ imprisonment.

High Court and Court of Appeal decisions

In 2017, the High Court found in favour of the claimants, ruling (among other matters) that Morrisons could be held vicariously liable for the acts of Mr Skelton since he had been provided access to the relevant data in the course of his duties as an employee and his publication of the data was “a seamless and continuous sequence of events”  relating to his duties. Furthermore, it was held that there was nothing which would prevent vicarious liability from applying under the DPA. Morrisons appealed to the Court of Appeal but were unsuccessful and so further appealed to the Supreme Court which heard the case at the end of last year.

Supreme Court ruling

The Supreme Court’s decision covered the following key issues.

  1. Could Morrisons be vicariously liable for Mr Skelton’s conduct?

The court found that the decision of the High Court and Court of Appeal relating to vicarious liability had focused too heavily on the judgment of Lord Toulson in an earlier Supreme Court decision (Mohamud [2016]) (coincidentally also involving Morrisons) in which a customer at a petrol station had been assaulted by an employee of the petrol station. Much had been made by the judges in the lower courts of Lord Toulson’s comments in that case that the decision of the employee had been connected to his employment and that his motives for assaulting the customer were “irrelevant”.

However, the Supreme Court found that Lord Toulson’s comments in the Mohamud judgement had been taken out of context and should not be construed as introducing new principles to the concept of vicarious liability. It ruled that the “close connection” test remained the appropriate test for determining whether vicarious liability could be imposed on an employer. Pursuant to the close connection test:

“…the wrongful conduct [of the employee] must be so closely connected with acts the employee was authorised to do that, for the purposes of the liability of the employer to third parties, it may fairly and properly be regarded as done by the employee while acting in the ordinary course of his employment.”

In the present case, the Supreme Court found that the “close connection” test was not met (despite there being a close temporal and causal link between Mr Skelton’s role and his publication of the data on the internet) for the following key reasons:

  • The disclosure of the data on the Internet did not form part of Mr Skelton’s functions or field of activities – he was not authorised to disclose the relevant data to anyone other than KPMG.
  • The motives of Mr Skelton in disclosing the data were important – the fact that he did so for personal reasons was “highly material”. Indeed, the reasons Mr Skelton had decided to publish the data was to cause harm to Morrisons due to his personal vendetta against the company.
  1. Does the DPA exclude vicarious liability for statutory torts committed by an employee who is acting as a data controller under the DPA?

Although not strictly necessary given the court’s finding that Morrisons could not be held vicariously liable based on the facts of the case, the court did give its views on the above question which are important from a data protection perspective.

It had been agreed by all parties that both Morrisons and Mr Skelton were independent controllers in relation to the data which was published online. In light of this, Morrisons had argued that it could not be held vicariously liable for the acts of Mr Skelton under the DPA since it had complied with its obligations as a controller under the DPA and Mr Skelton was acting as a separate controller when disclosing the data. Morrisons argued that the DPA did not allow for vicarious liability to be imposed on them for Mr Skelton’s actions as a controller.

However, the Supreme Court rejected this position, stating that since the DPA does not indicate (whether expressly or impliedly) whether the principle of vicarious liability applies to breaches of its obligations, an employer can be found vicariously liable for breaches which are committed by an employee who is acting as a data controller in the course of his or her employment.

Comment

The decision will be welcomed by business since it shows that employers will not generally be held liable for the acts of rogue employees acting outside their “field of activities”. However, it is important to bear in mind that the decision came down to the specific facts of the case. It is entirely possible that there could be cases where unauthorised disclosure of personal data by an employee results in an employer being held vicariously liable; an example could be an employee negligently leaving sensitive documents on a train on the way to a business meeting, or causing a data breach by failing to follow the company’s data security policies. As ever, implementing appropriate data security measures and policies and reinforcing the need for employees to follow such policies can help to reduce these risks.

The case is also the first to come before the Supreme Court involving a class action brought by data subjects for a violation of data protection rules. Notwithstanding the decision in favour of Morrisons, we expect class actions in relation to data breaches to become increasingly common.

Finally, although the case was brought under the (old) Data Protection Act, the position would not be any different under the GDPR and the new DPA.

 

Ben Nolan (solicitor, qualified in Scotland) and Nigel Miller (partner)

Codes of Conduct and Certification Schemes: one step closer….

Sian Barr

In brief

The GDPR provides two ways in which certain organisations can demonstrate that their processing of personal data is compliant with data protection laws, thereby satisfying the accountability requirement under the GDPR: Codes of Conduct and Certifications Schemes.

While each of these procedures is voluntary, organisations have been prevented from attempting to use them up until now as the administrative framework for gaining the requisite approval from the ICO of a proposed code or scheme has not been ready.

The good news is that these processes are now open: as of 27 February 2020, organisations can submit their proposals for a GDPR code of conduct or certification scheme criteria to the ICO for their approval.

In practice though, controllers and processors must continue to be patient as there are currently no approved codes or schemes out there.

The detail

  • Accountability is one of the data protection principles, requiring organisations to demonstrate their compliance with data protection laws.
  • Codes of Conduct and Certification schemes should both be useful voluntary accountability tools, once up and running.
  • Codes of Conduct can be used by organisations such as trade, membership or professional bodies to set out practical ways in which individual members of the organisation can comply with data protection laws, in light of the data protection issues specific to their sector or businesses. Once a Code of Conduct has been approved by the ICO, individual members of the organisation will be able to sign up to it to help demonstrate their compliance with data protection legislation. Adherence to the approved Code will be monitored by a monitoring body, which will also have been approved by the ICO.
  • In its new Guidance on Codes of Conduct, the ICO describes its role, which is to:
    • provide advice and guidance to bodies considering or developing a code;
    • check that codes meet the code criteria set out below;
    • accredit (approve) monitoring bodies;
    • approve and publish codes of conduct; and
    • maintain a public register of all approved UK codes of conduct.
  • As for Certification, this tool will allow businesses to demonstrate their compliance with data protection laws in respect of specific processing activities that are covered by a certification scheme. Organisations will be able to use certification to build trust in their business and to demonstrate compliance to their customers and contractors.  In particular, the GDPR states that certification can be used to assist in compliance with data security, privacy by design and international transfer obligations.
  • In its new Guidance on Certification Schemes, the ICO describes the UK certification framework as follows:
    • The ICO will publish accreditation requirements for certification bodies to meet;
    • The UK’s national accreditation body, UKAS, will accredit certification bodies and maintain a public register;
    • The ICO will approve and publish certification criteria;
    • Accredited certification bodies will issue certification against those criteria; and
    • Controllers and processors will apply for certification and use it to demonstrate compliance.
  • Codes of Conduct and Certification Schemes are not a ‘one size fits all’ solution: they will not be relevant to all organisations. They will apply to processing within specific industries, or to specific processing activities.

Comment

Codes of conduct and certification schemes are a welcome and useful addition to the methods available to businesses to satisfy the accountability principle.  Many sectors are faced with specific data protection issues, particularly when it comes to the processing of special category data.  ICO approved norms for addressing these issues, which are codified and then used across a sector will improve compliance across the industry and ensure a level playing field for data protection compliance amongst competing businesses.

Certification too will be useful once it is available.  It may allow consumers to quickly check that an organisation can be trusted to use their personal data for certain purposes.  It is also likely to form part of the due diligence carried out on a proposed processor or sub-processor, and may feature as a requirement in data processing agreements where a relevant certification scheme is available.

Sian Barr is a Senior Associate in the commerce & technology team at City law firm Fox Williams LLP and can be contacted at sbarr@foxwilliams.com

Happy Data Privacy Day! And what’s coming up in 2020?

Since 2006, 28 January has marked the anniversary of the first international law in the field of data protection – who knew?

A lot has happened since then. Data protection and privacy is now a rapidly expanding area of law of ever-increasing importance. As we head towards the second anniversary since the GDPR came into force, we review current developments and look ahead at what to expect in 2020.

Our special Data Privacy Day newsletter covers the following topics:

Accountability – sounds good, but what does it actually mean?
International transfers and Brexit
What’s cooking with cookies?
Whatever happened to the ePrivacy Regulation?
The growing culture of Data Subject Access Requests (DSARs)
Adtech – under regulator scrutiny
Artificial Intelligence (“AI”) and data protection
Data security – what’s appropriate?
Fines – more to come …
Class action compensation claims

Meanwhile, please make a diary note of our annual Data Protection Update seminar, which will be held on 14 May 2020.

Please do contact us if you have any questions or if our data protection team can assist you in any way.

Continue reading

The growing culture of Data Subject Access Requests (DSARs)

The GDPR gives data subjects the right to access the personal data which a controller holds in relation to them. Although this may sound fairly innocuous, dealing with DSARs in practice continues to be a source of much frustration for controllers, particularly in the field of employment where DSARs are often used by disgruntled employees as part of a wider litigation strategy.

Meanwhile, the ICO’s Annual Report 2018-19 (published in July 2019) shows that subject access requests generate by far the most complaints to the regulator (at 38%). We expect the use of DSARs will continue to be prevalent in 2020. Businesses who do not yet have processes in place for dealing with such requests should develop procedures and protocols to be followed when requests are received.  To this end, the ICO published updated draft guidance in relation to the right of access towards the end of 2019. Some key points for controllers to note are as follows:

  • Procedure for submitting requests – there is no particular procedure data subjects must follow when submitting a DSAR. Individuals do not need to designate their request as being a DSAR for it to be treated as such. Furthermore, individuals can submit DSARs through whatever channel they prefer (including verbally), meaning that it’s important that relevant staff are trained in recognising such requests.
  • Receiving DSARs from 3rd parties – it is common for 3rd parties, such as law firms, to submit DSARs on behalf of others. In such circumstances, controllers are entitled to (and should) ask the relevant 3rd party for proof of the authorisation permitting them to act on behalf of the data subject. The onus is on the 3rd party to provide proof of authorisation, and this can be achieved through a letter of authorisation or a general power of attorney.
  • Time for responding to DSARs – normally you must comply with a DSAR without undue delay and at the latest within one month of receipt of the request. You can extend the time to respond by a further two months if the request is “complex” or you have received a number of requests from the same individual. Some organisations claim the extra time on the basis that the request is complex because it involves a large volume of information. The ICO guidance indicates that, while this may add to the complexity of a request, a request is not complex solely because the individual has requested a large amount of information.

The ICO guidance provides helpful advice in relation to the timeframe controllers are required to respond to DSARs, including the circumstances in which a controller may be able to extend the time for responding to a request on the basis of it being “complex” or where it has received multiple requests from the same individual.

The following are given as examples of factors that may in some circumstances add to the complexity of a request. However, you need to be able to demonstrate why the request is complex in the particular circumstances:

  • Technical difficulties in retrieving the information – for example if data is electronically archived.
  • Applying an exemption that involves large volumes of particularly sensitive information.
  • Any specialist work involved in redacting information or communicating it in an intelligible form.

One key area where the ICO has changed its position is in relation to circumstances where a controller needs to raise clarifications in relation to the DSAR. Whilst previously the ICO had taken the view that the statutory timeframe for responding to a DSAR would not commence until the controller received a response to any clarifications raised by it, this is no longer the case in the updated guidance. The ICO now takes the position that the timeframe for responding commences from the date the DSAR is received, irrespective of whether any clarifications are raised by the controller or whether the data subject has replied.

  • Being ready for DSARs – the ICO guidance expresses little sympathy for controllers who aren’t able to process DSARs efficiently, stating that DSARs have been a feature of the law since the 1980s and that therefore organisations should have systems in place to deal with them. From our experience, many organisations do not currently have systems in place to deal with DSARs, and particular difficulties are faced with unstructured data such as emails. While there are a growing number of third-party solutions which claim to assist, organisations are often forced to expend significant time and expense in dealing with DSARs.
  • Charging for DSARs – the guidance provides further guidance as to what is meant by the “administrative” costs which can be charged by controllers where an individual submits excessive or manifestly unfounded DSARs. Printing, photocopying and postage would fall within the meaning of an administrative costs. Charging for employee time taken to deal with such requests – which can be significant – would not be.

Return to Data Privacy Day 2020 index

Artificial Intelligence (“AI”) and data protection

In the past few years, we have seen an increasing number of organisations developing or using AI solutions. Although the business case for the use AI is compelling, tensions can arise where its use is at odds with data protection laws.

These tensions between AI and data protection include the following:

  • Transparency – the GDPR requires you to provide individuals with notice setting out how you are using their personal data. Where there is an element of automated decision-making which results in legal effects or otherwise has a significant effect on an individual (as there often is with AI), the controller is required to provide affected individuals with “meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject”. Given the complexities with AI and the fact that some types of AI can develop in an unsupervised environment, without human intervention, it can sometimes be difficult to meet these requirements.
  • Purpose limitation, data minimisation and storage limitation – the GDPR requires that processing of personal data is carried out for specific purposes, no more personal data than is adequate to achieve those purposes is processed and that personal data is only processed for as long as necessary to achieve those purposes. There is often tension between these principles and AI, since the development of an AI system can often result in data being used for unexpected purposes, and often requires vast amounts of data to be inputted into the system in order for it to meaningfully detect patterns and trends.

In respect of the transparency issue, the ICO has developed draft guidance along with the Alan Turing Institute (the UK’s national institute for data science and artificial intelligence) dealing with explaining AI. The guidance provides detailed information on the different ways in which businesses can seek to explain the processing they undertake using AI to the individuals concerned and seeks to address some of the concerns businesses may have in providing such explanations.

In addition to the above, the ICO is also working on finalising its AI auditing framework which will address the following specific issues:

  • Accountability – which will discuss the measures that an organisation must have in place to be compliant with data protection law.
  • AI-specific risk areas – which will discuss the key risk areas the ICO has identified in relation to the use of AI in the field of data protection.

As the use of AI becomes more widespread, it is hoped that the guidance issued by the ICO will help businesses better understand and comply with their data protection obligations whilst still allowing them to develop AI systems which can benefit organisations and individuals alike as our knowledge in this area continues to grow.

Return to Data Privacy Day 2020 index