Dr Gavin Scruby,CIO,SmartDebit
Certain industries have significant restrictions on the way they process data. Some of the most common are defence, health, credit card and government. When these organisations process data, they have to comply with industry-specific regulations, which benefits us all. What some companies have not yet realised is that everyone now operates under a similar kind of regulation. This is of course the General Data Protection Regulation, most commonly referred to as GDPR, which now governs data protection across the EU. The UK government intends to write GDPR into UK law and stay largely parallel with the EU, so the caveats here will probably apply even in the case of a no-deal Brexit. While many people know that the GDPR affects how they should protect data, the breadth of impact on the data controller-processor relationship is often missed, and this can have catastrophic effects on business flexibility, and particularly on cloud migration.
Before getting into the consequences of this and how they could be managed, it’s worth looking at what controller and processors are, to see how they affect nearly everyone who offers a service over the internet. If you have a website and you integrate a card payment service, you are a data controller – you decide what data you collect from your customers (card details and postcode), why it is processed (to make a card payment) and who processes it (the card payment processing company). While you are the controller, the card company is your processor – it processes data from your customers to enable credit card payments to happen. This kind of relationship is more common than many people may think. In any situation where a company provides a personal-data processing service to another company, that service company becomes a processor. It could be an online CRM service, a bookings service, an online document storage service, even a paper document library (as GDPR applies to printed information too) – almost anything where the service provided stores or processes personal data for another organisation creates a controller-processor relationship.
The difficulty now is that GDPR puts a lot more restrictions on what a processor can do without the controller’s consent, largely because the controller now has many more obligations to check and control how data that it collects is used. This is only fair; if you are liable for data you’ve collected, you should have some say in what is done with it when you subcontract it to someone else.
A key restriction, and the one we consider here, is within the GDPR’s Article 28 Paragraph 2: “The processor shall not engage another processor without prior specific or general written authorisation of the controller. In the case of general written authorisation, the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes.”
The simple language interpretation of this is that as a processor, you can’t change your data subcontractors without explicit permission from your controllers (i.e. customers) – and that means all of them. This is difficult enough if you want to change standard suppliers, but the often neglected consequence is that it can also affect where you locate core data and whether you migrate to the cloud. Even if you rent rack space in a data centre (co-location hosting) and the data centre never “sees” unencrypted data, this is still classed as a sub- processor by the law. Consequently, any move to another data centre, or a migration to cloud, is considered a change in sub-processor, which therefore requires permission from all customers.
In practice, this could be extremely limiting. You would not want to attempt to arrange written authorisation from every customer when you want or need to move to the cloud. If nothing else, it could push back migration timescales by years. The most you would want to do is inform customers, with perhaps an early termination clause if they had a significant issue. This is not how contracts are being drafted, and not how the ICO recommends they are drafted. Standard clauses will be created by the EU or ICO in time, but these are not yet available. The ICO recommends contract terms of the form: before employing a sub-processor, the original processor must inform the controller and obtain its prior specific or general written authorisation. It is possible to draft contracts to contain general written authorisation or include clauses to allow early termination or assumed acceptance on non-response, but you’ll need professional legal advice to make these enforceable and legal such that they do not violate the GDPR.
The result of the introduction of the GDPR now means you need to do two things: firstly, make sure your own contracts are drafted to ensure maximum flexibility for you but in compliance with the law; and secondly, read sub-processor clause amendments made by customers very carefully. Here you need to discuss your specific circumstances with your legal advisors or industry body. If you just migrate to cloud without customer consent, you could fall foul of GDPR sub-processor limitations, and many more organisations and individuals are getting knowledgeable on their rights.
Don’t panic though. The GDPR has thrown up many situations like this and it is still very new, in case law terms. The GDPR is not intended to work in such a way as to stop dead industry-wide cloud adoption. Everyone is finding their way on these rules right now and the ICO seems to be taking a “carrot” rather than “stick” approach for those companies who are genuinely trying to improve data protection but still operate their businesses competitively. In time, consensus guidance will be developed, but until that time, we all have to be more careful about what we sign and even more careful about the contracts we write.