How much do data centres and cloud providers need to know about the data? - part one

The volume, profile and relevance of regulation around data has increased significantly in the last few years.

We've seen record fines handed out for breaches affecting millions, (TalkTalk and Yahoo), charities lambasted for wealth screening practises (which were widespread but not transparent), revelations about government monitoring and back-door access to private corporations' systems and outcries over attempts by government to create a central health database (care.data). And now we have the General Data Protection Regulation 2016 ("GDPR"), bringing major changes for data controllers and, for the first time, direct statutory obligations for data processors too.

So if you are a data centre operator or cloud service provider, how much do you need to know about all of this? After all, it's your customers' data, not yours, so you aren't responsible for it, right?

If only the world were that simple…

There's a sliding scale depending on what type of service you are providing, and how close you are to the data itself and the systems in which it resides. Those factors will determine whether any of the legislation applies to you directly. You should also be aware of legislation and industry requirements affecting your customers as well, to be able to anticipate what they will want to see from you.

In this article, the first of a two-part series, we look how GDPR applies to different types of service providers along this scale.

The General Data Protection Regulation 2016 ("GDPR")

For the first time, the GDPR puts statutory obligations on data processors. A "processor" processes data on behalf of another (the "controller"), under the controller's instruction and direction. To "process" is very wide and covers almost anything to do with data other than pure transit. Storage and deletion are "processing".

Colocation provider

Pure colocation operators' positions have been, and will remain, that they are not processors under GDPR. As the hardware on which data is processed is not owned by the colocation provider, they are not a processor.

Two 'buts'.

Firstly, there are some limited activities where the provider will process data. Most data centres require visitors to submit a passport or other identification to gain entry. The operator records those details in order to maintain security and will be a controller of that data. Where security guards are provided by a third party, operators will need to ensure that they have appropriate clauses in their contracts to cover this processing. CCTV over common areas of the data centre involves processing of data. Whether the operator is a controller or processor here will depend on what degree of control the operator has over the CCTV system.

Secondly, whilst operators are not processing data, the security around the data centre is part of the security ecosystem that customers will evaluate to determine whether the data is protected by "appropriate technical and organisational measures" from theft, loss, accidental disclosure. The standard required for security by the GDPR has not changed from that in the current Data Protection Act 1998. However, controllers are required to obtain "sufficient guarantees" from their processors that the processor is capable of complying with the GDPR. Whilst operators will not be processors for the vast majority of data that resides in their data centres, operators should anticipate customers asking more details questions around security and requiring more documentation of security systems, including evidence of testing and results, incident logs and certifications.

So the main changes under GDPR which will affect colocation providers are:

• Where the operator is a controller (i.e. for employee data, access identification document and possibly CCTV), the full force of the GDPR will apply e.g. mandatory record keeping, mandatory breach notification, more detailed privacy notices, carrying out Data Protection Impact Assessments for systems like CCTV;
• Where the operator is a processor (which will apply in limited scenarios e.g. CCTV where the customer prescribes how the CCTV will operate, but the operator will not be a processor for the data that resides on the customer's servers in the data centre), the operator will need to comply with the processor specific obligations in relation to that data (see advice for platform as a service (PaaS) operators below);
• Anticipate that customers may be asking more detailed questions about security and require more evidence. Remember though that you are not a processor of this data, so do not have a direct obligation under GDPR to ensure that there is adequate security in place.

PaaS provider

Providers of platforms within the technology stack will definitely be processors on the basis that they store data or host applications in which data resides. However, if the service is limited to providing a mere platform onto which the customer installs their own applications which carry out the actual transactions with the data, then the provider will not be a controller.

The big change for PaaS providers is that you now have direct statutory obligations as a processor, whereas previously your data protection obligations were only those flowed down in contracts by controllers. You could therefore be subject to regulatory fines for failing to comply with your obligations, in addition to contractual liabilities. Fines are substantial - up to €20million or 4% of global annual turnover (whichever is greater).

Key obligations you will need to comply with are:

• security (which is a joint responsibility with the controller);
• ensuring international transfers occur using an approved transfer mechanism (also a joint responsibility with the controller);
• mandatory record keeping of your processing;
• ensuring that your sub-processors can provide "sufficient guarantees" that they comply with the GDPR;
• assisting the data controller to implement data subject rights and with their own security obligations (but in a manner appropriate to the nature of the processing) and assisting with Data Protection Impact Assessments.

Key actions for PaaS providers are therefore:

• prepare evidence that your company is capable of implementing the GDPR as controllers are required to ensure that they have "sufficient guarantees" from you. It will be much simpler if you are prepared for the question rather than allowing each customer to require different evidence. In the future, hopefully the regulators will approve some certifications or codes of conduct to simplify this;
• determine what security you deem to be appropriate for the platform, given that you will not know exactly what data your customer will be processing. Be very clear with customers that they will need to take the risk that actual security is suitable as determined by the customer given that only they will have detailed knowledge of their applications, processing, types of data, categories of data subjects etc;
• have a Data Protection Impact Assessment for your platform/systems that is suitable for sharing with customers. Customers are likely to want to see these to feed in to their own assessments (which will be mandatory in certain circumstances);
• consider how your system meets the principles of privacy by design and privacy by default. This means that privacy considerations should be one of the design principles of software systems, rather than being bolted on afterwards. Whilst this is not a direct obligation on processors in the GDPR, it is something that controllers have to show and the recitals to the legislation note that controllers will be reliant on their suppliers to achieve this;
• think about what you need from customers so that you can meet your GDPR statutory obligations. The GDPR expects controller's obligations to be set out, as well as the processor's. This is your opportunity to ensure that it is clear which party is doing what in areas where both have responsibility like security. It also gives you a contractual remedy for damages if the customer fails to perform (even if you cannot get any indemnity protection);
• be ready for negotiation of GDPR compliant processing clauses. Whilst the GDPR sets out certain points that must be covered, there is leeway and the ability to shape the clause to the types of services being provided;
• carry out diligence on your supply chain. It is your responsibility to ensure that all your sub-processors are capable of being GDPR compliant. You will be liable to your customers for your sub-processors' failings and actions. Customers may want to see evidence of your diligence to satisfy themselves that they can comply with the principle of accountability.

SaaS providers

If you provide access to a software application as a cloud service, you will be a processor, so everything set out above in relation to PaaS providers above is relevant, except that the nature of your services will be different. Therefore the level of assistance that you will need to give to customers relating to data subject rights and security will be higher and more involved.

Key actions for SaaS providers:

• decide how to cost in the price of compliance with GDPR. Should this be built into the price of the service or chargeable separately depending on the level and complexity of assistance and compliance?
• Decide how to resource and approach the extended data subject rights. For example, can you build access to and modification of personal data into systems through dashboards and portals so that data subjects can effectively help themselves to their data? Or will you need to train a customer services team to manually effect requests for copies of data, amendments, deletions etc?
• Decide how to tackle joint obligations such as security and international transfers. Operationally who will make decisions? Contractually who will take the risk of the actual security being deemed insufficient by a regulator?

Managed service provider

Regulators have acknowledged that some service providers have a greater degree of control and freedom in how data is used in order to provide a service. These providers will actually be controllers in their own right. Sophisticated outsourcing services could fall into this bucket, or professional service providers operating in a cloud environment.

The distinction between who is a processor and who is a controller has not changed under GDPR. If you are on the borderline, now is the time to conduct a thorough analysis to determine and record why you believe you are just a processor and not a controller. The consequence of getting that wrong is a fine for failing to meet the controller's obligations, which is likely to attract fines at the higher end of the spectrum.

Controllers clearly bear the full brunt of the GDPR requirements and the principles, including accountability.

Points to consider where you are a service provider who is a controller:

• How will privacy notices for both you and the customer be presented without confusing data subjects? Where you are truly joint controllers, the GDPR requires it to be very clear to data subjects about what entity is doing what and how they can enforce their data subject rights, but even if you are not joint controllers, both parties' processing activities will need to be clear in order to be transparent.
• Related to privacy notices is being clear with data subjects how they enforce their rights and which entity they need to deal with. Providers should consider how their systems interact with the customer's to ensure that operationally data is consistent.
• If there is a breach, both parties will have a duty to report to the regulator, and possibly to data subjects as well. This could put a provider in an awkward position commercially if the customer does not believe that a breach should be reported, or wants to limit disclosure to the regulator.
• Watch the relationship between data protection issues and confidentiality. Just because a provider is a controller does not mean that you are free to do whatever you want with the data that you process as a customer is still likely to view this as "their" data and confidential. For example, if you intended to run big data style analytics on data that you process across customers in similar sectors in order to gain insights into overarching trends, other restrictions in the contract could restrict or prevent that.

The GDPR come into force on 25 May 2018, so with just a year to go, now is definitely the time to create action plans in order to become compliant.