Cloud providers: How the forthcoming GDPR will affect you
The forthcoming General Data Protection Regulation (GDPR) heralds large-scale change for business, not least for those entities who process personal data on behalf of others.
Known currently as data processors, these entities (now to be known simply as processors), will from 25 May 2018 have to comply with the GDPR where they are processing the personal data of EU citizens. A failure to do so will expose the cloud provider to direct enforcement and potentially large fines imposed by the Information Commissioner. This is the headline change - there are many more, which we describe below in summary form. Many of your activities are likely to be processor activities, but there will also be some where you are a controller.
1. Processors directly regulated - as noted above, the GDPR moves the position from processors only having obligations under contract to having direct legal obligations, as well as being subject to regulatory review and scrutiny. The GDPR also applies outside the EU to non-EU entities, to the extent that the data being processed relates to EU citizens - where they are being monitored or services are being targeted at them.
a. You will therefore need to review the applicable parts of the GDPR and prepare a compliance programme to be ready for May 2018.
2. Data protection by design and default - and data minimisation - while primarily controller responsibilities, these are still issues cloud providers should be aware of, especially in respect of their activities as controllers (see below). Clearly the security measures taken by cloud providers will be an integral part of their customers' IT architecture and therefore will be scrutinised by customers to ensure that the customers themselves are achieving data protection by design. For example, the cloud provider must ensure that all data held on behalf of a customer is completely expunged from its systems upon the customer's request or shortly following contract termination to enable the customer to comply with its duty under the GDPR to ensure it only retains data for so long as it is required. Providing self-service tools to your customers to completely erase personal data held on your systems may be a preferred approach, subject to the appropriate warnings/safeguards regarding the use of such tools.
3. Accountability - processors will also have to document the steps they take to comply with GDPR, and keep records of the policies, procedures, processes and decisions they take relating to processing personal data. If a breach and/or enforcement action occurs, this is one of the things a regulator may take into account.
a. You will therefore need to prepare processes to prepare for GDPR and implement a team to deal with this accountability requirement and to assure compliance post-May 2018.
4. Security measures - the measures to be taken will depend on the nature of data being processed, and cloud providers will need to provide sufficient guarantees about the measures adopted to protect the data. These may be codes of conduct or by certification mechanisms if these are agreed (for example, possibly the TRUSTe enterprise privacy certification). Potentially, cloud providers will need to perform a risks assessment for each customer's requirements or give the customer the necessary tools to undertake its own assessment, taking into account the bespoke security measures (such as pseudonymisation and encryption) that the cloud provider is able to provide.
a. You will need a prepared statement about the nature of your services and the security measures adopted (both technical and organisational).
b. You will either need to seek assurances from your customer around the nature of data being processed or pro-actively state which categories of data particular services are suitable for.
c. The security measures should be set out in the contract or clearly referenced - one of the things the GDPR does not do is set out who has the veto if this cannot be agreed, and this should be added to contracts to clarify this right.
d. The GDPR also refers to the need for encryption, where appropriate, and the extent of your encryption technologies should be clearly explained to your customers.
5. Additional requirements for processing contracts - the GDPR sets out additional requirements to include in data processing contracts. These include specifying more clearly the nature of the data, the security measures applicable, the location(s) of the data and sub-processors involved. A key change under the GDPR is the need for the controller's consent to the appointment of sub-processors. However, the GDPR does state that an open consent to subcontracting processing can be agreed upfront and so cloud providers will be wise to do so as a matter of course. Be aware that the 'same' data protection obligations as set out in the contract between the customer and the cloud provider needs to be flowed down to a sub-processor and the clouds provider will be liable to the customer for the acts of the sub processor. This places cloud providers in an unenviable position of either aligning their terms strictly with the terms offered by the likes of Amazon or Microsoft (who typically perform the role of sub processor) and risk failing to differentiate their service from the likes of AWS and Azure, or risk non-compliance and potential fines for failing to do so. At the end of the contract, the controller must have the option for the data to be returned to it or securely destroyed, unless the processor must retain it for compliance with member state law.
a. You should review current contracts as well as templates for new contracts to ensure that they meet GDPR requirements, and make appropriate changes.
b. Where there is flexibility or doubt in the GDPR, you should use this to position yourself - e.g. you should have a standard position of controllers adopting general consents to sub-processors - that will afford you greater flexibility in the delivery of the services.
c. In your contracts with sub-processors, you should update these to include standard terms for processing (reflecting the position agreed with controllers*) and deal with the additional information, liability and breach reporting issues. * clearly this will be difficult as there will be multiple different controllers involved in commodity / shared cloud services and therefore a risk-based view may need to be taken to have 'materially' the same terms.
6. Breach reporting - there are now mandatory breach reporting requirements in the GDPR at three levels - 1. From controller to regulator; 2. From controller to data subject and 3. From processor to controller. The GDPR is vague as to the timescales for this latter reporting - we would recommend contracts are made clear as to when the clock starts and how long there is to report a breach. The scope of what is a breach is also very wide - ranging from a potential issue to a massive data breach.
a. You should ensure that your contracts state the breach reporting timescales and what is expected from yourselves.
7. Data Protection Officer - many organisations undertaking more sophisticated or more sensitive processing will need to appoint a Data Protection Officer. There are legal requirements as to the suitability of this person and stipulations as to what they must do to regulate data processing within the organisation.
a. You should review whether a DPO is required, and if so consider who this will be (or considered an outsource service appointment). Note that the DPO must operate independently and cannot be dismissed or penalised for performing their task.
8. Data Subjects' rights enhanced - the rights of individuals have been increased under GDPR, including a right of data portability, enhanced (and free) rights of subject access to a copy of their personal data. Fair processing notices (privacy policies) must be clearer and more comprehensive as well. Processors must assist controllers as far as possible to meet these enhanced requirements.
a. You should prepare to assist controllers in responding to such requests.
9. As an employer/marketer/profiling - where you hold personal data for your own purposes, e.g. for legal reasons, as an employer or as an instigator of direct marketing, you will also be a controller. This will also be the case if you undertake data analytics / profiling for your own purposes using identifiable data (as opposed to on behalf of your customers). Controllers have greater obligations than processors under the GDPR, not least keeping more detailed records of the processing activities undertaken and the legal basis on which this is permitted, and being subject to higher levels of sanctions.
a. You should consider the instances in which you are processing data as a controller, and prepare additional processes to deal with the additional compliance requirements. The accountability principle also applies to controllers.
10. Overseas data transfers - the GDPR also requires diligence to be undertaken regarding data transfers, and to ensure that there are adequate legal mechanisms in place to ensure that personal data is protected. This isn't new (and was put into the spotlight when the former Safe Harbor data transfer regime was struck down), but the obligations to tell individuals and to provide copies of data transfer documents is new. While Safe Harbor's replacement (Privacy Shield) is currently valid, the process is currently undergoing its first annual review, and has not been without some suggestion of challenge.
a. You should prepare a listing of contracts with data transfers and ensure that each has an adequate mechanism to transfer data outside the EEA.
b. You should update privacy policies to reflect these rights, and the other changes GDPR requires, where you are acting as a controller.