Privacy Shield has been invalidated, and SCCs are next… Now what?

On July 16, 2020, the Court of Justice of the European Union (CJEU) invalidated the EU-U.S. Privacy Shield in its Facebook Ireland v. Schrems (Schrems II) decision. The EU–US Privacy Shield is a framework for regulating transatlantic exchanges of personal data for commercial purposes between the European Union (specifically the European Economic Area and Switzerland) and the United States. The Court ruled the Privacy Shield did not include adequate limitations to ensure the protection of EU personal data from access and use by US public authorities. Because of this, the Court immediately invalidated the Privacy Shield, which can no longer be used for EU–US data transfers.

In its ruling, the Court focused on US government surveillance practices, which the CJEU viewed as unjustly prioritizing national security over the rights and freedoms of European data subjects. In particular, the Court noted that Section 702 of the Foreign Intelligence and Surveillance Act (FISA) and Presidential Policy Directive 28 lacked the necessary PII data protections.

The little-known Presidential Policy Directive 28 was issued on January 17, 2014 and lays out the principles used to guide why, whether, when, and how the United States conducts signals intelligence activities for authorized foreign intelligence and counterintelligence purposes. This Directive obviously prioritizes US foreign intelligence over EU data subject privacy.

Additionally, the CJEU found that the Privacy Shield did not provide EU data subjects with sufficient (or any) rights against the US government for PII violations. Because of this finding, the Court stated that the Privacy Shield lacks the needed processes for EU data subjects seeking remedy as required by EU law.

Safe Harbor and SCCs

The EU has long been focused on the protection of their citizen’s personally identifiable information, much earlier than other countries. Because of this, in 1995 the EU created the EU Data Protection Directive (DPD), officially Directive 95/46/EC, to standardize on the protection of personal information across the various European countries. The DPD laid out a set of common rules for public and private entities that store and transmit personal data. The DPD was the very early precursor to the GDPR and regulated the processing and free movement of personal data within the European Union. It also prohibited the transfer of personal data to a country outside the European Economic Area (EEA) unless that country had adequate data protection measures in place. The Safe Harbor framework was adopted in 2000 to enable data transfers more seamlessly between the EEA and the US by creating processes which both the EU and US could accept.  

This allowed American companies to self-certify that they complied with the Safe Harbor framework. Once self-certified, a US company could legally receive exports of personal data from the EEA to the US. The Safe Harbor framework provided US companies with a relatively painless way to comply with European privacy laws and keep the flow of personal data from Europe to the US open.

In October 2015 Max Schrems, an Austrian citizen, filed a complaint with the Irish Data Protection Commissioner asking the Commissioner to prohibit Facebook from transferring his personal data to the US. Ireland's High Court noted that several US Federal Agencies carried out ongoing surveillance of personal data in a manner contrary to Irish privacy laws. The CJEU found that the Safe Harbor framework did not adequately protect personal data from "interference" from the US government, and on October 6, 2015, the CJEU invalidated the Safe Harbor framework, which had been in place prior to the Privacy Shield.

After the Safe Harbor was invalidated in 2015, EU data protection agencies began relying on an alternate process, utilizing Standard Contractual Clauses (SCC), first created in February 2010 and approved by European Commission Decision 2010/87/EU. SCCs have been used as a fallback legal basis for cross-border data transfers over the years. However, the Schrems' II case (Privacy Shield invalidation) has led the Irish Data Protection Commission to also question the legality of SCCs.

Now, because of the recent Privacy Shield invalidation, many experts are hinting that SCCs could very well be invalidated as well for the same reasons; they don't provide enough protection against US Government access. But until a decision of SCC validity by the CJEU, they can still be used in the transfer of PII between the EU and US.

One argument against the continued use of SCCs is that they are a contractual agreement between businesses promising that EU PII will be handled appropriately based on EU data privacy law. However, SCCs do not bind the US Government to the same responsibilities. An example portion of the SCC agreement lays out data importer responsibilities:

1. Obligations of the data importer

The data importer warrants and undertakes that:

(h) It [the data importer] will process the personal data, at its option, in accordance with:

(i) the data protection laws of the country in which the data exporter is established, or

(ii) the relevant provisions (1) of any Commission decision pursuant to Article 25(6) of Directive 95/46/EC, where the data importer complies with the relevant provisions of such an authorization or decision and is based in a country to which such an authorization or decision pertains, but is not covered by such authorization or decision for the purposes of the transfer(s) of the personal data (2)

The above (and other) provisions of SCCs do not address (and cannot solve) the primary issue the EU has with PII being transferred to the US, protection against governmental access.

The European Commission has issued two sets of standard contractual clauses for data transfers from data controllers in the EU to data controllers established outside the EU or European Economic Area (EEA).

A recent opinion on the two versions of SCCs stated that the SCCs cannot be changed or edited down, but additional requirements can be added to better address the EU objections via an addendum.

Specific Product CTA

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore

Securing data during transit, while at rest, and while in use

I wrote about governmental access and secrecy warrants in a recent blog – specifically warrants issued from a US government agency to a third-party cloud services provider demanding access to specific client data. In some cases, the warrants require access to a company's cloud data with the added condition that the company that owns the data cannot be told by the cloud services provider that the US government has accessed/copied the data – ever.

The prospect of secrecy warrants has driven some US-based companies to direct their sensitive data to be stored in cloud data centers outside the US. The underlying issue for these organizations is they want to safeguard the privacy and integrity of their sensitive data, which means having control of it at all times. Some in favor of the use of government secrecy warrants and backdoor access (LAEDA) throw the old adage around that if you have nothing to hide, why worry. However, others would argue that this is amounts to ceding your individual and corporate rights. Plus, given the uncertainty caused by Schrems II/Privacy Shield invalidation, US companies must respect the rights of EU data subjects or risk losing business opportunities in the future.

There are two significant areas of technical concern when transferring EU PII to the US: protection of PII during transit and protection while at rest. The best solution to data security while in transit is to encrypt the data before transfer to the US data importer. Many data exporters will transfer the data to the US without encrypting it first. The data importer will then store it in their multi-tenant public cloud – usually unencrypted as well. Encryption while at rest (storage) is the most straightforward and secure solution. But, if you want to archive the data for ongoing management and use, data encryption in a cloud archive presents its own challenges.

Most cloud archiving providers provide a limited capability for customized data security/encryption. If asked, they will encrypt the data with their encryption keys; however, they sometimes will reuse the same keys for other clients as well. In most cases, the encryption keys remain with the cloud service provider, giving them full control of your sensitive data as well as an access point for government subpoenas.

Even if the data is encrypted after reaching the cloud, the cloud service provider (the encryption key owner) can be served with a secrecy warrant from an agency demanding the data be decrypted, and the agency be provided access. Remember, the Privacy Shield and Standard Contractual Clauses do not limit governmental agencies from access - only the business entity which signed the agreements.

Double-key encryption

A potential solution to protecting sensitive data in a cloud is to incorporate double key encryption. Double key encryption (DKE) uses two separate encryption keys to access protected content. The data owner stores one key in the cloud repository, for example, Microsoft Azure, and then stores the second key locally. With this process, both keys are needed to access the encrypted data.

Double key cloud encryption can/should be used if:

• You want to ensure that only you can decrypt protected content
• You don't want the cloud storage provider to have access to protected data on its own
• You don't want a government entity to access your sensitive data with a secrecy warrant
• You have regulatory requirements to hold keys separately from the cloud data storage.

Double key encryption does ensure that sensitive corporate data cannot be accessed by the cloud provider or by governments via secrecy warrants served to the cloud provider. This solution would be adequate protection for PII transfer to the US. However, because of the nature of double key encryption, cloud-based encrypted data would be unable to be actively managed, indexed, searched, viewed, or analyzed on an ongoing basis. The data is securely stored but cannot be actively used by the data importer while stored/managed in the cloud – making it unusable for cloud-based archiving for instance.

Local key storage and homomorphic encryption

Until recently, it was impossible to move encrypted data (and keep the keys locally) to a cloud archive because once encrypted and moved to a cloud for archiving and management, the data was rendered useless for cloud-based management or analysis. Now, with the addition of fully homomorphic encryption, data encrypted on-premises can be stored in the cloud and remain entirely usable and manageable while the encryption keys are secured and always remain on-premises. Companies can now benefit from cloud-based archiving and information management without the accompanying data privacy and security concerns for unauthorized 3rd-party or governmental access. The result is a secrecy warrant-proof solution where a warrant would need to be presented to the actual data owner (versus the cloud provider), who would have the opportunity whether to fight the subpoena.

The homomorphic encryption technique is the only way to fully secure and manage your company's sensitive data when stored in a cloud archive while allowing the full use of the encrypted data for ongoing data management, eDiscovery/litigation hold, AI and ML and analytics.

To fully utilize this highly secure approach to transferring and managing EU PII to a US organization, the data exporter would need to encrypt the PII before sending it to the importer in the US. The encryption key would then be transferred separately. Once both the data and encryption key arrived at the US data importer, the data would be decrypted (on-premises) using the EU encryption key. The data would then be re-encrypted using homomorphic encryption processes and only then imported into the cloud-based archive with the new encryption key stored locally in the company's data center.

Needed SCC additions

Because the Privacy Shield has been invalidated and questions have arisen about the legality of Standard Contractual Clauses, EU data exporters should look to modify the SCCs to include the new security/encryption process:

1. (Additional) Obligations of the data exporter
   1. The data exporter warrants and undertakes that:
      1. Before the transfer of PII to an organization in the US, the data exporter shall encrypt the dataset using a mutually agreed-upon encryption technique.
      2. The encryption keys will be sent to the data importer via email or other acceptable processes.
      3. (Additional) Obligations of the data importer
   2. The data importer warrants and undertakes that:
      1. Once the encrypted data set and encryption keys are received, the data exporter will decrypt the data set locally (on-premises.) The data importer will then re-encrypt (on-premises) the data set using the homomorphic encryption process. Once encrypted, the data can then be migrated into a cloud-based archiving and data management system to secure storage and management.
      2. The new encryption keys will always remain in the company's local possession under an acceptable security protocol.

By adopting the additional clauses mentioned above, SCCs could be made more tolerable to the EU for PII transfer to the US. But until then, the use of the above encryption techniques and contractual clauses could remove the hesitation of using SCCs for PII transfer to the US.

The Archive2Azure Security Gateway

Unlike other cloud-based archiving solutions where the SaaS providers use their own encryption keys to encrypt your data, Archive360 provides a patent-pending Security Gateway for encryption of your data on-premises before it's moved into your Azure cloud tenancy – utilizing your company's own encryption keys – which stay secure onsite at all times. Additionally, your encryption keys can never be accessed or used by Archive360 – or anyone else.

The Archive360 on-premises encryption process has the added benefit of significantly reducing the risk of a data breach or 2-stage ransomware triggering privacy regulatory notification requirements – a very costly process. In fact, the California Consumer Privacy Act (CCPA) stipulates that the notification requirement is not triggered if the breached data was encrypted AND the encryption keys were stored separately. Even though it is not explicitly stated, it is believed the GDPR authorities would rule the same way if presented with the same situation.

Archive2Azure with the Security Gateway provides the best of information management and archiving in the cloud without the security risks of SaaS solutions.