For those of you who deal with the wonderful document that is a processor contract. Whether you’re on the Controller side or the Processor side, you will know there are quite a few hoops to jump through. This is because GDPR strengthened the requirements of a Controller-Processor relationship, outlined in Article 28. That said, a recent case has gone through the UK court system, all the way to the UK Supreme Court, which clarified that when a third party processes data outside of the Processor-Controller contractual agreement, the Third Party then becomes the Controller for this ultra vires processing. Processors who are inadvertently processing data, without explicit instructions from the original Controller, could find themselves at considerable legal risk in the event of a GDPR Breach. Here’s why…
Processor Contracts & GDPR
Before we go on to the legal risk issues, let’s first look at some of the text of GDPR so we can build up the picture of how a Processor can become a Controller. The first thing to do is understand what Processing actually means. Many organisations are still not aware of the all-encompassing nature of the GDPR definition of Processing. So, if you’re one of those organisations, Article 4 of the GDPR states ‘processing’ means:
“any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, STORAGE, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction;”
I’ve specifically put storage in bold and in capitals for reasons that will become clear in the next section but suffice to say it’s worth being reminded of how much the definition of processing covers. If anyone outside your own organisation is doing something with personal data, on your behalf, then they are most likely a Processor. That means, amongst other things, Article 28 and 29 apply. Article 29 states:
The processor and any person acting under the authority of the controller or of the processor, who has access to personal data, shall not process those data except on instructions from the controller, unless required to do so by Union or Member State law.
What this means is a Third-Party organisation can’t process the data a Controller provides them without a contract AND it can only process data based on the instructions provided by the Controller. What this means in practice is that when it comes to the Processor-Controller relationship, there must be a Processor contract in place to lay down exactly what the Processor can do with the Personal Data to which the Processor is entrusted (and also, what they can’t do with that Personal Data). There are a lot of things that need to be considered when it comes to creating such a contract but for the limited purposes of this discussion, it’s worth pointing out the following key clauses of GDPR Article 28, which states:
“The processor shall not engage another processor without prior specific or general written authorisation of the controller.”
Article 28 also states the Processor shall only process:
“the personal data [on behalf of the Controller] only on documented instructions from the controller, including with regard to transfers of personal data to a third country or an international organisation”
So what happens if a Processor decides to go off-piste or processes data in a manner that could be argued isn’t within the “documented instructions of the Controller”?
Processor Contract – Enter WM Morrisons Supermarkets plc v Various Claimants
Some avid readers of data protection law may already be aware of UKSC 2018/0213. Whilst I am not going to go into the details of the case, I do want to point out the relevant quote that was agreed by both Claimant and Respondent Counsel. It was also held by the Judges in the High Court and Court of Appeal. The key text is below:
“neither side challenges the Judge’s finding that Mr Skelton, and not Morrisons, was the data controller under the DPA in respect of the data wrongfully copied by Mr Skelton onto his personal USB stick and subsequently disclosed by him on the internet”
For those not of a law background what the above text essentially confirms is that where data is processed in a manner not explicitly permitted by the Data Controller, the Processor is in fact the de facto Controller for that processing activity. This was also confirmed in a previous case [2017] EWCA Civ 121 where it states:
“if they [a Processor] are processing personal data on their own behalves they will be controllers as regards that processing and those data.”
Processor Contract – Scenarios where a Processor could be a Controller
In quite a few scenarios a Processor could find they may already be a Controller if they have not considered some of the following scenarios in their Processor contracts. Let’s have a look at a couple of common scenarios.
Third Country Transfers
Remember when I highlighted “storage” in the definition of Processing? Well hopefully you do as it wasn’t that far back! Anyway, let’s say you’re an Application Developer and to support your development you use AWS. You predominantly work in the US availability zones and have sold a cloud-based application to an EU company (or a UK-based company for the foreseeable future). If it is not explicit in the Processor contract that you have the authorisation to process data in a Third Country (i.e. store the data in the US) then you could now be considered the Controller for that Processing.
Transfers to Third Parties
If you Sub-contract application support to India or South Africa (i.e. otherwise making personal data available) then, in addition to a Third Country transfer issue, you could also be considered the Controller for this Processing too. If the rights and freedoms of Data Subjects are affected as a result of this Processing, a Processor may also be found to be liable as a Controller if this processing was not explicitly included in the Processor contract.
Security of Processing
Let us now consider a common inclusion in Processor contracts, underpinned by GDPR Article 32 (Security of Processing). A Controller may make some basic, and reasonable, explicit stipulations in their contracts in regards to the security of processing. One such stipulation could be that personal data must not be processed within an unsupported operating system (OS) environment. Going one step further a Controller may also require those operating systems have security patches applied within a mandated timeframe (typically 30 days). If there is a security breach at a Processor and it was found the data was being processed on an unsupported OS. If there was processing occurring on an OS missing a security patch that should have been applied but was not. In such cases, the processing was not carried out as per the instructions of the Controller and therefore the Processor has, arguably, become the Controller.
Incomplete Processor Contract – What does this mean for legal risk?
That a Processor can become a Controller throws up a number of interesting questions. Could Controllers apply defences for breaches, originating at a Processor, based on the premise that they were not the Controller for the particular processing? Could a Data Subject seek judicial remedy one more step along the supply chain? How much involvement are IT and InfoSec having with regards to what is being agreed within Processor contracts? If they are not aware, how is it affecting their risk management regimes? Should the Head of IT be able to universally accept the risk of not maintaining infrastructure where contractual obligations exist that she doesn’t know about? And what of the risks to subcontractors who may not fully appreciate how many Controllers they are actually supporting unlawfully?
The key takeaway is to work with your legal representatives to make sure your Processor contracts are fit-for-purpose but also make sure your IT, InfoSec and DPO know what those contracts do (and don’t) contain. From an InfoSec and DPO perspective, organisations need to ask themselves how do we know, as a Processor, we are only processing data as per our Controller’s instructions? If you can’t get a decent answer to that question, you could be a Processor with a whole load more risk than you thought!
About Fox Red Risk
Fox Red Risk is a boutique data protection and cybersecurity consultancy and Managed Security Service Provider which, amongst other things, helps client organisations with implementing control frameworks for resilience, data protection and information security risk management. Call us on 020 8242 6047 or contact us via the website to discuss your needs.
22301 22301:2019 article 28 awareness bcms BIA business continuity calculating risk change management ciso controller cybersecurity data breach data privacy Data Protection data protection by design data protection officer data protection service Data Subject Access Request DPO DSAR GDPR incident management information security leadership monitoring operational resilience Outsourced DPO Privacy processor risk risk appetite risk management ROI security security as a service small business strategic strategy Subject Access Request tools training transparency vciso virtual ciso
