Apr 18, 2018 12:00:00 AM | Data Privacy A never-ending story: your organisation’s processor chains

Assume that you just found yourself with a supposedly complete article 30 GDPR register of your processing activities. You did the meticulous work of inventorying the activities, their purposes, the data subject categories and categories of personal data involved, and all the other information required by the article. You sigh deeply and sit back for a moment. Are you ready now?

Probably not. There are a few interrelated obligations that seem to force you to have a complete picture of all processors and subprocessors, almost ad infinitum. First of all, it is important to emphasise that the roles of processor and subprocessor are always determined in the context of a processing activity. Your organisation can be a controller for one processing activity and a processor for another processing activity.

Given a certain processing activity, as a controller, according to article 28 of the GDPR, you need to make sure that you “shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject.”

What is more, there should be a contract (or similar instrument) between controllers and processors, and between processors and subprocessors, containing all kinds of safeguards on the processing of personal data (part 3 and 4 of article 28 GDPR). Although the notion of ‘subprocessor’ is not itself part of the GDPR, it is pretty clear that the legislator means to set a hierarchy or ‘chain’ so that a controller can never escape responsibility.

Article 28 part 2 requires you – being a processor – to engage other processors only with prior written authorisation of the controller. If there is a general permission from the controller to the processor to employ different subprocessors, there should still be a notification from the processor allowing the controller to object to any change in subprocessors employed (part 2 of article 28 GDPR).

So for instance, PrivacyPerfect (as a processor for the customer using its software solution) wants to employ a different hosting provider (a subprocessor for its software solution). Even if PrivacyPerfect has permission under the processing agreement to employ different subprocessors without prior permission, it should still notify the change to its customers.

There is one escape route for this: if a processor does not respect the GDPR and contrary to its obligations determines the purpose and means of a processing, he will be deemed a controller for that processing activity (part 10 of article 28 GDPR). That will not really help the original controller, though, because he will still be held financially liable for any consequential damages.

The purpose of this set of obligations seems to be clear: a controller should be completely, well, in control. If you are a processor, you will probably have noticed the number of requests to sign processor agreements. You should realise yourself that – unless you want the buck to stop at your desk – you need to contract all your subprocessors too. But what does that mean in practice?

That is the hard part to answer. Assume that you use Microsoft Office 365 and store your documents online in Microsoft’s cloud. Do you know all the subprocessors that Microsoft employs? It is good to see that Microsoft actually provides a list of subcontractors on https://goo.gl/KqonGr. But it has 7 pages and without further information it is virtually impossible to determine which of these would actually act as subprocessor in one of our processing activities.

A similar list containing subprocessors of Google, with a similar concern, is available via https://goo.gl/Tyg2xP. Additionally, it is unclear if the list really contains the sub-subprocessors as well. What are the odds that the listed companies have subcontractors too? It is virtually impossible to determine where the processing chain really comes to a halt.

Without further information on the – very specific – conditions under which the listed companies could act as a subprocessor in your cloud processing activities, the question is how much these lists are worth. And, although I have not tried yet, I doubt whether there will be a very specific answer if a company like ours would ask (rest assured, our service is not hosted with either Google or Microsoft).

Since May 25th, supervisory authorities can enforce the GDPR; it remains to be seen if Google, Microsoft and its peers will ‘get away’ with this generic information. But more importantly, it is the question if your organisation, being the controller with the inseparable obligations explained above, will have any justification for not being able to answer supervisory authorities’ questions on the subprocessor chains.