CSA Code of Conduct for GDPR Compliance (CSA GDPR CoC)


    CSA Code of Conduct for GDPR Compliance (CSA GDPR CoC)

    Privacy Level Agreement Working Group 2018

    The risk-based approach to data protection embedded in the GDPR has far-reaching consequences for Cloud data privacy. In 2018, the Cloud Security Alliance (CSA) issued the Code of Conduct (CoC) for GDPR Compliance with the aim of becoming a horizontal tool for compliance across sectors and domains. The CoC is addressed to all stakeholders interested in cloud computing.

    Last Updated: July 30, 2019

  • General

    The CoC is mainly focused on risk-based legal requirements for the protection of personal data in cloud domains. However, the CoC is not only based on the mandatory legal provisions. The Code also reflects relevant interpretations from authoritative bodies and best practises developed thus far (for example the guidelines for the interpretation of certain concepts drafted by Article 29 Working Party; and, the ENISA Technical Guidelines for the implementation of security measures for Digital Service Providers).

    Based on these foundations, the GDPR is intended to focus on both ends of the cloud environment. On the one hand, this tool facilitates Cloud Service Providers (CSPs) to self-assess their compliance with data protection legislation. On the other hand, cloud service consumers will be able to evaluate the level of protection offered by different CSPs thus facilitating their due diligence before engaging a CSP. As such, the CoC provides both a solution for GPDR compliance and transparency guidelines for appropriate disclosure of the level of protection offered.

    The CoC is based on two components: (a) a Privacy Level Agreement Code of Practise (PLA CoP), and (b) associated certification schemes and adherence mechanisms. Whereas the former specifies legal requirements laid down in the GDPR, adoption of the latter provides evidence that CSPs have actually adopted security programs that adequately protect data from threats that were previously identified in risk assessments and DPIAs.

    The CoC is structured in three parts:

    • part 1 lays down the scope, objectives, methodology, and assumptions;
    • part 2 describes the PLA CoP and its provisions;
    • part 3 outlines the PLA’s governance structure and mechanisms of adherence to this Code of Conduct.

    The CoC deals only with Business-to-Business (B2B) scenarios. Therefore it considers cloud service consumers as companies (rather than individuals or consumers). The CoC considers two types of customer scenarios: (a) the customer is a data controller and the CSP is a data processor; and, (b) where both consumers and CSPs are controllers. Nevertheless, the working group acknowledges that there could be more complex scenarios with hybrid situations (e.g. where both consumers and CSPs are data processors). In addition, the CoC was drafted to provide enough flexibility to adapt to EU Member States specific / sector-specific requirements, and, to consider the extra-territorial scope of the GDPR.

    The CoC also provides a list of items that cloud service consumers may have to consider when conducting internal and external due diligence assessments. When a controller intends to move personal data to the cloud (i.e., becoming a customer of cloud services) this entity will need to carry out internal due diligence. When carrying out their internal due diligence, entities may have to consider:

    • Defining requirements concerning their security and data protection compliance.
    • Mapping the data, processes, and services that they will move to the cloud.
    • Reviewing its own internal security and data protection practices and restrictions (e.g. pre-existing contracts, applicable laws, guidelines and best practices).
    • Risk assessments (e.g. DPIAs).
    • Identifying the relevant security controls and certifications that are useful/required to achieve adequate protection.
    • Allocating responsibilities for security controls implementations by identifying which controls are under their direct governance, and those that are under the responsibility of the CSP.
    • Identifying those activities of their service providers that they need to monitor, and how will this be achieved.

    When a controller intends to move personal data to the cloud (i.e., becoming a customer of cloud services) this entity will also need to carry out external due diligence. When carrying out their external due diligence, entities may have to consider:

    • Assessing whether the chosen CSP (and its subcontractors) fulfils the customer’s data protection requirements.
    • Determining whether the CSP holds any relevant certifications.
    • Understanding how to monitor the security controls and practices implemented by the CSP.

    The baseline of the CoC is the mandatory applicable EU personal data protection framework. However, the CoC takes into consideration other important opinions and guidelines that reflect the relevant interpretation by the European supervisory authorities(i.e. Article 29 WP) and related best practises developed by relevant Agencies (ENISA). In addition, the CoC is open-ended in the sense that: it leaves room to point out to other documents; it allows leeway to provide further clarification concerning the subject and time-frame for the cloud services to be provided; it clarifies the extent, manner and types of personal data to be processed by the CSP.

  • Lawfulness, Fairness and Nondiscrimination

    Lawfulness of the processing of personal data by CSPs depends on their adherence to the basic data protection principles laid down in Article 5 of the GDPR. This section examines the principles of lawfulness, fairness and non-discrimination in the cloud environment:

    • Lawfulness: personal data should be processed within the limits marked by EU and Member State data protection legislation. The latter is particularly relevant for those aspects on which Member States are afforded leeway to legislate beyond what is mandated by the GDPR (e.g., the age of consent, restrictions to data subject rights, further processing operations in the public interest, etc.). Attach to this principle, subcontractors have a legal obligation to disclose specific information (see section on transparency).
    • Fairness: the information disclosed by data controllers and processors should not mislead data subjects, it should be accurate and should place data subjects in a position to exercise their rights and seek a legal remedy where necessary. For this reason, CSPs have to be clear and open about their practices. The Cloud environment places more layers between data subjects and their personal information. Transparency is an essential condition for processing operations to be considered fair and lawful. Transparency requires from controllers and processors to be open concerning the details of the actors processing personal data, the purpose of processing, the source of the personal data (if it is collected indirectly), the extent of the processing, the types of data being processed, and the legal basis on which the processing is justified, the potential risks involved, the existence of data subject rights and the mechanisms available to exercise those rights. This information ought to be easily accessible and provided in a clear and plain manner (for more details, see section on Transparency and Free Access).
    • Nondiscrimination: in a cloud environment this principle is closely related to the hotly debated topic of net neutrality. On the early days the Internet, developments were based on the principles of non-discrimination and openness, which meant that ISPs had to provide equal access and speed to all applications and users. As the Internet keeps developing, this feature has changed because of the increased development of latency-sensitive applications that need to use more bandwidth to operate (e.g. Voice over Internet Protocols). As a result, ISPs have a more active role on the management of the quality of service as they increasingly have to make decisions to maintain operativity. Proponents of net neutrality advocate for data on the Internet to be moved impartially, regardless of the content, source or destination of the data being received and transferred. Proponents of net neutrality advocate for the implementation of laws regulating the dynamics between ISPs on one hand, and Service Providers (e.g. CSPs) and Content Providers on the other.

    CSA CoC and the PLA CoP are useful tools provided by well-established accreditation mechanism for CSPs to demonstrate fairness and transparency. In addition, the Cloud Security Alliance’s STAR framework is a well-established accreditation mechanism for CSPs to provide security assurances in the cloud. STAR encompasses self-assessments, 3rd party certifications and continuous monitoring.

  • Transparency

    Transparency is fundamentally related to the fairness and lawfulness of processing operations. Transparent processing is about being clear, open and honest with data subjects about the purpose, means and actors involved in the processing operations. The obligation to be transparent has to flow down to all actors actively involved in the processing operations. When more than one entity is involved in the processing of personal data (e.g. processors and sub-processors) all actors must be transparent with each other. In a cloud computing environment, there is some information that CSPs ought to disclose to cloud customers — depending on their role as controllers or processors — so that they can assess the pros and cons of adopting a cloud service.

    Below, we list by topic all the information that CSPs shall disclose to cloud customers in compliance with the PLA CoP:

    Contact details

    (CSPs acting as) both controllers and processors alike shall disclose the following contact information:

    • identity, name, address, email address, telephone number and place of establishment;
    • identity and contact details of local representative(s) (e.g. name, address, email address, and telephone number of a representative established in an EU Member State).
    • the role of each CSP that takes part in the processing activities (i.e. controller, joint controller, processor or sub-processor);
    • the contact details of the relevant DPO. Where there is no DPO, the name and contact details of the person to whom the customer may address all privacy-related requests;
    • the information and contact details of the Information Security Officer (ISO). Where there is no ISO, the name and contact details of the person to whom the customer may address all security-related requests.

    General processing information.

    CSPs acting as controllers shall disclose the following information:

    • categories of personal data that will be processed;
    • purpose(s) of the processing linked to the necessary legal basis to legally carry out the processing operations (including legitimate interests pursued by the controller or a third party). When relying on a legitimate interest, the controller shall identify the legitimate interest pursued by the controller or by a third party;
    • mention the possibility to withdraw consent at any time where applicable. Withdrawal of consent does not affect the lawfulness of the processing operations carried out prior to the withdrawal of consent;
    • the right to lodge a complaint with a DPA;
    • recipients and categories of recipients if the data is to be shared with or disclosed to third parties;
    • the existence and availability of mechanisms to exercise data subject rights (access, rectification, erasure, objection, and data portability);
    • if the controller intends to transfer the personal data to a third country or an international organisation, the controller shall specify whether there is an adequacy decision by the European Commission. If there is no adequacy decision the controller shall identify the suitable safeguards that have been implemented and the means by which to obtain a copy of them;
    • provide information concerning storage limitation (the foreseen period during which the data will be processed). Where this is not possible, the controller shall identify the criteria used to determine the storage period;
    • whether it is a contractual or a legal requirement to provide the requested personal data, and the potential consequences of failure to provide such data;
    • information concerning automated decision-making and/or profiling (if applicable), including the existence of automated decision-making, information about the logic involved in this type of processing, the significance of the envisaged consequences of such processing for the data subject;
    • information about any further processing intended and identify the new purpose. This information ought to be provided prior to any further processing.
    • any indirect collection of personal data (if applicable), the source of the data, and/or a specification concerning whether the data has was collected from publicly accessible sources;
    • details concerning the specific activities that are conducted to provide the agreed cloud service(s) (e.g., data storage), those activities conducted at the customer’s request (e.g., report production) and those conducted at the CSP’s initiative (e.g., backup, disaster recovery, fraud monitoring).

    CSPs acting as processors shall disclose the extent and modalities in which the customer-data controller can issue its binding instructions to the CSP-data processor.

    (CSPs acting as) both controllers and processors shall specify the manner in which cloud customers will be informed about changes to the cloud services (e.g. implementation or removal of functions).

    Personal data location.

    (CSPs acting as) both controllers and processors shall specify the location(s) of all data centres or other data processing locations (by country) where personal data may be processed, and in particular, the place and format or modalities where the data may be stored, mirrored, backed-up, and recovered.


    There is some information that the CSP ought to disclose where subcontractors will be engaged to carry out certain processing activities.

    1. It is the obligation of processors to declare the following to cloud customers:
    • the CSP will not engage another processor without prior specific (or general) written authorisation of the cloud customer;
    •  by way of a binding legal act (contract or otherwise) the processor shall declare how the CSP imposes on other (sub-)processors the same data protection obligations stipulated between the CSP and the cloud customer. In particular, the processor shall provide details concerning the guarantees to implement appropriate technical and organisational measures in order to meet EU data protection requirements;
    • that the processor remains fully liable to the cloud customer for the performance of other (sub-)processors’ obligations, in case the other (sub-)processors fail to fulfil their data protection obligations.
    1. (CSPs acting as) both controllers and processors shall identify:
    • any and all subcontractors and sub-processors that (may) participate in the processing operations;
    • the chain of accountabilities and responsibilities used to ensure that data protection requirements are met; and,
    • the procedures used to inform the cloud customer of any intended changes concerning the addition or replacement of subcontractors or sub-processors. In this case, customers ought to be informed that they have the right to object to such changes or to terminate the contract.

    Installation of software on the system of the cloud customer.

    (CSPs acting as) both controllers and processors shall indicate:

    • whether the provision of the service requires the installation of software on the cloud customer’s system (e.g., browser plug-ins); and,
    • the software’s implications from a data protection and data security point of view.

    Data processing contract (or other binding legal act)

    The CSP acting as processor ought to share with cloud customers:

    • the model data processing contract (or other binding legal act) which will govern the processing carried out by the CSP on behalf of the cloud customer; and,
    • set out the subject matter and duration of the processing, the type of personal data and categories of data subjects and the obligations and rights of the cloud customer.

    The CSP acting as processor ought to share with cloud customers (by means of a contract or other legal act) that the CSP commits to:

    • process personal data only upon documented instructions from the cloud customer, including with regard to transfers of personal data to a third country or an international organisation;
    •  inform the cloud customer prior to any transfer to third countries or international organisations, where such a transfer of personal data is required by Union or Member State law on grounds of public interest;
    • ensure that persons authorised to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality and that they do not process personal data except upon instructions from the cloud customer;
    • take all measures required by applicable EU law;
    • respect the conditions for engaging another (sub-)processor;
    • assist the cloud customer(by appropriate technical and organisational means) to respond to requests for exercising data subjects’ rights;
    • assist the cloud customer in ensuring obligations related to compliance with security requirements, obligations resulting from breach and security incidents, and to carry out Data Protection Impact Assessments;
    • delete or return all personal data to cloud customer after the end of the provision of services relating to processing, and delete existing copies (unless otherwise provided by Union or Member State law); and,
    • make available to the cloud customer all information necessary to demonstrate compliance with relevant data protection obligations, and allow for and contribute to audits.

    Legally required disclosure

    (CSPs acting as) both controllers and processors shall indicate to the cloud customers:

    • whether the cloud customer can request the CSP to comply with specific sectoral legislation; and,
      the mechanism available for cloud customers to request compliance with sectoral legislation.
  • Purpose Specification, Use Limitation and Suitability

    The principle of purpose limitation, as laid down in Article 5.1(b) of the GDPR, requires all personal data to be collected and processed for ‘specified, explicit and legitimate purposes and not further processed in a way that is incompatible with those purposes’. After the processing purpose(s) has been defined, the cloud customer must only process the personal data collected for reasons that are compatible with the original purpose identified. Data controllers ought to record the original purpose(s) and log each processing operation in their records in order to keep track on processing operations and to assess whether they are compatible with the purpose(s) originally laid down. Processing of personal data that is incompatible with the initial purpose(s) identified is deemed illegal. Therefore recordkeeping by the cloud customer and CSP comes is an effective tool to avoid illegal processing of personal data.

    In the context of a cloud environment, cloud customers (the initial controller) ought to determine the purpose(s) of the processing before any personal data about individuals is collected and handed to the CSP for processing. In addition, the controller must ensure that personal data is not processed for further purposes by the CSP or its subcontractors. Article 29 WP noted in opinion 05/2012 (on Cloud Computing) that a cloud scenario may potentially involve a large number of subcontractors. The more actors involved in the processing operations, the higher the risk of processing personal data for further incompatible purposes. Therefore, in a cloud environment context, controllers should consider that the risk of further incompatible processing is quite high. For example, in a cloud environment, several resources are shared between different tenants (e.g. memory, storage, networks, etc.).

    Cloud customers should implement mechanisms to mitigate this risk. One such way to mitigate the risk of further incompatible processing of personal data is to include in the contract — agreed between the CSP and the cloud consumer — relevant mechanisms to this end. Relevant contractual mechanisms include all available technical and organisational measures to avoid further incompatible processing, assurances of proper recordkeeping, and implementation of auditing mechanisms to evaluate all processing operations carried out by the employees and subcontractors of the CSP.

    Article 29 WP identified “isolation” as an adequate measure to mitigate the risk of further incompatible processing. In their opinion 05/2012, Article 29WP noted that “isolation” is meant to address the further incompatible processing risk through the implementation of proper governance of the rights and roles for accessing personal data which, ought to be reviewed on a regular basis. Governance of access and processing rights should include measures such as:

    1. Avoid implementation of roles with excessive rights (e.g. no user should be authorised to access the entire environment).
    2. Enable the lest privilege principle (i.e. administrators and users should only be able to access data that is necessary for their legitimate processing purpose.
    3. Enable technical measures:
      • hardening of hypervisors, and
      • implementation of adequate management of shared physical resources.
  • Data Minimisation, Storage Limitation and Accuracy

    In compliance with article 5.1(e) of the GDPR, personal data should allow identification of the data subjects concerned only for as long as it is necessary for achieving the processing purpose(s). Personal data may be stored for longer periods insofar as it is a legal requirement (e.g. in compliance with fiscal or business law) or it is done pursuant to article 89 of the GDPR. Either way, this is allowed within very limited circumstances and provided that appropriate safeguards have been implemented. Once the meaningful retention period has expired, controllers ought to proceed to the restitution or deletion of the personal data concerned.

    In this regard, both controllers and processors ought to have retention policies, timelines and conditions for returning the personal data once the cloud service comes to an end. In the context of the cloud environment, it is the obligation of (CSPs acting as) both controllers and processors to:

    • describe to cloud customers their retention policies, timelines and conditions for returning (or deleting) personal data upon termination of the cloud service;

    • describe the retention policies of their subcontractors, as well as the timelines and conditions for returning (or deleting) personal data upon termination of the cloud service.

    This description should include an indication of:

    • the time period for which the personal data will or may be retained, or if that is not possible, the criteria used to determine such a period;

    • whether the cloud customer can request the CSP to comply with specific statutory retention periods (i.e. in compliance with sectoral legislation);

    • the procedure for returning to the cloud customer the relevant personal data in a format that allows portability, migration and/or transfer-back;

    • the methods available or used to delete the personal data;

    • whether the data may be retained by the CSP upon termination of the contract, or after the cloud customer has deleted the data;

    • (in case data may be retained) the specific reason that justifies the retention of the data;

    • the retention period during which the CSP will hold on to the data.

  • Security and Prevention

    This security section of the PLA CoP is based on opinion 05/2012 of the Article 29 Working Party (Art29 WP) on cloud computing. In this opinion, the Art29 WP highlighted security risks associated to the delivery of computing resources over the Internet (e.g., servers, network equipment, memory, data-centre facilities, etc.), which arise from the fact that cloud customers relinquish exclusive control of the data they process. In particular, concerning security, the Art29 WP identified the potential loss of integrity, availability and confidentiality of the data being processed in the cloud as security risks to be addressed by CSPs.

    In addition, in the context of Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union (the NIS Directive), cloud computing services are considered Digital Service Providers that are subject to the scope of this Directive where they provide any service for remuneration, at a distance, by electronic means and at the individual request of a recipient of service,s.

    Therefore, the CSA invites CSPs to consider and follow the ENISA guidelines and to adhere to relevant codes of conduct and certifications mechanisms in order for CSPs to provide evidence of their data security compliance.

    Thus, (in compliance with Article 32 of the GDPR) taking into account the state of the art, costs of implementation and the nature, scope, context and purposes of processing, as well and the risk of varying likelihood and severity for the rights and freedoms of natural persons, the CSPs acting as both controllers and processors should:

    1. Specify to cloud customers the technical, physical and organisational measures that are in place to protect personal data against accidental or unlawful destruction; or accidental loss, alteration, unauthorized use, unauthorised modification, disclosure or access; and against all
    other unlawful forms of processing.
    2. Describe to cloud customers the concrete processes, measures and methods implemented to ensure that the following safeguards have been taken into account:

    • Availability – refers to processes and measures to manage risk disruption and to prevent, detect, and react to incidents (e.g. backup Internet network links, redundancy and effective data backup, restore mechanisms and patch management);
    • Integrity – refers to methods by which CSPs ensure the integrity of personal data (e.g. detecting alterations to personal data by cryptographic mechanisms) detailing all data layers within the CSP;
    • Confidentiality – on one hand, it refers to technical methods implemented to assure that only authorised persons can access the data (e.g. pseudonymisation and encryption of “in transit” and “at rest” data; as well as authentication and authorisation mechanisms). And to contractual obligations in place on the other hand (e.g. confidentiality agreements and clauses, company policies and procedures binding upon the CSP, its employees and subcontractors);
    • Transparency – as part of their transparency obligations, CSPs have to be clear about the technical, physical and organisational measures in place to support transparency and to allow review by customers (see section on transparency);
    • Purpose limitation – refers to the modalities in which CSPs provide appropriate isolation to personal data (which has to be reviewed on a regular basis), access management based on the “least privilege” principle, hardening of hypervisors (i.e., computer software, firmware or hardware that creates and runs virtual machines), and proper management of shared resources wherever virtual machines are used to share physical resources among cloud customers;
    • Intervenability – this aspect refers to the methods by which CSPs enable data subject rights to access, rectification, erasure and restriction (see section on data subject rights);
    • Portability – this aspect refers to the methods by which CSPs enable the right to data portability (see section on data subject rights);
    • Accountability – this aspect refers to the documents wherein CSPs declare compliance with data protection obligations (see section on accountability and recordkeeping).

    In addition, CSPs acting as both controllers and processors ought to indicate to cloud customers the means by which cloud customers can monitor or audit first- and/or third parties in order to ensure that they have implemented the privacy and security measures detailed in the PLA. These auditing mechanisms ought to be available on an ongoing basis.

  • Accountability and Record Keeping

    Organisations must be able to provide evidence that they are compliant with Data Protection legislation. By showing that they are compliant with the data protection framework, data controllers and processors demonstrate that they are embedding data protection by design and by default into their business processes and operations.

    In order to be able to demonstrate that they have adopted and embedded a data protection culture in their blueprint, CSPs have certain accountability obligations depending on their role as controllers or processors within the cloud environment.

    CSPs acting as controllers ought to maintain a record of all processing activities that fall within the scope of the CSP agreement. This record should be available to relevant DPAs upon request and must contain the following information:

    • name and contact details of the controller, the controller’s representative and the DPO if one has been designated;
    • if applicable, name and contact details of the joint-controller and their representative or DPO;
    •  a list of identified purposes of the processing;
    •  a description of the categories of data subjects and of the categories of personal data;
    •  categories of recipients to whom the personal data have been or will be disclosed, including recipients in third countries or international organisations;
    •  where the CSP foresees transfers of personal data to third countries or international organisations: identify the country or organisation and identify the suitable safeguards;
    •  the envisaged time limits for erasure of different categories of data;
    •  a general description of technical and organisational security measures.

    CSPs acting as processors shall confirm to cloud customers that they keep a record of all categories of processing activities carried out on behalf of a controller. This record should be available to relevant DPAs upon request and must contain the following information:

    • name and contact details of the processor or processors and of each controller on behalf of which the processor is acting;
    • where applicable, name and contact details of the controller’s or the processor’s representative, and the DPO;
    • categories of processing activities carried out on behalf of each controller;
    • an indication of whether there are transfers of personal data to third countries or international organisations foreseen;
    • If transfers of personal data to third countries are foreseen, the processor ought to identify the countries or international organisation(s) and provide documentation of suitable safeguards;
    • a general description of technical and organisational security measures.
  • Data Protection Officer

    Article 37 of the GDPR introduces a duty for organisations to appoint a Data Protection Officer (DPO) if they are a public authority or body, or if they carry out regular and systematic monitoring of data subjects on a large scale, or their core activities involve a large scale processing of special categories of personal information. Sometimes it may not be too obvious whether organisations should appoint a DPO. Where this is the case, organisations should consider appointing a DPO, unless it is obvious that appointing a DPO is not required. Article 29 WP, in Opinion 243/16 Rev.01, encourages, to appoint a DPO on a voluntary basis even if the appointment is not mandatory. In order to foster a culture of transparency and accountability, CSPs ought to keep records of the internal analysis carried out in order to determine whether it is required to appoint a DPO. Documentary evidence of the allocation of resources (e.g. appointment of a DPO) should be available upon request by the authorities.

    In the cloud environment, CSPs are most likely required to appoint a DPO, especially where CSPs are acting as controllers. Regardless of the high likelihood of CSPs having to appoint a DPO. Where CSPs have not appointed a DPO, the PLA CoP makes it clear that CSPs ought to appoint an individual responsible for addressing privacy matters raised by the cloud customer. The difference between an officially appointed DPO, and an individual responsible for addressing privacy requests from the cloud customer is that the latter would not be required to fulfil the requirements laid down in Article 37.5 of the GDPR (i.e. expert knowledge of data protection law and practice ) and would not have to fulfil the basic tasks for which a DPO is responsible under Article 39 of the GDPR (i.e. advisory role, monitoring compliance, liaison and cooperation with the relevant DPA(s).

    The PLA CoP stipulates that the Statement of Adherence to the Code of Practise ought to be signed by the appointed DPO. Where a DPO has not been appointed, the legal representative of the CSP is the one responsible for the signing the Statement of Adherence (not the individual responsible for addressing the requests of the cloud consumer).

  • Privacy by Design and by Default

    This is a component of the data protection framework that may also be referred to as the ‘technical and organisational measures’ that data controllers are required to implement as part of their approach to the data protection obligations imposed on them. This is the step that enables data controllers to appropriately embed data protection principles into their products, business, and processes. Privacy by Design and by Default applies to:

    • the planning and execution stages of new developments;
    • ongoing operation of such developments to effectively embed privacy and data protection principles throughout the entire lifecycle of the processing operations (from collection to erasure or portability);
    • embedding data protection principles, data subject rights and controller/processor obligations at the R&D stage when developing new products — particularly digital products, services, or technologies;

    The PLA CoP enables CSPs in this regard by guiding them in their efforts to implement appropriate technical and organisational measures and to embed data protection principles. Thus, promoting an iterative privacy culture.


    As part of their internal due diligence, cloud customers ought to evaluate the likelihood of risks to fundamental rights and freedoms of data subjects that are posed by the processing operations carried out in the cloud environment. One such way to assess those risks is to carry out a DPIA to the extent required by Article 35 of the GDPR. To read more about mandatory DPIAs, click here.

    It is the responsibility of the cloud customer to carry out a DPIA prior to engaging a CSP. The risks related to engaging a particular CSP to carry out certain processing operations on behalf of the cloud customer should be factored into the DPIA. CSPs ought to assist the cloud customer, by appropriate technical and organisational means, to carry out a DPIA. In addition, the data processing contract on which the provision of cloud services is based should contain a description detailing the manner in which the CSP will assist the cloud customer with this task.

  • Data Subject Rights

    The CSPs will cooperate with the cloud customers to enable them to effectively guarantee the exercise of data subjects’ rights: rights of access, rectification, erasure (right to be forgotten), restriction of processing, and portability (portability, migration and transfer back).

    Rights of access, rectification and erasure

    CSPs must collaborate with cloud customers to ensure data subjects can exercise their rights. Moreover, as explained in the accountability and recordkeeping section, CSPs acting as controllers must inform the cloud customers about the existence and availability of mechanisms whereby data subjects can access their personal data, rectify the data if necessary, and request that their data be deleted.

    Right to data portability (portability, migration and transfer back)

    CSPs acting as both controllers and processors shall specify and describe to cloud customers:

    1. How the CSP assures data portability, in terms of the capability to transmit personal data in a
      structured, commonly used, machine-readable and interoperable format to:

    (a) the cloud customer (transfer back);
    (b) data subjects (portability);
    (c) another service provider (migration) by means of — e.g. — downloadable applications, APIs, or other interfaces or tools.

    1. How and at what cost will the CSP assist customers in the possible migration or transfer back.

    Right to the restriction of processing: because data subjects have the right to restrict the processing of their personal data, CSPs acting as both controllers and processors ought to implement mechanisms to enable data subjects to exercise this right. In this regard CSPs acting as both controllers and processors shall specify and describe to cloud customers:

    • How the possibility of restricting the processing of personal data is granted.
    • That where the processing has been restricted, with the exception of storage, personal data can only be processed if:

    (a) the data subject has consented; or,
    (b) the processing is necessary for the establishment, exercise or defence
    of legal claims;
    (c) the processing is necessary for the protection of the rights of another natural or legal person;
    (d) There are important reasons for the public interest to the European Union or a Member State.

  • Vendor Management

    The GDPR stipulates vendor management responsibilities in Articles 24, 28, 29, and 46. There is shared liability for controllers engaging vendors to process data on their behalf (e.g. CSPs). Controllers ought to have the correct protections in place and must flow down this responsibility to their contractors and sub-contractors by means of legally binding agreements. This is of great relevance in a cloud environment where a number of processors and sub-processors may be engaged to process data on behalf of a cloud customer. For this reason, the CSA and the PLA working groups have issued a Code of Conduct and a Code of Practise to which CSAs can adhere in an effort to help cloud customers evaluate whether a specific cloud service is suitable to their needs and circumstances. In addition, the PLA CoP and the PLA [V3] Template are useful to help flow down controller responsibilities to processors and sub-processors (be aware that before accessing the resources in the hyperlinks you will have to fill in a short questionnaire).

  • Cross-border Data Transfers & Data Localisation

    Controllers and processors in a CSP arrangement offering services to cloud customers ought to be transparent concerning the localisation of the data, and their intentions to transfer, back-up or recovery across borders.

    Data localisation: as mentioned in the section on transparency, (CSPs acting as) both controllers and processors shall specify the location(s) of all data centres or other data processing locations (by country) where personal data may be processed, and in particular, where and how data may be stored, mirrored, backed up, and recovered.

    Data transfers: (CSPs acting as) both controllers and processors shall indicate whether data is to be transferred, backed up and/or recovered across borders. In addition, the CSP shall indicate to the cloud customer whether said transfers are to take place as part of their regular processing operations, or as a response to an emergency (e.g. incident response).
    Where a transfer intended by the CSP is restricted by EU law, (CSPs acting as) both controllers and processors shall identify the legal grounds for the transfer (including onward transfers through several layers of subcontractors. Said legal grounds may be adequacy decisions (issued by the European Commission, model contracts or standard data protection clauses, approved codes of conduct or other certification mechanisms, binding corporate rules, or mechanisms such as the Privacy Shield.

  • Incident and Breach

    In compliance with articles 5.1(f) and 32 of the GDPR, both controllers and processors shall safeguard the integrity and availability of personal data during their processing operations.

    Personal data is processed securely if appropriate technical and organisational mechanisms have been implemented in order to ensure a level of security proportionate to any potential risks. However, there is no ultimate level of security. No one-size-fits-all for the potential risks to personal data. Even where appropriate technical and organisational security measures are implemented, personal data may be at risk from sophisticated attacks (e.g. social engineering, hacking, internal risks, etc.) resulting in a security breach. In the context of the PLA CoP, a ‘personal data breach’ is defined as a security incident leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data processed in connection with the provision of a service provided by a CSP.

    As we constantly see on the news, there is no infallible security mechanism, and organisations are constantly hit by attacks resulting in negative effects to the privacy of individuals (e.g. unauthorised access to, and disclosure of, personal data). For this reason, apart from security measures, controllers must also implement a procedure detailing appropriate responses to personal data breaches. Moreover, controllers should flow down their security responsibilities to organisations processing personal data on their behalf (processors).

    In relation to potential incidents and breaches, the PLA CoP details a few obligations for controllers and processors.

    CSPs acting as controllers ought to specify to cloud customers:

    1. the manner in which DPAs will be informed of personal data security breaches within the 72-hour period of becoming aware of a breach as mandated by the GDPR;
    2. The manner in which data subjects are to be informed — without undue delay — when a security breach is likely to result in a high risk to the rights and freedoms of individuals.

    A shared obligation of controllers and processors

    In addition, (CSPs acting as) both controllers and processors ought to specify to cloud customers the manner in which the cloud customers will be informed of personal data breaches affecting the customer’s data being processed by the CSP and/or its subcontractors.

    Contents of the breach communication to cloud customers

    (CSPs acting as) both controllers and processors shall make sure that the communication of a breach to cloud customers should include at least:

    1. A description of the nature of the personal data breach, including (where possible):
      • The categories of personal data concerned (extent of breach); and,
      • The number of records concerned.
    2. Name and contact details of the DPO or relevant contact point who can provide further information.
    3. A description of the possible consequences of the breach.
    4. A description of:
      • the steps that have been taken to address the breach;
      • the measures implemented to mitigate the potential negative effects of the breach.
  • Enforcement (Governance)

    The CoC for GDPR compliance falls within an evolving landscape, whereby all parties and certification schemes must continuously develop security and privacy measures to ensure that regulatory requirements are always met. The constant evolution of security and privacy measures requires a proper governance structure. The implementation of a proper governance structure will help ensure consistency, control and adequate implementation of all necessary changes.

    There are three essential elements that ought to be considered when implementing a governance structure pursuant to this CoC:

    • technical components that will be affected by changes to the legal, regulatory and technological landscapes, as well as by internal changes within the Cloud Security Alliance (CSA). This element has four components: PLA Code of Practise, CoC certification scheme and mechanism of adherence, a Code of Ethics, and the Working Groups charters and documentation;
    • key Governance bodies, their roles, and responsibilities.
    • processes implementing relevant activities related to the definition, revision and implementation of the CoC.

    Below we review in detail each component:

    Technical components

    1. The PLA Code of Practise: this is the fundamental technical component that (1) identifies the relevant personal data protection compliance requirements in the EU, and (2) defines clauses and controls to manage controls with requirements.
    2. Certification schemes and codes of adherence: being a component of the CSA certification framework, this element defines the scope, objectives, mechanisms, requirements, processes and rules that have been defined in a Statement of Adherence to the CSA in line with the principles, policies and guidelines laid down in the CoC and its subsequent updates developed by the Open Certification Frameworks (OCFs). The Statement of Adherence shall be signed by the organisation’s legal representative(s) or appointed DPO, and supported by the PLA template. This Statement ought to include:
    • the scope and objectives of certification;
    •  auditing rules and mechanisms;
    • auditor qualification process;
    • conditions for revocation and complaint mechanisms; and,
    • certification fees.
    • Validation of the Statement. This validation can be presented in the form of a self-attestation (which may be voluntarily published indicating that the organisation has adopted the code) or in the form of a third-party certification, which is obtained through validation by a qualified auditing partner (see definitions in the ‘General’ section). The validation process shall include an assessment of:
      • the correct use of the CoC; and,
      • the accuracy of the information issued.

    All of the requirements in the PLA Code of Practise ought to be taken into account (as opposed to only one chosen subset).

    1. Code of Ethics (CoE): is a statement that is binding for all members, officers, employees (full-time and part-time), contractors, and volunteers within the organisation that is implementing the CoC. This document encompasses 7 sections and is based on the Code of Ethics of the CSA (which should also be included in the agreement):
    • scope;
    • definitions;
    • principles;
    • acknowledgement of the Code of Ethics;
    • the moment of entry into force and publicity;
    • oversight and procedures to support the Code of Ethics;
    • review and changes.

    The CSA Code of Ethics is reviewed and updated annually by the CSA Board of Directors. Any and all changes to the Code of Ethics shall be communicated to all CSA Parties.

    1. PLA and OCF Working Groups’ Charters: these documents state the background, practical use, scope and objectives, structure and functioning, membership, decision-making procedure, deliverables, and expiration date of the charter of each working group.

    The PLA Working Group is responsible for defining, approving and updating changes to the technical standard and the PLA Code of Practise (currently in its third version, i.e., PLA [V3]). This body also provides expert opinion to the CSA when complaints about CoC Self-Attestation or Certification are submitted. The PLA Code of Conduct is intended to be used as the structure for the creation of an appendix to a Cloud Services Agreement that would describe the level of privacy and data protection that the CSP undertakes to commit to provide and maintain with respect to the personal data that its customer will provide to the CSP and process through the CSP’s service(s).
    The OCF is an industry initiative to allow global and trusted certification of cloud providers by addressing the gaps within the IT ecosystem that are inhibiting market adoption of secure and reliable cloud services. The OCF Working Group is the body responsible for the definition of the certification scheme(s) adopted within the CSA STAR Program. The OCF WG defines, reviews and approves changes in certification schemes already existing within the CSA OCF/STAR Program; and defines, reviews and approves any new certification scheme(e.g., the CoC certification scheme).

    The Charters for both Working Groups are set to be valid until 31 March 2019.

    Governance Bodies.

    Governance of the CoC and its components is a shared responsibility between the PLA and the OCF Working Groups on one hand, and the CSA on the other. In addition to the aforementioned functions and objectives of the (PLA and OCF) Working Groups, the CSA supports and oversees implementation of the CoC certification scheme as a component of the STAR Program. Some of the relevant governance activities of the CSA include, but are not limited to: maintaining a public registry of issued CoC certificates, maintaining a public registry of qualified CoC auditors, maintaining a website with information and guidelines, reviewing CoC self-attestations, verifying minimum requirements are met, maintaining a mechanism for filing complaints, verifying complaints and taking appropriate actions, providing guidance for managing conflicts, etc.

    The CoC governance bodies collaborate and support national data protection authorities (DPAs) in matters related to the protection of personal data processed in the cloud. Upon request by a national DPA, or the European Data Protection Board (EDPB), the CoC governance bodies may:

    1. Collaborate with the DPA or EDPB by providing:
    • guidelines and awareness initiatives addressed to users of cloud computing services;
    • advice on opinions to be issued regarding relevant data protection laws.
    1. Engage in supporting actions:
    • promoting awareness (among self-attested and certified companies) about measures issued by national DPAs;
    • provide DPAs with all information and evidence available in CSA when a DPA carries out an inspection of a self-attested or certified company.
    • review the certification of a company subject to a DPA enforcement action, and withdraw the certification if necessary.

    Governance process and related activities

    The governance process defines the relationship between the governing bodies and their compliance activities. The governance activities encompass four review processes and activities related to the publication of Statements of Adherence, the issuing of CoC marks, and management of complaints.

    1. PLA CoP review process: the PLA CoP is subject to periodic reviews in order to address changes to the data protection legislative landscape. This review process falls under the purview of the PLA Working Group and can be triggered by any member of the CSA community. In order to help cloud service providers cope with the legislative transition, the current version of the PLA CoP [V3] focuses on both the previous legislative framework (Directive 95/46 EC) and the GDPR.
    2. CoC Certification Review Process: the OCF Working Group is responsible for triggering reviews of the CoC certification schemes, assessment and approval of review requests, and implementation of the proposed changes. The OCF Working Group itself may propose changes to both the CSA STAR Program and the CoC certification scheme.
    3. CoC marks issuing, Statement of Adherence publication and complaints management: CSA is responsible for,
    • reviewing that requirements for CoC self-attestation have been met, for verifying the validity of relevant complaints submitted by any
      third party, and for taking the relevant actions where the requirements are not met or if the complaint is deemed valid (i.e. request an amendment to the CoC self-attestation or remove the self-attestation and revoke the mark). In the case of validation, CSA is also responsible for publishing the CoC self-attestation at the online CSA Registry.
    • Publishing any CoC certification in the STAR registry where a qualified auditor has informed the CSA that the auditee has passed the assessment.
    • Notifying a qualified auditor that issued a certification if a related complaint is filed and take into account feedback issued by the auditor.
    1. CoE review process: The Statement of Ethics is reviewed and updated annually by the CSA Board of Directors. Any changes to the Statement of Ethics shall be communicated to all CSA Parties.
    2. PLA and OCF Working Groups’ charters documents review process. CSA is responsible for approving any OCF and PLA charter revision and extension requests.
  • Codes of Conduct and Certifications

    The GDPR promotes self-regulation through the heightened focus on codes of conduct and certification schemes. In a context where self-regulation is promoted among actors that are increasingly incentivised to use cloud computing technologies to manage and process their data the CSA CoC for GDPR compliance and the PLA CoP (together with its [V3] Template) contain mechanisms that allow CSPs to (a) provide evidence of their data processing practises, (b) provide evidence of the appropriate implementation of necessary technical and organisational means to comply with data protection legislation, and (c) to enable authorised bodies of experts to carry out mandatory monitoring of compliance with the CoC and the CoP by controllers and processors (pursuant to Article 41 of the GDPR).

Want to learn more? Login to the full DataGuidance platform.

About OneTrust

OneTrust is the #1 most widely used privacy, security and third-party risk technology platform trusted by more than 3,000 companies to comply with the CCPA, GDPR, ISO27001 and hundreds of the world’s privacy and security laws. OneTrust's three primary offerings include OneTrust Privacy Management Software, OneTrust PreferenceChoice™ consent and preference management software, and OneTrust Vendorpedia™ third-party risk management software and vendor risk exchange. To learn more, visit OneTrust.com or connect on LinkedIn, Twitter and Facebook.