June 16, 2017,
EU General Data Protection Regulation, Henley Business School, News, Thought Leadership 
No comments
Regardless of the size of the organisation, Data Controllers are entering arrangements with Cloud Service Providers in the hope of improving customer service levels coupled with reductions in processing costs and enhanced personal data security.
It’s important for a Data Controller to understand the different Cloud Service models to select the one that’s best aligned with its risk appetite and business requirements.
Many are often apprehensive about cloud security, however cloud storage with a reputable provider will likely be more secure than on-premises storage because protecting data is the core function of the business.
Unlike a Data Controller that has the entire organisation to consider, a Cloud Service Provider’s only business is to securely process a Data Controller’s data and it can’t afford to lose a Data Controller’s confidence as this would terminate any relationship quickly.
For two decades, individuals and organisations have taken advantage of the benefits of the cloud – online and on-demand IT services that can be accessed from virtually anywhere.
Three Types of Cloud Service Models
There are three main types of cloud service models:
- Infrastructure as a Service (IaaS)
- Platform as a Service (PaaS)
- Software as a Service (SaaS).
Infrastructure as a Service (IaaS)
IaaS is the most flexible cloud service model that can be customised to meet the needs and requirements of the Data Controller. This ’outer layer’ of cloud services provides the ‘building blocks’ for the cloud in the form of virtualized computer hardware – servers, storage and network capability – that a Data Controller uses to build and run its own IT platform with greater scalability.
It’s available on-demand, often on a self-service basis. It can even use it to create a virtual data centre.
Examples include Amazon Web Services (AWS) and Google Compute Engine.
Platform as a Service (PaaS)
PaaS – the ‘middle layer’ of cloud services – provides the environment in which a Data Controller can develop and deploy its software. It provides virtual access to an external operating system, server hardware, infrastructure and storage. The Data Controller can use the resources as necessary and focus on the business side of IT – app development, deployment and scalability.
Example include Google App engine.
Software as a Service (SaaS)
SaaS – the ‘inner layer’ of cloud services – is the most familiar of the family of cloud services.
SaaS provides a virtual point of access to software developed by a third party and running on virtual servers, platforms and infrastructure.
A Data Controller doesn’t need to manage, install, or upgrade the software internally. Rather, the business accesses it through a subscription service and thereby reduces the cost and hassle of software ownership and management.
Examples include Microsoft Office 365, Evernote Business, Salesforce.com.
History of Cloud Service Providers
From the first cloud-based email service (Microsoft’s Hotmail) in 1996 to the first Software as a Service (Salesforce.com) platform in 1999 to the seemingly ubiquitous Microsoft Office 365 and client-focused apps today, the cloud is already well integrated into the life of the Data Subject and value chain of the Data Controller.
A Cloud Service Provider is a Data Processor under the GDPR
A Cloud Service Provider will be considered a Data Processor under the EU General Data Protection Regulation (GDPR) if it provides data processing services (e.g. storage) on behalf of the Data Controller without determining the purposes and means of processing (Art.4(7) and (8), GDPR).
It’s worth remembering that the definition of processing is very broad and simply viewing or granting access to personal data constitutes processing (Art.4(2), GDPR). The typical terms and conditions of many cloud service contracts go further than simply processing on behalf of a Data Controller. Many contracts reserve the right for the Cloud Service Provider to use or access the personal data for its own purposes. This is particularly common in Software as a Service (SaaS) contracts, though this is changing.
By jointly determining the purposes and means of processing, a Data Controller and its Cloud Service Provider become Joint Data Controllers (Art.26(1), GDPR). This triggers additional significant duties and responsibilities for the Data Processor that wasn’t contemplated when it entered the agreement with the Data Controller in the first place.
A Cloud Service Provider that offers personal data processing services directly to Data Subjects such as Facebook and Drop Box will be Data Controller (Art.4(7), GDPR). If a Data Controller permits a Cloud Service Provider to outsource a portion of data processing activities to another entity, that entity will become a sub-Data Processor.
For example, a SaaS provider may run its app on a third party’s platform through a PaaS arrangement. The SaaS provider will be the Data Processor, while the PaaS provider will be the sub-Data Processor (Art.28(2) and Art.29, GDPR).
If a Cloud Service Provider determines the purposes and means for processing personal data without the Data Controller’s agreement or awareness (contrary to the GDPR), the Cloud Service Provider will be considered a Joint Data Controller. In addition to having Joint Data Controller obligations, it may also be subject to regulatory sanctions (Art.28(10) and Art.29, GDPR).
A Cloud Service Provider that treats a Data Subject’s personal data as their private property can no longer be regarded as business as usual and will be in breach of the GDPR where that personal data is processed in the absence of a Data Privacy Notice.
The contractual position for the Data Controller
A Data Controller using a third-party public or external Cloud Service Provider is effectively relinquishing control of its personal data holdings to a third party. This is problematic under the duties and responsibilities imposed on it by the GDPR.
While the Data Controller is effectively outsourcing Data Protection by Design and by Default (DPDD) and Security of Processing obligations to a third party, legal responsibility remains with the Data Controller (Art.24(1), GDPR).
A Data Controller is under a legal duty to take a risk-based approach to the processing of personal data and must assess the risk when entering any contractual relationship with a Data Processor.
Lingering questions can haunt a Data Controller’s Data Protection Officer (DPO):
- Where’s the data located?
- How’s it stored?
- Who can access it?
- How’s it protected?
- What if there’s a service disruption, a breach, or permanent data loss?
- Where’s the back-up? Is it within the EU or in an adequate country?
- How easily can a Data Controller respond to Data Subject rights requests for personal data processed in the cloud?
- When the service ends or a Data Controller switches to a different Cloud Service Provider, will the personal data be truly erased or will it persist, leaving a Data Controller and the personal data of the Data Subject exposed?
- How can I negotiate with a large Cloud Service Provider that doesn’t want to negotiate when I have no negotiating power (e.g. ‘take it or leave it’ terms and conditions?)
Leveraging the cost-saving benefits of the cloud while remaining GDPR-compliant is challenging for a Data Controller under traditional cloud business models and service-level agreements (SLAs).
Cloud services are typically:
- ready-built, ’take it or leave it’ commodities
- subscription-based/pay-as-you-go
- self-service
- based on standard terms and conditions that favour the Cloud Service Provider with rigid terms, sweeping exclusions of liability and the power for a Cloud Service Provider to make unilateral service changes without reference to the Data Controller.
Typically, these cloud service agreements purport to place all the risk and liability on the shoulders of the Data Controller and though they promise security, they stop short of offering guarantees, so work on the basis of ‘buyer beware’ and use ‘at your own risk.’
This leaves the Data Controller with virtually no negotiating power with the Cloud Service Provider.
Cloud contracts typically allocate most or all risk related to security to the client and impose standard terms and conditions that are in contravention with the GDPR.
Any Data Controller using a Cloud Service Provider will need a guarantee in the agreement that it’s compliant with the GDPR, particularly as such an agreement is likely to run past 25 May 2018.
Top Tips for a Data Controller contracting with a Cloud Service Provider:
- Review existing Data Processor’s security and data protection practices to confirm whether it aligns with the GDPR or whether it’s on track to GDPR compliance. If the Cloud Service Provider can’t provide a convincing response to questions about GDPR compliance and GDPR-readiness, prepare an exit strategy and start shopping around for a new Data Processor.
- Re-negotiate contracts to include the mandatory provisions of Art.28(3), GDPR and terms specific to Data Controller’s needs. Start now to avoid last-minute challenges if contractual negotiations break down
- If existing contracts have not been re-negotiated by May 25, 2017, a Data Controller’s DPO should flag the issue with the Data Processor’s DPO for action. A DPO must be independent and can’t advise its client to violate the GDPR.
Cloud Service Providers must now comply with the GDPR
Cloud Service Providers will also be subject to the GDPR and now have the incentive to bring their practices in line with its requirements.
The subscription model of Cloud Service contracts creates a new relationship with the Data Controller that requires greater accountability. If a Data Controller’s not happy with the service, it can cancel the subscription.
The GDPR creates a paradigm shift in the Data Controller-Cloud Service Provider relationship. A Data Controller should leverage the new power dynamic to negotiate for better terms or shop around for providers that are poised for GDPR compliance.
Cloud providers competing for a Data Controller’s business will need to provide assurance of GDPR compliance and agree to the mandatory contractual terms (Art.28, GDPR). And the fact is, third-party Cloud Service Providers can’t afford to have security breaches or business disruption for fear of losing clients to other vendors.
And Cloud Service Providers are probably better positioned to handle security than a Data Controller’s internal tech team because that’s the nature of their business.
This is already happening with the Code of Conduct for Cloud Service Providers (CoC-CSP).
Cloud Service Providers such as IBM, Alibaba, Oracle and SAP are founding members of the General Assembly that established the CoC-CSP and related certification programs with the aim of “improving transparency and helping cloud customers understand how data protection issues are addressed by cloud service providers” and help cloud providers comply with the GDPR.
Meanwhile, Microsoft Cloud has made “Supporting your journey to compliance with the GDPR” a key part of its value proposition for services such as Azure and Dynamics 365. A DPO must still read the fine print. Without certification or approval under the GDPR, which will only be obtained after a rigorous review of the codes and certification mechanisms – a Data Controller can’t risk taking a cloud provider at its word.
In summary
A Data Controller should determine what sort of relationship it wants with its Cloud Service Provider, which model is appropriate and decide how to structure and manage the relationship, and enforce this under contract.
For information about the GDPR Transition Programme at Henley Business School, click here.
Recent Comments