Insights

Personal Data Protection in Cloud Computing

1. Introduction

As we are in and still moving towards a technology-driven era, more and more companies are relying on cloud computing for their business operations every day. An increase in reliance on cloud computing also results in the accession of data protection concerns. This article explains some of the basic rules and terms in data protection regulations of the EU and Türkiye, mainly the General Data Protection Regulation (“GDPR”)[1] and Law on Protection of Personal Data No. 6698 (“LPPD”),[2] and interprets how these can apply to cloud service providers (“CSPs”).

1. Personal Data vs. Non-Personal Data

To determine whether CSPs are in the scope of GDPR or LPPD, keeping in mind the material and territorial scopes of both regulations, the definitions of “processing”, “personal data”, “anonymization” and “pseudonymization” should be assessed carefully. The terms “processing” and “personal data” are defined almost identically in GDPR and LPPD and according to these definitions personal data means “any information relating to an identified or identifiable natural person” and processing means “any operation or set of operations which is performed on personal data”. By merely looking at these definitions, it can be said that whether the CSPs are in the scope of GDPR and LPPD can be summed up in one question: do the CSPs hold the ability to identify a data subject or at least, make the data subject identifiable?

According to Recital 26 of GDPR anonymization is defined as “information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable”. and pseudonymization is defined as “Personal data … which could be attributed to a natural person by the use of additional information.” Although a definition for pseudonymization does not exist under LPPD, anonymization is defined similarly in the auxiliary legislations of LPPD.

The concept of “anonymization” is highly debated to this day. As Recital 26 of GDPR states that “to determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used” it can be argued that the chance of data becoming “accidentally” identifiable in the hands of another person or the chance that the data could become identifiable by using “illegal” methods does not affect the concept of anonymization. As stated by Article 29 Working Party, “even if identification of certain data subjects may take place despite all those protocols and measures [cryptographic, irreversible hashing] (due to unforeseeable circumstances such as accidental matching of qualities of the data subject that reveal his/her identity), the information processed by the original controller may not be considered to relate to identified or identifiable individuals taking account of all the means likely reasonably to be used by the controller or by any other person”.[3]

The ability of CSPs to identify a data subject mainly depends on the contract between the CSP and the customer, also the technical measures put in place by the customer before transferring the data to the cloud. However, the ability of CSPs to identify a data subject varies for each given case and therefore it would be beneficial to look at different scenarios to determine whether the CSPs are processing personal data or non-personal data.

As can be observed from the table above, in most cases, the CSPs are in the scope of data protection regulations. Only if the CSPs are prohibited from accessing personal data (e.g., via the contracts concluded with the customers), the applicability of data protection regulations to CSPs becomes debatable.

The issue of encryption, pseudonymization and anonymization is still debated to this day, even amongst various data protection authorities. European Data Protection Supervisor,[4] Spanish,[5] and Irish[6] data protection authorities view that encryption is a pseudonymization tool since it can either be reversed with a key or will allow a singling out through brute force attacks or data leaks.

However according to Information Commissioner’s Office,[7] “where an organisation converts personal data into an anonymised form and discloses it, this will not amount to a disclosure of personal data. This is the case even though the organisation disclosing the data still holds the other data that would allow re-identification to take place” and according to the Court of Justice of the European Union “ [regarding means likely reasonably to be used to identify the data subject] that would not be the case if the identification of the data subject was prohibited by law or practically impossible on account of the fact that it requires a disproportionate effort in terms of time, cost and man-power, so that the risk of identification appears in reality to be insignificant.”[8]

In light of the above, if (i) a customer uses state-of-the-art encryption while uploading the data to the cloud, (ii) the CSP does not have any means to access the decryption key, (iii) the CSP is prohibited by contract to request access to data and (iv) the CSP does not have an alternative method to single out the encrypted data, the characteristic of the data in question becomes a highly debatable issue, even amongst various data protection authorities. Therefore, professional legal and technical advice regarding whether data is pseudonymized or anonymized should be obtained for each individual case.

• The Roles of Controller and Processor

Where CSPs process personal data, it is important to determine whether CSPs are identified as “controllers” or “processors”. These terms are defined similarly between GDPR and LPPD and accordingly controller is identified as “the natural or legal person who determines the purposes and means of the processing of personal data” while the processor is recognized as “the natural or legal person who processes personal data on behalf of the controller”.

It is pertinent to note that merely designating a CSP as a processor in a contract does not automatically make that CSP a processor as is summed up in the Guidelines published by European Data Protection Board (“EDPB”).[9] Thus, the factual processing role of the CSPs vis-à-vis the reason and the means that the CSP is processing personal data will be of utmost importance in determining whether the CSP is a controller or a processor.

According to EDPB, if a party determines the “essential means” of processing, which are (i) the type of personal data that are processed, (ii) the duration of the processing, (iii) the categories of recipients, and (iv) the categories of data subjects, that party should be regarded as a controller.[10] Therefore, the CSPs must look at their contracts with their customers and ascertain whether or not they determine one of the above specified “essential means” while processing personal data.

The concepts of “essential and non-essential means” were debated in a recent decision of the Turkish Data Protection Authority (“DPA”), which was focused on same-sector companies’ joint procurement of blacklisting software from a software provider. In its decision, the Turkish DPA concluded that since the customers of the blacklisting software can see the data uploaded to the system by other customers, all the customers and the software provider are joint controllers.[11] Instead of mere accessibility, the Turkish DPA should have analyzed who decides that the uploaded data will be shared among other customers and whether or not the data uploader could restrict this type of data transfer.

In addition to the above, attention should be given to the activities conducted by the CSPs with the uploaded customer data. If the CSP only provides storage space for the customer, it would be difficult to argue that the CSP itself acts as a controller. On the other hand, in cases where the CSP conducts analytical activities or data mining on the data for its own interest and profit, here the role of the CSP would switch to the controller regarding these activities. However, in light of a recent decision of the Turkish DPA,[12] if CSPs provide the technical infrastructure of a software (e.g., for analytical or data mining purposes) but the customer decides on which data and whose data can be entered into the software, to whom the data will be transferred, or how the data will be managed and stored, the CSPs will be a processor for this relationship. Therefore, the role of the CSP is highly dependent on factual variables. A case-by-case analysis must be conducted to precisely determine whether the CSP is a controller or a processor.     

1. Localization and Network Security Obligations in Cloud Computing

This part of the paper will focus on the questions of i) are there any security obligations for CSPs, ii) can the CSPs keep the customer data in another country besides the one where the customer is located and iii) if the answer to the second question is yes, how could this transfer occur?

For the EU part, in addition to the security obligations laid down by GDPR, the network security obligations are specifically regulated under Directive 2016/1148 and Directive 2022/2555 (“NIS Directives”) and application of NIS Directives brings the cybersecurity and incident notification requirements for CSPs. Yet, an equivalent capture-all regulation to the NIS Directives does not exist under Turkish law, the security and localization requirements are regulated on a sectoral basis.

The closest counterpart of the NIS Directives under Turkish law can be found in the e-communications sector, which extensively regulates the operators’ network and information security obligations.[13] Besides, a similar obligation exists in other sectors such as banking, fintech, health, energy, e-commerce, and the capital market. Additionally, the Turkish DPA published a Guideline on Personal Data Security (Technical and Organizational Measures), which obliges controllers to take the necessary measures to prevent unlawful access to personal data, Computer Emergency Response Center, an organization within the Information and Communication Technologies Authority, circulated sector specific lists of security measures that must be taken by those acting in that particular sector (e.g. e-commerce) and the Presidency of Türkiye issued the Decree on Information and Communication Security Measures, No. 2019/12, which obliges the public bodies to adhere to the measures specified in the decree itself, which also includes localization.      

Apart from network security, in Türkiye, regulations in sectors like banking, fintech, and the capital market restrict the cross-border transfer of personal data. According to the relevant regulations, the primary and secondary systems used by companies in these sectors must be stored locally.[14] Therefore, CSPs must assess whether the services they provide to their customers are within the scope of “primary and secondary systems” as defined in sector-specific regulations and if yes, the systems of CSPs must be located in Türkiye. For systems that are not within the scope of “primary and secondary systems”, the application of personal data protection regulations should be assessed to ensure a lawful transfer of the data. As explained in the first part, in case the data within the CSPs systems do not amount to personal data, naturally, personal data protection regulations would not be applicable. However, if it is personal data and the systems of CSPs are not located in the same country (EEA for GDPR) as the customer, which is usually the case for cloud services, the cross-border transfer regime of GDPR or LPPD would apply to the customer and CSPs.  

1. Cross-Border Transfer of Personal Data

Cross-border data transfer (“CBDT”) is one of the areas where GDPR and LPPD get separated from each other yet, soon, it is expected for the CBDT regime of LPPD to be amended in line with the rules of GDPR.

According to Chapter V of GDPR, CBDT is lawfully possible if (i) an adequacy decision exists for the data importing country, (ii) for instances where an adequacy decision does not exist, one of the appropriate safeguards has been put in place (e.g., SCCs, BCRs), or (iii) for instances where both an adequacy decision or an appropriate safeguard does not exist, the existence of one of the art. 49 GDPR derogations in the given transfer.

For LPPD, CBDT can be conducted on a legal basis if (i) adequate protection is provided (similar to the adequacy decision) in the country where the data importer is located, (ii) a commitment for adequate protection is provided in writing by the data controllers in Türkiye and the relevant foreign country, and the Turkish DPA’s approval for this commitment is obtained or, (iii) the data subject’s explicit consent is collected. However, as of today, the Turkish DPA has not declared a single country as providing adequate protection and the approval procedure before the DPA is a cumbersome procedure and usually takes a substantial amount of time. In the last six years, only five commitments have been approved by the Turkish DPA. Due to these reasons, the current CBDT regime is in a gridlock until the CBDT regime of LPPD is harmonized with that in the GDPR.

1. Conclusion

Although the basic data protection concepts are interpreted similarly between GDPR and LPPD, the network security obligations and CBDT regimes are where the legislations foresee different rules and provisions. If utmost care is not shown to these provisions, a CSP may find itself violating the relevant legislation and a possible administrative fine can be issued due to this infringement. Obtaining the advice of a local counsel before engaging in cloud services in that country may be in the best interest of CSPs and their potential customers.

[1] Published in Official Journal of the European Union numbered L 119 and dated 4.5.2016, p. 1–88.

[2] Published in the Official Gazette numbered 29677 and dated 07.04.2016.

[3] WP136 Opinion 4/2007 on the concept of personal data p. 20.

[4] EDPS-AEPD Joint Paper on 10 Misunderstandings Related to Anonymization p. 3.

[5] AEPD Encryption and Privacy: Encryption in the GDPR, published 15 November 2019.

[6] DPC Guidance on Anonymisation and Pseudonymisation, published June 2019.

[7] ICO Anonymisation: Managing Data Protection Risk Code of Practice p. 13.

[8] CJEU C-582/14 Patrick Breyer v Bundesrepublik Deutschland paras. 45-46.

[9] EDPB Guidelines 07/2020 on the concepts of controller and processor in the GDPR p.9.

[10] EDPB Guidelines 07/2020 on the concepts of controller and processor in the GDPR p.15.

[11] Turkish DPA’s Principal Decision Numbered 2021/1304 and Dated 23/12/2021.

[12] Turkish DPA’s Decision Numbered 2021/1303 and Dated 23/12/2021.

[13] Electronic Communications Law, No. 5809 & The Regulation of Network and Information Security in the Electronic Communications Sector, published in the Official Gazette numbered 29059 and dated 13.07.2014.

[14] The primary and secondary systems are defined in sectoral legislation (e.g., art. 3/1-i and 3/1-ee of Communique on Payment and E-Money Institutions’ Information Security and Payment Service Providers’ Data Sharing Services in the Payment Services Sector).