Data Processors wake up to the GDPR
We undertook a GDPR impact assessment for a large data processor recently and I thought it might be worth sharing our findings and thoughts. Not surprisingly we identified three sources of threat: a processor’s suppliers, their customers, and their ability to meet their own responsibilities set out in the GDPR.
I think overall the bit that surprised them the most is what I have been saying for almost a decade now – the supply chain will drag you along the compliance path whether you like it or not! First, let’s have a look at the main threats by category:
I guess this is pretty obvious but the greatest risk to processors in relation to the supply chain is caused by the sub-processors they appoint. So if you are a small company providing for example hosting services, email broadcasting services, postal mailings, or even confidential waste or IT disposals etc. and you hire anyone else as a sub-contractor who has access to personal data – how they handle your customer’s data is your responsibility. Article 28(4) imposes obligations on processors to control and monitor any sub-processors that it uses and to ensure that they are under an approved and appropriate contract and the GDPR is clear that where that other processor fails to fulfil its data protection obligations, the initial processor remains fully liable to the controller for the performance of that other processor’s obligations.
Article 29 requires the processor and any person acting under the authority of the processor who has access to personal data to only process those data on instructions from the controller unless required to do so by law. And these obligations roll down the supply chain meaning that if your supplier further engages another supplier, for example a back-up or DR mirroring arrangement etc. the whole chain is likely to be caught by the provisions.
Processors therefore need a framework for supplier selection and appointment, briefing, and on-going management. In addition records need to be maintained of all such interaction with sub-processors. The obligations on overseas transfers are also relevant but not touched upon here.
The risks presented by a processors’ customers are several but boil down to two big ones in my opinion: the risk of unlawful processing and the risk of a processor being classified as a joint controller.
The risk of unlawful processing has several causes. If a controller collects personal data unlawfully, then any subsequent processing is also carried out unlawfully. In the ICO’s guidance on PECR (admittedly a slightly oblique angle but bear with me) it states,
“What if we pay someone else to do our marketing?
You are both responsible for complying with PECR. Even if someone else actually makes the calls or sends the messages, you are still responsible, as you are ‘instigating’ those calls or messages. If we needed to take enforcement action, we would usually take it against you as the instigator. In some cases we might consider taking action against a specialist subcontractor as well if they deliberately or persistently ignored the rules.”
It seems reasonable to assume (although this is speculation) that this approach would be taken with a processor turning a blind eye to unlawful processing they were undertaking on behalf of a client which could be caused by a controller’s failure to comply with the data protection principles. This speculation is supported by Article 28(1)(h) which states that, “the processor shall immediately inform the controller if, in its opinion, an instruction infringes this Regulation or other Union or Member State data protection provisions.”
So how much do you really know about the activities of your customers? Are they likely to land you in it?
The other big risk is undertaking activities which render you liable to be classified as a controller or joint controller. Article 26 introduces the concept of joint controllers, “where two or more controllers jointly determine the purposes and means of processing, they shall be joint controllers” and sets out responsibilities for the controllers. Article 28(10) states that, “if a processor infringes this Regulation by determining the purposes and means of processing, the processor shall be considered to be a controller in respect of that processing” and therefore subject to far greater obligations under the GDPR.
So processors need to ensure that they take no action which renders it liable to be classified as a joint controller as this would bring significantly more obligations. You’d be advised to ensure your client briefs are accurate, complete and that there are no circumstances where your staff to have to make decisions because of poor or vague instructions as well as no back-doors into your organisation for unofficial briefing or variations.
Processor’s Own Risks
One of the biggest factors affecting both controllers and processors is in relation to information security. Article 28 sets out specific obligations on processors most of which revolve around contractual relationships and using sub-processors – but within the detail of what is required in contractual relationships is Article 28(3) requiring processors to take all measures required pursuant to Article 32 which of course sets out the need for a risk-based approach to implementing sufficient technical and organisational measures to protect personal data from accidental or unlawful destruction, loss, or alteration, and unauthorised disclosure of, or access to personal data that is transmitted, stored or otherwise processed, and to protect the rights and freedoms of data subjects.
Being compliant and having good information security measures is one thing – being able to evidence them is quite another! The accountability principle relates specifically to controllers but Article 32 contains provisions to ensure the regular testing, assessing, and evaluating the effectiveness of the security measures which applies to processors as well as controllers. Article 28 points towards certifications, accreditations, and codes of practice as being suitable mechanism to provide for the demonstration of compliance so you may well wish to pursue an ISO27001 program in due course because if you can’t evidence compliance…
Another interesting twist is that some small to medium sized operations may find themselves being dragged into having to become complaint with areas of the GDPR from which they are exempt. For example, some may be coerced into appointing a data protection officer through client pressure and while processors are not required to respond to information rights requests as that is a controller responsibility, they may well be required to support their customer when these are exercised. Equally, it is controllers who are responsible for undertaking data protection impact assessments (DPIA) but I would fully expect a processor to have a DPIA capability and to use it to explore risks within its operations and/or be able to complete a DPIA with or for me in relation to a specific brief.
Finally it is the responsibility of controllers to notify the ICO of personal data breaches, but there are obligations on processors to inform controllers “without undue delay after becoming aware of a data breach”. Processors therefore need to have a formal data breach policy and process and be able to identify exactly what data was subject to a personal data breach.
This is just a flavour of our thoughts and findings through undertaking a GDPR impact assessment for a handful of processors. The table below may be a useful reference point as to how some of the articles apply to controllers and processors. There is a lot more detail to consider as a processor but the bottom line is that processors no longer are off scott-free. They will have significant obligations from May next year.
Summary of the application of GDPR articles to Controllers and Processors
A5(1) Data protection principles apply to both controllers and processors.
A5(2) Accountability principle applies to controllers.
A6 Lawful conditions for processing personal data – processors will most likely be processing personal data on the basis of the pursuit of the Legitimate Interests of the data controller.
A7 &8 Relate to consent and apply to the controller.
A9 Lawful conditions for processing special categories of personal data – processors will most likely need to rely on the lawful grounds of the data controller.
A10 Prohibit processing personal data relating to criminal convictions and offences unless under an official authority which applies to both controllers and processors.
A12 to 22 Relate to information rights of data subjects the servicing of which is a responsibility of the controller but the exercise of which will potentially impact a processor (erasure, portability, SAR, restriction etc.).
A22 Restricts processing activities defined as “automated individual decision-making including profiling” in the GDPR and requires controllers to satisfy the legitimising conditions.
A27 Refers to representatives and applies to both controllers and processors.
A28 Sets out the legal obligations of processors.
A29 Relates to the control of persons who have access to personal data and applies equally to controllers and processors.
A30(2) Requires processors to keep certain records about their processing activities/operations.
A32 Relates to information security and applies to both controllers and processors.
A33(2) Requires processors to notify controllers of any personal data breach.
A35 While the obligation to undertake data protection impact assessments applies to the controllers it may be that controllers use this as a tool they require their processors to adopt.
A37 to 39 Apply to controllers and processors and requires the appointment of a Data Protection Officer in certain circumstances.
A40 to 43 Relate to codes of conduct and certification and can be used by controllers and processors as a method for demonstrating compliance.
A44 Prohibits the transfer of personal data to third countries and applies equally to controllers and processors.