GDPR — a flaw in Article 28
It hasn’t caught up with developments in cloud computing
When a controller transfers data to a third party for processing, Article 28 of the GDPR legislation states that there has to be a ‘written contract’ covering the processor’s obligations and liabilities — including ‘documented instructions from the controller’ on how to process personal data.
That particular rule clearly originated in the days before the cloud came into existence, and people were still writing contracts. Today, cloud computing has become commoditised beyond all recognition. Controllers now deal with multiple cloud providers, each serving thousands, or even millions, of customers. And they do this on a self-service basis, without issuing any written instructions to anyone.
Most cloud service providers never even meet their clients
Needless to say, cloud providers like Amazon, Google or Salesforce are not going to sign individual GDPR-related contracts with their customers, most of whom they will never meet. Instead, they include their GDPR credentials in their generic terms of service, which controllers have no choice but to accept.
Now as long as cloud providers meet their GDPR responsibilities, there is nothing wrong with this approach — indeed, it is the most practical solution.
Article 28 is ultimately still work in progress
Since technology always moves much faster than legislation, this disconnect is understandable. So Article 28 should be seen as work in progress, until such time as the regulator takes into account commoditised cloud computing. When this happens, ‘written contracts’ will probably expand to include ‘terms of service’, and ‘documented instructions’ will become optional. Until that happens, controllers and processors today could both be technically in breach of Article 28; but the regulator is unlikely to enforce it.
What do controllers know anyway?
Article 28 also states that a processor ‘must not use a sub-processor without the prior written authorisation of the controller’. In the pre-cloud world, this approach made sense because of the risks involved in your outsourcer changing suppliers, which could have an impact on your operations. Today, however, we have a smorgasbord of interconnected cloud services, most of which are completely transparent to the controller. To put it bluntly, your average controller simply does not have the expertise to authorise a processor to use — for example, Stripe rather than Polka Dot for payments.
In order to be compliant, therefore, all a processor can realistically do is to inform its thousands of customers of any upcoming changes in its supply chain, and give them the option to approve — or to cancel their contract if they object. Not much of a choice, true, but it’s the only realistic one.
Here too, Article 28 needs to be amended to recognise the de facto right of a cloud-service provider to choose its own sub-processors without requiring the authorisation of its clients. Until then, processors can take comfort in the fact that they are not in breach of Article 28, since they do inform their controllers of any changes to their sub-processor supply chain. It’s just that it’s essentially an FYI, rather than an ‘opportunity to object’.
Michael Gentle is the founder of The Balance of Privacy, based in Geneva. For similar articles by Michael, click here.
Further reading
What’s wrong with the ICO’s draft guidance on controller-processor contracts?
