The current state of affairs relating to cross-border transfers of personal data to third countries could be described as disproportionate, ineffective, and unforeseeable. Disproportionate because the CJEU has, in two separate judgements, concluded that the US law and practice does not provide essentially equivalent data protection. In spite of these invalidations of the main transfer mechanism, transfers to the US are not completely discontinued after the Schrems II judgement but mainly based on another legal basis.55 A legal basis that, in the case of EU–US transfers conducted by Meta Platforms, Inc., led to a 1.2 billion Euro fine.56

The current state could be characterized as ineffective because exporters of personal data approach the challenging problem of transfers to third countries through complex risk assessments of the laws and practices in the receiving third country when relying on SCCs as the transfer mechanism. These Transfer Impact Assessments could be described as both tedious and procedural for the exporters. Our supposition is that they might lead to ‘paper’ compliance, but not necessarily to improved data protection in the receiving third country.

Lastly, the current state of affairs could be described as unforeseeable for the exporters due to the changing nature of the rules, requirements, and recommendations relating to transfers of personal data out of the protected area.

Adequacy decisions and appropriate safeguards, read in the light of the interpretation of the CJEU, require the GDPR and the rights in the Charter to be ‘essentially’ implemented in a third country, either through diplomatic negotiations between the Commission and the third country or as a contract between the exporter and importer. Regarding the first alternative, it is unlikely that a third country with a different legal culture, legal system, and fundamental rights instruments would implement data protection rights in a manner ‘essentially’ equivalent to the level within the protected area. Regarding the latter, a contract between private parties could not bind third-country governmental access to transferred personal data.

In the following sections, attention is therefore drawn to whether (PETs) could safeguard the confidentiality and protection of personal data transferred to third countries and thereby provide for a more effective alternative in third-country transfers.

The role of PETs in third-country transfers

PETs are not defined in the GDPR. The European Union Agency for Cybersecurity (ENISA) defines PETs as a broad range of technologies that are designed for supporting privacy and data protection.57

An exporter of personal data relying on standard contractual clauses could be required, according to the SCC decision, to take both organizational and technical measures to ensure that a transfer to a third country is compliant with GDPR Chapter V interpreted in line with the Charter.58 Various PETs that have potential as such technical measures are discussed in the following sections.

Currently, technology could represent potential additional measures that the exporter of personal data could introduce in order to comply with the ‘essentially equivalent’ requirement. PETs could also have the potential to make GDPR compliance more effective; they can enforce key principles of data protection. Thus, a data-transfer agreement could indicate the use of a pre-approved set of technologies to be employed by both parties for protecting the personal data transferred, instead of being a lengthy, complicated set of different modules of contractual clauses.

This section presents technical measures that can enforce different principles of data processing: integrity and confidentiality, purpose limitation, data minimization, accuracy, and informational self-determination.59

For each presented technical measure, we discuss the concept and applicability of the solution in cross-border transfers to third countries. Every technical solution that protects personal data imposes restrictions on how this data are used and processed, decreasing the data utility for the controller or processor. So, for each presented solution, we also discuss the trade-off between the degree of utility that is offered to the processor and the degree of data protection offered to the data subject.

Lastly, we discuss the legal status of the transfer if the different technical measures are applied. The measures have the potential to either:

Render the processing outside the material scope of the transfer rules in Chapter V and thus also out of the scope of the regulation on the importers’ hands; or Provide essentially equivalent data protection in the receiving third country; or Secure the processing, however, not to an extent that alters the legal status of the transfer.

The section concludes with some general comments on the analysed technical measures in terms of the overall proportionality, efficiency, and foreseeability the application of the measures could offer.

PETs with potential to leave the transfer outside the scope of chapter V Before discussing different technical measures that might contribute to protecting personal data in crossborder transfers to third countries, it is important to define the scope of the regulation in relation to personal and non-personal data. These two legal concepts are important to discuss because they are relevant in the assessment of whether technical measures in the form of PETs render the transfer outside the scope of the transfer rules in Chapter V of the GDPR.

The GDPR and the principles of data protection apply to personal data, ie information relating to an identified or identifiable natural person.60 When personal data are anonymized, the link between the natural person and the data no longer exists. The GDPR and the principles of data protection do therefore not apply to anonymous information and if personal data is rendered anonymous in such a manner that natural persons are not or no longer identifiable from the data, the processing is left outside the scope of the GDPR and is regarded as non-personal data.61

When determining whether data is regarded as personal or non-personal and under or outside of the scope of the GDPR, the key element is an assessment of identifiability. To determine whether a natural person is still identifiable, an account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify a natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify a natural person, account should be taken of all objective factors, such as the cost of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and the technological developments.62

However, there is a non-settled scholarly debate and a divergence in the legal sources on the question of whether the GDPR regulates identifiability in an absolute or relative manner.63 Under the absolute manner of assessing identifiability, no risk of reidentifications is accepted. If there is a mere theoretical risk that someone somewhere could reverse-engineer the process and identify a natural person, the data should be regarded as personal data.64 The relative approach, on the other hand, accepts a theoretical risk of reidentification. The risk of reidentification is considered from the objective factors mentioned in Recital 26 GDPR in order to answer whether the data are regarded as personal data under the scope of the regulation or non-personal data outside the scope.

A recent judgement of April 2023 from the Eighth Chamber of the General Court regarding the concept of personal data in Regulation (EU) 2018/172565 might shed some light on the concept of personal data also under the GDPR.66 The disputed question, in essence, concerned whether sharing an alphanumeric code, related to an identifiable natural person, should be considered anonymous or pseudonymous data in the hand of the recipient when the information allowing reidentification was not shared. The General Court interpreted the definition of personal data in Regulation (EU) 2018/1725, which corresponds to the definition under the GDPR, in line with the Breyer judgement. The General Court does not provide a clear general answer to the question of whether information that can only be used to identify a specific individual when additional information, not possessed by the entity, is available, can be considered as personal data. However, the General Court concludes that the actual risk of reidentification must be assessed and that sharing of pseudonymous data where the repository necessary for identification is not shared does not automatically renders the data either anonymous or pseudonymous on the receiver’s hand. The judgement of the General Court is in line with the relative manner of assessing identifiability.

In the Judgement, data were shared but not transferred to a third country. Furthermore, the Judgement concerned Regulation 2018/1725 and not the GDPR. The Judgement of the General Court therefore has relevance but needs to be applied with some caution in relation to third-country transfers. Related to the third country problem, the judgement is relevant for the following scenario: The data transferred is identifiable for the exporter, but the exported data are processed in a manner where identifying natural persons requires information kept by the exporter in the protected area. The GDPR assesses the status of data, whether it is regarded as personal data or anonymized data, after the identifiability assessment. We argue that the identifiability assessment, in such a situation, is different depending on whether the exporter or importer is holding the data. We argue that, from the perspective of the importer in the third country holding the data, the relative manner of assessing identifiability in the GDPR could leave the transfer of data processed by the use of technical measures outside the scope of the transfer rules in Chapter V of the GDPR because the data are no longer linked to a natural person in the receiving third country without access to information kept by the exporter. 66 Case T-557/20 Single Resolution Board (SRB) v European Data Protection Supervisor ECLI:EU:T:2023:219 General Court (Eighth Chamber, Extended Composition). 67 Pseudonymization is defined under art 4(5) in Regulation (EU) 2016/679 as ‘the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is

In a situation where technical measures are applied to render the transfer outside the scope of the transfer rules in Chapter V of the GDPR the following elaboration is important to make: the processing of personal data in the protected area is, unquestionably, under the scope of the GDPR. When the technical safeguards are applied to the personal data by the exporter in the protected area prior to the export and identifiability of a natural person is not possible, the transfer may fall outside the scope of the transfer rules in Chapter V. The rationale behind this statement is that the definition of transfers from the EDPB is not fulfilled for such a processing operation. Point two of the definition of the EDPB is not fulfilled in such a scenario because the data made available for the importer does not fulfil the definition of personal data. An important disclaimer is that technical measures must be implemented on the personal data before the point of export. The objective of the transfer rules is to protect data subjects in the protected area from disproportionate data protection rules in a third-country jurisdiction. In a situation where the data transferred is not personal data, this purpose becomes inapplicable. The further reasoning behind why different PETs may cause the transfer to fall outside the transfer rules in Chapter V is elaborated under each of the sections analysing the different PETs. Pseudonymization as a technical safeguard in transfers to third countries Pseudonymization protects personal data by replacing the identifier between information in a data set and a natural person.67 Personal identifiers, for instance, a name, age, or an identification number, are replaced by a pseudonym, for instance, a random number or a hash, and the link between the identifier and the pseudonym is protected by keeping the additional information needed to identify the natural person separately and subject to technical and organizational safeguards.68

In relation to cross-border transfers to third countries, the applicability of pseudonymization could be illustrated by the use of an example. Suppose that a patient, an EU data subject, is employed with a wearable sensor that monitors blood pressure and heart rate. The wearable device sends data to servers in a third country for analysis before the result is reported to the patient’s doctor. The doctor needs to link the results from the analysis with the identity of the patient. However, the kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person’. 68 European Union Agency for Cybersecurity, ‘Deploying Pseudonymization Techniques (2022)’ <https://www.enisa.europa.eu/publications/deploy ing-pseudonymisation-techniques> accessed 13 July 2023. identity of the patient is not necessary to perform the analysis of the patient’s data in the third country. Pseudonymization could be applied to replace the name of the patient with a pseudonym, for instance, a number or a random hash. The number of random hash is transferred together with the sensor data to the third country. The analysis of the sensor data is performed and transferred back to the protected area. The linking between the result of the analysis and the identity of the natural person behind the pseudonym is then performed in the protected area.

The example above illustrates that pseudonymization could be applied to enhance the confidentiality of personal data and limit the identifiability of natural persons and thus contribute to the principle of data minimization in third-country transfer. To what extent could the pseudonymization of natural persons’ identifiers offer confidentiality protection? The level of confidentiality protection could also be illustrated with an example. Suppose that an online service provider in the protected area stores the following data from its users: time-stamp with the users’ time zone, IP address, type, and version of browser, set and preferences of natural languages in the browser settings, and the operating system of the user’s computer. The IP address is pseudonymized and kept in a repository by the controller or processor.

Now, suppose that the controller and processor wish to transfer the stored data to a third country for further storage in a cloud. Is the pseudonymization of the IP address sufficient to protect the data subject from reidentification attempts in the third country? The Panopticlick experiment has shown that even though the IP address is pseudonymized, information on timezone, language settings, type and version of the browser, and the operating system is sufficient to identify a browser and thus also a specific data subject.69

Unlike anonymization, pseudonymization is not a technique that renders the processing outside the material scope of the GDPR by default. Personal data that have undergone pseudonymization is still defined as personal data and pseudonymization is an example of an appropriate safeguard under Article 6(4)(e), data protection by design and by default under Article 25, and as a security measure under Article 32.

The recommendations on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data from the EDPB,70 also regard pseudonymization as an additional measure for essentially equivalent protection and not a measure that renders the processing on the importer’s hand outside the scope of the GDPR. The EDPB concludes that pseudonymization might represent a relevant additional measure for cross-border transfers to third countries. The conclusion from the EDPB is relevant for pseudonymization techniques that fulfil the following requirements: (i) the personal data can no longer be attributed to a specific data subject or used to single out the data subject in a larger group, (ii) the additional information necessary to identify the data subject is held exclusively by the exporter, (iii) disclosure or unauthorized use of the additional information is prevented by technical and organizational safeguards and (iv) the exporter has thoroughly analysed the data in question and taken into account any information that the authorities in the recipient third country may possess that the pseudonymized personal data cannot be attributed to an identified or identifiable natural person even if cross-referenced with such information.71

The recommendations from the EDPB call for the exporter to take into account ‘any information the authorities in the receiving third country may possess’ when considering whether pseudonymization is an efficient additional measure to secure personal data in a transfer to a third country.

The recommendations on pseudonymization as an additional safeguard in transfer to third countries from the EDPB and the definition of pseudonymization in Article 4(5) GDPR are somewhat different. While the definition in Article 4(5) presupposes that only information kept separately by the controller or processors should be assessed when evaluating whether natural persons are identifiable.72 Recommendation 01/2020 presupposes that the exporter of personal data should also assess the risk of indirect identification from information kept by third-country authorities when applying pseudonymization as a technical safeguard in transfers to third countries.

To conclude on the legal status of pseudonymization as a technical measure to safeguard transfers, the transfer of pseudonymized data may either contribute to essentially equivalent protection dependent on the specifics of the transfers such as the sensitivity of the personal data and the laws and practices in the receiving third country.73 In such a situation, the analysis of laws and practices in the receiving third country is necessary. Therefore, as an overall conclusion, pseudonymization as a technical measure would contribute to securing the transfers, but not alter the legal status of the transfers by default.

Sovereignty cloud models: moving the cloud servers to the protected area The overall concept in sovereign cloud models is that the physical infrastructures necessitating third-country transfers, such as servers, are moved from third countries to the protected area in the EEA. In a sovereign cloud environment, personal data reside in the protected area under the GDPR, making the requirements for transfer to third countries excessive. Sovereign cloud models are therefore a technique applied to not transfer data out of the protected area.74

Several exporters of personal data are exploring sovereign cloud models. For instance, Microsoft announced the launch of Microsoft Cloud for Sovereignty in July 2022.75 The new cloud solution is offered to public sector customers that need to guarantee that personal data are only processed in a given region, for instance in the protected area. Other technology companies have announced comparable products to mitigate the risk related to transferring personal data to third countries. For instance, Google’s sovereign control for Workspace products is such a service.76

The various sovereign cloud solutions incorporate different techniques to enforce personal data protection and confidentiality, including encryption and access controls. Nevertheless, the overall concept underlying such cloud infrastructures is to maintain the data within the jurisdictional boundaries of one specific geographical location. Consequently, the various sovereign cloud providers contend that they offer a solution where the transfer rules in Chapter V become inapplicable because the data are not transferred to a third country.77

The following paragraphs will discuss a legal issue when a controller or processor established in the Union makes use of a sovereign cloud solution: how should a controller or processor in the protected area assess the situation where personal data are processed on a sovereign cloud in the protected area and the cloud provider is registered in a third country or is an EU subsidiary of an enterprise registered in a third country?

To recapitulate, the GDPR does not define transfers out of the protected area. A common definition of such transfers is given in guidelines from the EDPB.78 In the situation where personal data are stored and processed in the protected area but the cloud provider is an enterprise registered in a third country, the situation is not regarded as a transfer under the EDPB’s guidelines.79

In the Council of Europe Convention for the Protection of Individuals with regard to Automatic Processing of Personal Data (Convention 108þ), crossborder transfers to third countries are defined as a process where the data are transferred to a recipient that is subject to the jurisdiction of a State that is not a party to Convention 108þ.80 The definition of transfers in Convention 108þ is further elaborated in the Draft Explanatory Report to the Convention.81 In the explanatory report, transborder data transfers are further explained as a process where ‘personal data are disclosed or made available to a recipient subject to the jurisdiction of another State or international organisation’.82 A transborder transfer under Convention 108þ would therefore cover also situations where personal data are made available to a jurisdiction of a non-party to the convention without the personal data being imported to the non-party state. Such a situation could occur when making personal data available on a cloud, even though the cloud server infrastructure is physically located in a state that is party to the Convention.83

Convention 108þ is an instrument of European data protection law as promulgated by the Council of Europe (CoE) and is closely linked to the right to data protection under Article 8 of the European Convention of Human Rights. Convention 108þ does therefore have relevance for the interpretation of the right to privacy and data protection in the Charter.84 Neither the GDPR nor the Convention has an explicit collision rule.85 However, the GDPR does not define transfers. The definition is based on a recommendation from the EDPB that is based on a judgement from the CJEU under the predecessor of the GDPR.86 The definition of transfers in Convention 108þ Article 14 could therefore represent a valid factor in the interpretation of a transfer in EU data protection law. This conclusion has to be elucidated. In Opinion of the Court 2/13, the CJEU concluded that the EU legal order constituted a distinct legal order and that the draft agreement regarding the EU accession to the ECHR was liable to affect the specific characteristics of EU law and its autonomy.87 Consequently, the relationship between EU law and CoE law could be described as one marked by a certain tension. However, in May 2023, the CoE and the European Commission published a revised agreement on the EU accession to the ECHR.88 The purpose of the revised agreement is to alleviate the concerns raised by the CJEU in opinion 2/13 regarding the autonomy of EU law. This recent development would, most likely, facilitate the future accession of the EU to the ECHR, and therefore also underscoring the relevance of Convention 108þ within the domain of EU data protection law.

In a German judgement from the Administrative Court in Wiesbaden from December 2021, the Court interpreted a situation similar to when a sovereign cloud is controlled by a third-country enterprise. The German Court concluded that even though the personal data never left the protected area under the GDPR, the situation could be defined as a transfer if the company processing the personal data is under the jurisdiction of a third country.89 The German administrative court did not assess the guidelines on transfers from the EDPB and the Court’s view does therefore not represent a homogeneously European interpretation of the GDPR.

The question of whether processing personal data in the protected area by a processor under the jurisdiction of a third country could be regarded as a transfer is also the subject of a non-settled scholarly debate.90

The question was adjudged by the French Conseil d’Etat in March 2021. Unlike the German Administrative Court, the French Court concluded that a platform processing personal data where the processing took place in the protected area by a Dutch subsidiary of a US corporation did not constitute a transfer of personal data to a third country.91 However, the Conseil d’Etat still assessed the risk of US authorities accessing personal data processed on the platform. The risk-based approach pursued by the Conseil d’Etat could entail that it is not that significant whether the situation is defined as a transfer to a third country or not since the Court assessed the risks of US authorities getting access to the personal data even after concluding that the processing was not defined as a transfer.

In the situation where the data reside in a sovereign cloud in Europe, but the cloud is controlled by a thirdcountry enterprise or a subsidiary of a third-country enterprise, several legal sources call for an assessment of the risks related to a potential non-authorized access to the personal data in the cloud by third-country authorities. In such a risk-based approach to the processing, relevant factors include both the nature of the personal data, the purpose of the processing, and technical safeguards, for instance, encryption and logs on data access.92

To conclude on the legal status of sovereign clouds in relation to transfers to third countries, a sovereign cloud solution is a technical measure with the potential to render the processing outside of the scope of the transfer rules in Chapter V of the GDPR if the cloud service provider is a company registered in the EEA. Both the legal status of the cloud in relation to the transfer rules and the risk of unauthorized access to personal data by authorities from third countries would depend on the nationality and jurisdiction of the cloud provider.

An example of a technical safeguard mentioned in the GDPR is data encryption.93 Encryption can be applied to enforce the confidentiality of the personal data, by making the data readable only to authorized principals. Encryption is one of the most widely used security measurements deployed by computer systems.

When users interact with their e-banking account or official governmental websites, or when sending messages, encryption is almost always used to protect the confidentiality of the users’ data.

Although encryption is widely adopted, there are certain assumptions that one needs to make when using it. These assumptions impact the level of data protection, the level of data utility, and the level of additional measures necessary in order to reach ‘essentially equivalent’ data protection if personal data are transferred outside the protected area. To be more specific, let us first give an overview of symmetric encryption.

This encryption procedure takes as input the piece of information to be protected, known as the plaintext, and a secret value, known as the secret key, and it returns a randomly looking sequence of bits, known as the ciphertext. The only efficient way in which the ciphertext can be converted back to the original plaintext is by invoking the corresponding decryption procedure with that ciphertext and that secret key. So, only those principals that know the secret key can decrypt the ciphertext. Consequently, encryption obscures the sensitive information for all principals but those that know the secret key. Figure 1 depicts the procedure described above.

The confidentiality protection that is provided by encryption is relative to principals that know the secret key since anyone that knows the key can always retrieve the sensitive information from the ciphertext. We consider two scenarios that differ in the assumption of who knows the secret key, and how this assumption influences the level of protection, utility, and the legal status of the cross-border transfer to a third country. For what follows, consider a user (ie data subject) in the protected area providing personal data to a processor in the Union (ie data exporter), which in turn makes the data accessible to a web service (ie data importer) based in a third country. The personal data are encrypted in its entirety

Symmetric Encryp on with a secret key, both for its transfer to the web service and for its storage within that web service. (i) User-side encryption. Assume that only the user knows the secret key. This entails that only the users can efficiently retrieve their personal data from the ciphertext; their personal data is not revealed to the exporter within the protected area or the importer in the third country. This technical solution provides high confidentiality protection. However, the high confidentiality protection comes at the cost of the low utility for both the exporter and importer of personal data. Here, the exporter and the web service access only the ciphertext and thus no useful processing can be applied to this obscured data, except for storing or forwarding it. Thus, this technical solution might be appropriate for web services that provide encrypted and robust cloud storage or peerto-peer communication. (ii) Server-side encryption. Assume the data subject, the exporter, and the web service importing the personal data in the third country know the secret key. This means that only these three parties can efficiently retrieve the user’s personal data. Specifically, adversaries that eavesdrop on the network communication between the data subject and the exporter or between the exporter and the importer in the third country might access the transferred ciphertexts, but cannot efficiently retrieve the encrypted sensitive data. So, server-side encryption ensures that the user’s personal data are only shared with the exporter and the importer and no one else, but it imposes no restrictions on how the web service utilizes that data. This implies that the data utility is high for the web service.

Regarding the principles of data protection, user-side and server-side encryption implicate different principles. Both techniques, to some extent, enhance the confidentiality of personal data by making the data only readable to authorized principals. However, user-side encryption limits the potential for the processor of personal data to process it, strengthening both the principles of data minimization and purpose limitation.

The two main different encryption techniques we described above, user-side and server-side encryption are met in real applications. Consider WhatsApp, a popular messaging application. WhatsApp offers end-to-end encryption between the communicating parties.94 This means that these parties encrypt the messages they exchange using a secret key only known to them. So, any personal information included in these messages is accessible only by the communicating parties, and no one else, including WhatsApp. This approach is closer to scenario (i) discussed above. The metadata of the communication, though, seems to be accessible to WhatsApp. This messaging service might know the parties that communicated when they communicated, and for how long. Metadata can be applied to identify an individual natural person and would therefore be included in the definition of personal data under GDPR Article 4(1) depending on the specifics of the case under question. So, if this metadata is subject to GDPR, then additional measurements need to be taken for its protection in cross-border transfers.

WhatsApp might be required by a third-country authority to terminate end-to-end encryption for users within the third country and share collected information with the authorities of the third country. This approach would be closer to scenario (ii). Specifically, Brazil intends to demand that WhatsApp support traceability95 for the exchanged messages, recording who communicate what and when. Such an intention is directly opposite to both the principle of data minimization, storage limitation, confidentiality, and proportionality in the GDPR. In the case where a Brazilian citizen is communicating with an EU citizen, the answer to the question of how WhatsApp will resolve the contradictory data protection requirements remains.

Consider now Gmail, the email application of Google. Here, emails are encrypted by a secret key that is known by both the user (ie client-side) and Gmail (ie serverside).96 So, this approach is closer to scenario (ii). Now, assume that an EU data subject sends an email containing sensitive personal data to a US user. This email will be ultimately stored on a US server. How is Gmail going to resolve the conflicting protection requirements between those that govern the EU-sent email and the USstored data?

These two real-life examples illustrate that if the secret key is accessible by the data importer in the third country of destination, encryption as an additional measure under the SCC decision could potentially represent a false sense of data protection, and server-side encryption would not be sufficient as an additional measure to reach ‘essentially equivalent’ protection is such situations.

The question of whether client-side encryption, where only the user accesses the secret key, as the first example above, is considered personal data under the GDPR is open for debate. As a starting point, encryption is regarded as a measure for secure processing under Article 32 GDPR and not an anonymization technique. Encrypted data are, therefore, regarded as personal data under the GDPR.

We argue that if personal data are encrypted before the point of export and the secret key is held in the protected area inaccessible to the importer in a receiving third country and if the encryption protocol is so strong that there is no means reasonably likely to be used to reverse the encrypted data back to personal data, the transfer is rendered outside the transfer rules in Chapter V.97

The decryption process in the protected area is still regarded as personal data processing. However, the transfer of the user-side encrypted data is not regarded as the transfer of personal data under the risk-based approach in Recital 26 because the importer cannot identify a natural person from the ciphertext alone.98 This understanding of user-side encryption and the scope of the transfer rules in Chapter V of the GDPR only applies if the encryption takes place prior to the point of export.

The conclusion on the legal status of encryption in relation to cross-border transfers of personal data is, therefore, different for user-side and server-side encryption. User-side encryption has the potential to derive the transfer of encrypted data to a third country outside the scope of the transfer rules in Chapter V of the GDPR.

Server-side encryption offers lower confidentiality protection, compared to user-side encryption. This means that the controller or processor exporting the personal data to the web service in the third country might need to take additional measures to ensure full GDPR compliance if the exporter is relying on SCC as a transfer tool and there are identified risks related to the laws and practices of the receiving third country.

Notice that, under server-side encryption, if the web service is subject to laws and practices under the jurisdiction of a third country that might require the acquisition of secret keys, then the user’s personal data are potentially accessible by the third country authorities, too. Across different jurisdictions, there are several examples of existing legislation that calls for encryption methods to implement mandatory backdoors that can access the encrypted ciphertext. One example of such anti-encryption legislation is the Australian Telecommunications and Other Legislation Amendment (Assistance and Access Act) from 2018.99 The amendment to the act requires telecommunications providers and other providers of server-side encryption to give technical assistance, including providing encryption keys, to Australian law enforcement agencies upon request. Another example is the non-binding call from the European Council in the Resolution on Encryption.100 These examples, and the current legislative trend of requiring access to secret keys for law enforcement and intelligence gathering purposes has the consequence that the effect of server-side encryption as a technical measure in third-country transfer might give a false sense of confidentiality protection for the personal data transferred.

Depending on the laws of the third country, one might therefore need to relax the assumption of who knows the secret key to include the authorities of the third country, further lowering the confidentiality protection and raising the risk relating to the transfer of personal server-side encrypted data. User-side encryption does not suffer from the problem relating to authority acquisition of secret keys.

The final conclusion of the legal status of transferring encrypted data out of the protected area is that user-side encryption may render the transfer outside the scope of the transfer rules in Chapter V and that server-side encryption, dependent on the law and practices in the third country, could be a potential first step in complying with the essentially equivalent requirement.

Ideally, a technological solution would offer both high confidentiality protection for a user’s personal data and high utility for the data processor. Homomorphic encryption (HE) has been proposed as a tool that approximates this ideal. Under HE, personal data can be encrypted with a secret key that only the user knows— obtaining protection benefits highlighted in (i)—and the data processor can perform certain computations on the encrypted information (apart from storing or forwarding)—obtaining utility benefits highlighted in (ii). Specifically, the characteristic property of HE is as follows: applying a certain operation on some homomorphically encrypted data and then decrypting the result with the corresponding secret key, yields a plaintext that equals the result of directly applying that operation to the original data. So, under HE, users encrypt their personal data, send the ciphertext to a third party, have the party apply certain computations to the ciphertext, receive and decrypt the processed ciphertext, and then access the plaintext, which is equal to the result of directly applying that computation to their original data. Figure 2 depicts this procedure.

We now give an example where HE could be an applicable technical measure in relation to cross-border transfers to third countries. Consider a database that is maintained by a service in a third country and that is homomorphically encrypted with a secret key known only by a data subject in the protected area. Assume that the employed HE scheme can preserve search operations, meaning that applying a homomorphically encrypted search query on the homomorphically encrypted database returns the same result as if that query was applied directly to the original database. The EU data subject can then issue a query, which might contain personal information, to the database in the third country, without having this service learn the content of the database, the issued query, and the result of the query.

However, HE is not ideal. There is a trade-off between the complexity of the computation that can be applied to the ciphertexts and the computational performance that can be achieved. The higher the Data Subject Processor (Server) complexity of the computation that one needs to apply to ciphertexts, the slower this computation becomes (compared to applying the same computation to plaintext), rendering HE impractical for general purpose processing.101 Although improving the performance of HE for a wider spectrum of computation is an active field of research.102

Employing HE to enforce the data protection principles of confidentiality and purpose limitation in crossborder transfers to third countries could be a sensible proposal, as many other authors have already argued.103 HE could be regarded as equivalent to original user-side encryption, for purposes of GDPR compliance in transfer to third countries.

Could the application of HE render the transfer outside the scope of the transfer rules in Chapter V from the perspective of the importer in the third country?

We suggest a new approach when assessing the legal status of homomorphic encryption as a safeguard in transfers to third countries. If personal data are encrypted by the data subject itself, or by a data exporter in the protected area, and the encryption key is not controlled or accessible by the data importer in the third country, good reasons call for interpreting the situation

Computa ons on the encrypted data

Ciphertect on the left side of Figure 2, prior to the point of export, as the processing of personal data (encryption) and processing of pseudonymized data (decryption) and the situation on the right side of Figure 2 (processing in the third country) as the processing of non-personal data. In such an interpretation, the processing in the third country is left outside of the material scope of the transfer rules in Chapter V. The interpretation builds on the following considerations: (i) the secret key is not accessible to the importer of personal data and (ii) it is not computationally efficient to reverse-engineer the personal data from the computations on the encrypted data in the third country.

A trusted execution environment (TEE) allows data to be processed without ever being accessed by unauthorized parties. Compared to homomorphic encryption, arbitrary computation can be practically applied to these data, while its confidentiality is still protected.

Compared to the other solutions discussed in this article, a TEE is a hardware solution. An example of TEE is Intel’s SGX processor. Here, data are stored encrypted

D o w n l o a d e d fr o m h t t p s : / / a c a d e m i. c o u p . c o m i/ d p l/ a d v a n c e a lit/r c e d o i/ 1 0 . 1 0 9 3 i/ d p il/ p a d 0 1 3 / 7 2 2 6 2 4 9 b y g u e s t o n 2 3 J u l y 2 0 2 3 in an isolated memory space, called an enclave. When performing a computation, the processor fetches data from the enclave, decrypts this data, applies the computation, and stores the result encrypted back to the enclave. Consequently, no other process running on the same machine, not even the operating system, can access data in the enclave, unless it knows the corresponding secret key. So, a TEE can provide high confidentiality protection and high utility since arbitrary computations can be applied to sensitive data.

We now give a scenario where a TEE is being employed as part of transfers from the protected area to a third country. Consider a medical centre in the protected area in the EU or EEA and a company in the USA that specializes in a rare-disease diagnosis. This company has proprietary software that takes as input patient’s data and outputs the likelihood that this patient suffers from the specific disease. This software is executed on a machine equipped with the SGX processor. The EU medical centre can then encrypt a patient’s medical information with a key known by that processor, send the ciphertext to the company in the USA, and have it stored and processed within an SGX enclave. The encrypted result of the processing can then be sent back to the medical centre in the protected area, where it is being decrypted and examined.

So, in this scenario, a TEE solution offers confidentiality protection for the transfer of personal information from the protected area to a third country.

Except for the confidentiality of data, a TEE could also be used to enhance the right to redress, for instance the right to information, rectification, and erasure in the GDPR interpreted in light of Article 47 of the Charter. A TEE can be used to attest the code that it executes. For example, assume that the data exporter and data importer have agreed on using the transferred data only in a certain way. A TEE can then be used to securely capture a fingerprint (ie hash) of the code to be executed on this data, and send the fingerprint to the data exporter. The data exporter is then able to verify whether the fingerprint corresponds to the pre-agreed processing of data, and thus check whether the sent data are used in the expected way.

Would the application of a TEE in a cross-border transfer to a third country render the data transfer outside the scope of the transfer rules in Chapter V of the GDPR? To answer this question, we examine two issues. First, to employ a TEE, one needs to trust the provider of that TEE. For example, one needs to trust Intel that the SGX processor functions as it is supposed to and that the keys employed cannot be compromised or handed to third-country authorities. The discussion on the legal status of the TEE under this question is similar to the discussion on sovereign cloud models above. Secondly, researchers have exposed data leakages through timing side-channels, when SGX is employed.104 If a TEE has been certified and is offered by a trusted European provider and if the timing sidechannel leakages are not enough to reconstruct personal data, then the application of a TEE could render a data transfer outside the scope of the transfer rules in Chapter V of the GDPR, or at least, enforce the ‘essentially equivalent’ requirement of GDPR.

One of the reasons behind transferring data from the protected area to a third country is for this data to be used in the training of a machine learning (ML) model. There are cases where many different institutions, from possibly different countries, want to collaborate in the training of a ML model, but without revealing their training data, which consists of personal data, to the other participants.

To address this constraint, federated learning has been proposed. In federated learning, the participants share the model—not the raw training data. Each time, a participant receives the partially trained model from another participant, uses their training data to further train the model, and then sends the result to the next participant. This procedure continues until the resulting trained model satisfies some optimization criteria.

Employing federated learning offers high utility since the ML model is trained on the entire training data, even if these data are split among different participants.

It seems that federated learning offers higher confidentiality protection than sending raw data to third parties. However, it has been established that the partially trained model (ie values of certain parameters of the model) might still reveal information about the training data.105

Although, it is not clear whether this leaked information is enough to reconstruct personal data. In any case, one could conservatively deduce that dependent on the specifics of the transfer and the receiving third country, of the 9th International Conference on Internet of Things: Systems, Management and Security (IOTSMS) 1 <https://doi.org/10.1109/ IOTSMS58070.2022.10062088> accessed 13 July 2023. employing federating learning is not sufficient to comply with the ‘essentially equivalent’ requirement, and additional measures should be taken to protect personal data, especially if the training data are sensitive data, such as for instance health data under GDPR Article 9(1).

EU data protection law and the GDPR build on a notion of informational self-determination.107 Informational self-determination represents the rationale behind the right of information for the data subject in Article 13, the right to access in Article 15, rectification in Article 16, and erasure in Article 17. The right to informational self-determination is also related to the right to redress 107 See, for instance, Regulation (EU) 2016/679 Recitals 32, 50, 59, 63, and 66. in Article 47 of the Charter of fundamental rights of the European Union.108

However, the rights of the data subjects in the mentioned Articles would only represent theoretical and illusory rights—and not practical and enforceable rights—if it is impossible to trace where the personal data are stored in a system. The importance of knowing where data flow in a system and where pieces of information with the potential to identify natural persons are transferred is especially present in third-country transfers.

In this section, we discuss whether new technologies, such as data tracing or provenance logs, might represent a solution to strengthen data subjects’ right to informational self-determination within the rights to information, access, rectification, and erasure of personal data in the GDPR in cross-border transfers to third countries.109

The rights of data subjects under the GDPR are supposed to travel with the personal data of EU and EEA data subjects if and when personal data are transferred outside the protected area.110 Data tracing can provide the technical means for implementing this requirement. Here, a piece of data are associated with a label. This label follows the associated data wherever it goes. For example, when data are copied from one storage location to another or when it is sent through the network to another physical location, the associated label follows the data to the new location. Also, when data are used as input to a computation, then the associated label is propagated to the result of this computation. This is because information about this input data is likely encoded in the result, and thus, the associated label owes to follow that information, too.

A label can encode any information that is relevant for the given application. For instance, a label can record the origin of the associated data or even its detailed provenance, including the processing steps the associated data have passed through and the different locations it has traversed. A label could include restrictions on how the associated data are allowed to be used. In such a case, whenever an entity attempts to process a labelled piece of data, it would first have to check whether this processing adheres to the restrictions included in the label.

Tracing and provenance mechanisms have been studied and deployed on different abstraction levels in a system. Constructing and querying the provenance of data within a database has been extensively explored.111 Tracing has also been implemented at the level of operating systems,112 where one can reason about the provenance of files. Establishing end-to-end traceability for internet of things (IoT) application, from the sensors to the data-processing stage, to the user interface is a current research front.

The ability of data tracing to capture the origin of data and record it in the associated label can support the right to access and the right to erasure. For example, if labels include information about the owner of the original data, and a principal wants to have their data deleted, then an automatic process could search through the system and delete all the information that is associated with a label specifying that principal as the owner.

Having labels record the provenance of data can support the right to redress. This information could help the user understand how their data have been used and whether this use is in accordance with certain agreements. For example, provenance information could be used to check whether data processing in the third country obeys the safeguards agreed upon between the EU data exporter and the data importer in the receiving third country.

For tracing to be used as a means of enforcement of the GDPR, the employed tracing mechanism should be trusted. The entities that implement tracing within the computer systems in the third country should provide some assurance about the integrity of the tracing mechanism. Such assurance could be regulated by the legal safeguards agreed between the parties.

Notice that tracing alone does not offer confidentiality protection. Though it can be augmented with a monitoring mechanism that ensures data are read only by principals prescribed by use restrictions within the associated label. Also, tracing does not, by itself, impede the utility of data. Finally, it does impose computational, storage, and network overhead, since all these aspects should accommodate the additional information carried by the labels.