On June 18, 2021 the European Data Protection Board (the assembly of European data protection authorities) published its recommendations on supplementary measures to be applied to ensure compliance with the GDPR for data transfers outside the European Union 🇪🇺.

Background 🎙

Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data | European Data Protection Board
European Data Protection Board

On July 16, 2020, the Court of Justice of the European Union invalidated the Privacy Shield, ruling that U.S. intelligence laws violate the GDPR.

Since this date, it is therefore illegal to use as a data processor a company operating or outsourcing all or part of its activity in the United States without signing Standard Contractual Clauses and without implementing supplementary measures.

Do not hesitate to read our dedicated article on the subject: Cloud Act, FISA, ... why the Privacy Shield was invalidated?

The EDPB had published in November 2020 a first version of recommendations on these supplementary measures, and after public consultation, they just issued the final version:

NB: this article is only intended to popularize the official recommendations, and does not replace them in any way, refer to the original document to ensure your compliance 👍.

Methodology 🤓

The EDPB has established a methodology for adopting appropriate supplementary measures:

  1. Know your transfers ➡ : while obvious to say, there are some subtleties:
    • some companies that are incorporated, that operate and store data in the EU sometimes allow access to data in third countries (for support purposes), especially companies that operate around the world, this then constitutes a transfer;
    • some transfers may be unjustified under the minimization principle.
  2. Validate the lawfulness of the transfer ✅ : the transfer must be authorized by one of the articles in Chapter V:
    • Article 45: transfers to certain geographical areas (such as Argentina, New Zealand, or Japan, but no longer the United States) are permitted on the basis of an adequacy of safeguards provided in that area with the GDPR.
    • Article 46: if adequacy is not declared by the European Commission, Standard Contractual Clauses (SCC) should be used as a legal tool for transfers;
    • Article 49: certain exceptional transfers are by way of derogation permitted to countries that do not offer any guarantees, but this cannot be the norm;
  3. Assessing the legislation of the country of export ⚖️ : it is up to the data controller to prove that the transfer of data ensures the effective application of the SCC in light of local legislation. If these guarantees cannot be provided, either:
    • stop the transfer ;
    • implement "supplementary measures" to obtain adequate safeguards. Typically in the United States, FISA Section 702 violates the Standard Contractual Clauses (which is the reason for the invalidation of the Privacy Shield), so supplementary measures must be implemented.
  4. Implement supplementary measures ➕ : the objective of these measures is to achieve an effective level of assurance on the transferred data equivalent to processing the data within the EEA. If no combination of supplementary measures can achieve this guarantee, the transfer must be stopped.

Supplementary measures 💪

The EDPB does not give an exhaustive list of supplementary measures, it leaves it up to data controllers to find the appropriate measures depending on the data, the treatment and the country of export.

Nevertheless, it gives some examples that we will study:

🟢 Storage of data without the need to access the data in clear text;
🟢 Transfer of pseudonymized data;
🟢 Encryption of data to protect against eavesdropping outside the EEA;
🟢 Protected recipient;
🟢 Split or multi-party computation.

Storage of data without the need to access the data in clear text ❌

If you want to store data with a processor outside the EEA and the processor does not need access to the data, the EDPB suggests assuming that the processor is essentially malicious with respect to data confidentiality and integrity because the authorities in the country in which the processor operates may attempt to read or alter the data.

This does not mean that we cannot trust the processor in terms of data availability: we can retrieve the data from the processor when we need it and decrypt it with the key that they does not have.

To do so, here are the details of the supplementary measures to be adopted:

  1. personal data is encrypted before being sent to the processor;
  2. the encryption algorithm, its parameters and the key management are state of the art and considered robust against the attack, cryptanalysis and computation capabilities of the authorities of the recipient country, and correctly sized considering the duration during which the data must remain unreadable by the authorities of the recipient country;
  3. the encryption algorithm is implemented correctly, by properly maintained software with no known vulnerabilities, whose compliance with the specification of the chosen algorithm has been verified, for example, by certification;
  4. the keys are held only under the control of the data exporter, or by another processor within the EEA.

Caution: using an HSM, KMS or BYOK delegating storage, control or use of the key to the processor which is outside the EEA is not a sufficient supplementary measure 👎.

Transfer of pseudonymized data 🕵️

If you want to analyze data with a processor outside the EEA, and you only need part of the data for the analysis, in particular not the identifying data, you can then perform a rigorous pseudonymization and then transfer only the pseudonymized data.

Specifically, here are the requirements for this to be considered an effective supplementary measures:

  1. pseudonymization must be performed in accordance with Article 4(5) of the GDPR, in particular, it must not be possible to attribute pseudonymized data to the individuals to whom it corresponds without using a pseudonymization table;
  2. the pseudonymization table and its use to re-identify individuals must remain controlled by the exporter through technical (such as encryption) and organizational measures;
  3. if an encryption measure is used to ensure control of the pseudonymization table, this measure must be implemented with the same precautions as a secure backup discussed above;
  4. the exporter has established through a thorough analysis of the pseudonymized data that it cannot be re-identified, even when using open sources or other sources available to the authorities of the destination country.

Encryption of data to protect against eavesdropping outside the EEA 👂

In many cases, data must be transmitted, including via the Internet, through countries whose legislation allows them to attempt to read its contents.

For this, robust transit encryption techniques must be implemented, in particular :

  1. the encryption algorithms, their parameters and their key management are state of the art and considered robust against the attack, cryptanalysis and computational capabilities of the authorities of the recipient country, and properly dimensioned taking into account the duration during which the data must remain unreadable by the authorities of the exporting country;
  2. a secure certification authority or infrastructure is chosen by the parties;
  3. proactive and state-of-the-art measures (such as vulnerability/backdoor testing) are used to defend against active and passive attacks on systems providing encryption in transit;
  4. if transit encryption at the infrastructure level is insufficient (because it would leave the ability for a third party to eavesdrop), application-level end-2-end encryption (at least between client and server) is added;

Protected recipient 🔒

In some specific cases, the legislation of the third country may protect the secrecy of certain data for certain professions and in certain cases (for example, in the case of medical secrecy or client / attorney privilege).

In these cases, the EDPB considers the transfer compliant provided that:

  1. the legislation of the third country ensures data secrecy to the processor importer of the data in the case of this transfer, and this assurance extends to encryption keys and other means that could be used to access data subject to such secrecy;
  2. the subcontractor ensures that its own subcontractors have the same legal assurance;
  3. the data is encrypted before sending and decrypted only by the importer-subcontractor using end-to-end encryption that ensures that the key is not accessible to entities other than the importer-subcontractor (and possibly the exporter).

Split or multi-party computation 🤐

The exporter may wish to process personal data using techniques known as multi-party computation or distributed secrecy. The principle in both cases is the same: split the personal data into several pieces before transfer, transfer each piece to different jurisdictions, and reconstruct the data only within the EEA.

The EDPB considers the transfer to be in compliance with the following conditions:

  1. the data splitting technique is done in such a way that it should not be possible to attribute from a single piece of data the persons to whom it corresponds, even using open sources or other sources available to the authorities in each destination jurisdiction;
  2. the data splitting technique used is robust against active attacks;
  3. the results of the data splitting are sent to different jurisdictions;
  4. it has been demonstrated that no collusion, collaboration or mutual assistance of any kind is possible between the authorities of each jurisdiction that could lead to the attribution of the data to the persons to whom they correspond;
  5. the data (and the possible results of multi-party computation) are only reconstructed within the EEA.

Conclusion 🔥

The recommendations of the EDPB are particularly rigorous, especially when it comes to encryption, which I applaud.

It is one of the first normative documents - to my knowledge - that correctly distinguishes the impact of the different encryption techniques (in transit, at rest, end-to-end) that we explained in our white paper.

Moreover, the attack scenarios against which the EDPB forces companies to defend themselves are very advanced and require real expertise from companies wishing to transfer data, especially when faced with governmental actors (American) particularly targeted in this document.

In my opinion, this shows the maturity of the European regulator in terms of digital sovereignty (although it is often denounced for its naivety in this matter).

If you are looking to implement supplementary measures similar to those described above, please contact us!