TOTAL: {[ getCartTotalCost() | currencyFilter ]} Update cart for total shopping_basket Checkout

Privacy Perspectives | Supplementing SCCs to solve surveillance shortfalls Related reading: 'Schrems II': Impact on Data Flows with Canada

rss_feed

By invalidating the EU-U.S. Privacy Shield but not rejecting wholesale the use of standard contractual clauses to transfer data to the U.S., the Court of Justice of the European Union in "Schrems II" left open the possibility that such transfers could continue. However, it emphasized that exporters and importers may need to adopt additional safeguards when using SCCs to ensure an adequate level of protection for personal data transferred to the U.S.

Until now, commentators have seemed unsure as to what those safeguards might be or how they can address potentially irredeemable flaws in the U.S. surveillance system. In this piece, we detail a proposed solution consisting of technical measures, supplemental clauses and exit strategies. 

Our solution can work because the CJEU decision was — at its core — based on three essential holdings. First, Section 702 of the Foreign Intelligence Surveillance Act provides no effective limitations on the power of the U.S. government to implement surveillance programs for foreign intelligence gathering and, therefore, fails the test of proportionality. 

Second, neither Section 702 nor the government’s surveillance activities under Executive Order 12333 adequately limit the surveillance to what is strictly necessary as required by the EU General Data Protection Regulation, because they allow for forms of bulk surveillance. 

And third, non-citizens lack adequate judicial redress against the USG under these surveillance authorities.

Although it is impossible to solve the judicial redress issue without U.S. structural reform, such redress only becomes necessary if the data at issue is, in fact, collected by the USG under the relevant surveillance programs. Moreover, where the likelihood of USG acquisition is very low, the transfer should satisfy the essential equivalence standard — for the same reason that Article 32 of the GDPR does not require perfect data security but rather a level of protection that is “appropriate to the risk,” and Article 25 (data protection by design) similarly requires a risk-based approach to GDPR compliance generally. This case-by-case evaluation is the very point of the SCCs as they are designed to be used in jurisdictions that have not achieved an adequacy determination.

Accordingly, the questions remain: What supplemental measures can appropriately reduce the risk of interception under EO 12333 or Section 702 of FISA? In other words, in light of "Schrems II," how can the parties find, prior to any transfer, that there is, in fact, an “adequate level of protection” for personal data in the importing jurisdiction and that the recipient can comply with the standard data protection clauses transferring personal data to that third country?  

The key is found in footnote 2 of the controller-to-processor SCCs, which is that laws that require data to be turned over to governmental entities do not invalidate the SCCs where, in a democratic society, they “constitute a necessary measure to safeguard national security, defense, public security, the prevention, investigation, detection and prosecution of criminal offenses or of breaches of ethics for the regulated professions, an important economic or financial interest of the State or the protection of the data subject or the rights and freedoms of others.”

The CJEU found the availability of surveillance and data acquisition under 12333 and Section 702 of FISA fails this test. If the data transferred to the U.S. cannot be obtained under these surveillance programs, then the programs shouldn’t impede the transfer — even without enhanced judicial redress for non-citizens. Indeed, adequate judicial redress for non-U.S. people has not always been available for certain forms of standard criminal process that generally are perceived to satisfy the standard in the footnote — and nothing about the decision suggests that standard criminal process alone would prevent the use of SCCs.

Defeating EO 12333 interceptions

With regard to EO 12333, the chief evil cited in the CJEU opinion was bulk surveillance and specifically the ability of the NSA to access data "in transit" to the U.S. by accessing underwater cables on the floor of the Atlantic and to collect and retain such data before arriving in the U.S. (p. 63).  This issue can be solved through a combination of technical measures and contractual promises. 

First and foremost, EO 12333 allocates surveillance responsibility within the USG and provides it with the authority to conduct its own surveillance activities but provides no mechanism for forcing importers to assist the government. Thus, importers can contractually commit to not voluntarily assist the government in conducting operations under EO 12333. 

Second, interceptions can be defeated through technical measures, like, for example, sufficiently strong encryption such that the USG cannot understand the substance of the data without the key, which it cannot compel importers to produce under 12333. If the USG cannot understand the substance of the data, there is no risk to the data subjects reflected in the data, and this particular safeguard can be considered adequate with respect to 12333. Thus, a commitment to encrypting all data in transmission and not voluntarily assist the government in its conduct of 12333 activities should defeat one of the core deficiencies cited in the CJEU decision. (Other technical measures that defeat the USG’s ability to understand the data without cooperation would also work.)

Surmounting Section 702

The CJEU decision fails to recognize the limited nature of Section 702 surveillance. 

First, not all providers are eligible to receive a “directive” (an order that leads to the USG’s acquisition of data) under 702. Only electronic communication service providers are eligible. Importers that are not ECSPs can, therefore, provide assurances of ineligibility and agree to fight any 702 directive. And even if the data was to be obtainable from the importer’s network provider through the NSA’s Upstream collection under 702, the same technical safeguards that would defeat 12333 surveillance would be effective against 702, particularly if decryption/reidentification required the exporter’s cooperation.

As for importers that are ECSPs (in whole or in part), the government only uses Section 702 where there is a repeated need for multitarget collection without the inefficiency of going to the FISA court for individual surveillance orders via a procedure that has greater judicial oversight.

Indeed, at the time of the Snowden leaks, it was reported that fewer than 10 companies were receiving 702 orders. Even if that number has doubled or tripled, it would be an insignificant percentage of the more than 5,300 companies that may be moving from Privacy Shield to SCCs, much less the entire field of importers who rely on SCCs.  

Thus, nearly all of them could promise that they have received no process under 702, and they can keep making that promise unless and until they receive a directive. Others can promise that the number of affected users under all national security process is published in their transparency reports, which exporters can compare to the number of overall data subjects about whom they collect data to make an accurate risk assessment. Where the chance of 702 collection identified through this reporting is sufficiently low (say, less than 1%, which is far lower than the chance of a data breach), an exporter may be able to justify continued exports.

Exit strategy: The potentially unkeepable promise

Of course, a provider that makes any sort of promise related to Section 702 surveillance as part of a package of supplemental clauses may be unable to keep that promise someday.

However, the SCCs already contemplate that situation, under C2P SCC Clause 5, and controller-to-controller SCC Clause II(c), an importer is required to notify an exporter of its inability to comply with SCCs, enabling the exporter to suspend and terminate the contract. An importer could similarly agree to notify an exporter that it will no longer be able to comply with all of its SCC and supplementary promises, without directly notifying the exporter which specific promise it can no longer keep, and offer the same suspension/termination right. Although explicit notification of the receipt of a directive is legally prohibited, a notification that the importer will no longer be able to comply with a set of promises would not violate non-disclosure restrictions, especially where it could be equally likely that the inability to comply was due to something else, such as a failure with the importer’s service provider.

And because a 702 directive is a demand for the importer’s cooperation — and not some sort of notice to the importer that data already has been acquired — importers can expect to provide their warning to the exporter in advance of any actual disclosure.

Service providers are tricky

The CJEU decision and Article 44 of the GDPR indicate that the assessment of the adequacy of protection must consider the importer’s transfers of data to subprocessors or other service providers (among other third parties).

Notably, under Clauses 4(i) and 11(1) of the C2P SCCs, an importer agrees to flow down its SCC obligations to its subprocessors, who must provide “at least the same level of protection for the personal data and the rights of data subject as the data importer.” C2C SCCs are less proscriptive, but it is hard to argue that an importer provides adequate protection if it passes the data to a U.S.-based service provider without addressing the risks identified in the CJEU decision. Just as supplementary provisions to the SCCs, such as those outlined above, may let importers adequately protect data transferred to the U.S., importers may be able to address onward transfer risks to service providers by doing one or more of the following: (1) using technical safeguards such as encryption to prevent the service provider from processing personal data in a form intelligible to the USG; (2) imposing applicable supplementary safeguards on their service providers, which may vary by service provider (a strict flow-down requirement may be unworkable because, for example, a non-ECSP cannot be expected to flow down a non-ECSP rep to its service providers who are ECSPs); (3) for eligible transfers, relying on a derogation set forth in Article 49 of the GDPR; and/or (4) using service providers located in the European Economic Area or an adequate jurisdiction. 

Option two, which for some importers is the least obtainable, could become easier if supervisory authorities signal support for the solution proposed in this article, thereby hastening its widespread adoption.

Conclusion

The irony of utilizing supplemental clauses to assist in the transfer of data to the U.S. is that EU data is sometimes better protected against the USG when it is imported into the U.S. than when it is kept outside the U.S. When data is outside the U.S. borders and doesn’t pertain to U.S. citizens, U.S. surveillance authorities allow the government to operate in an arguably unrestricted manner to obtain such data subject only to capability limitations. Only when the data is imported by U.S. companies does the mandate of U.S. intelligence agencies become circumscribed by U.S. legal authority, including under EO 12333 and FISA.

Thus, inside the U.S., the USG’s power is curtailed and subject to judicial oversight and the often-effective pushback by U.S. technology companies. Nevertheless, the use of the safeguards described in this article should — to the maximum extent possible without requiring changes to the U.S. judicial redress regime — allow for continued cross-border data transfers.

Photo by Duangphorn Wiriya on Unsplash

An Overview of US Surveillance in Light of "Schrems II"

The purpose of this white paper is not to argue for the validity or invalidity of any particular surveillance mechanism, but rather to provide a neutral, unclassified summary of the law and authorities in this area.

Click to view

GDPR Genius

This interactive tool provides IAPP members ready access to critical EU General Data Protection Regulation resources — enforcement precedent, interpretive guidance, expert analysis and more — all in one location.

View here


Approved
CIPM, CIPP/A, CIPP/C, CIPP/E, CIPP/G, CIPP/US, CIPT
Credits: 1

Submit for CPEs

9 Comments

If you want to comment on this post, you need to login.

  • comment Andor Demarteau • Aug 19, 2020
    Whilst this may work against executive order 12333, note encryption on connections on the Internet shouldn't be an extra thing you do because of this surveillance bit, encryption related to data importers and specially service providers will simply not work.
    The reason for this is pretty simple: the service providers probably have, to some extend, access to the cryptographic keys the importers are using. This is unless, I doubt company's will invest in this, they use proper HSM's to secure those keys and adopt additional measure.
    Also the risk of the government obtaining the data may be low, although since most if not all of this goes in secret I doubt the figures in this article are even close to be direct, it will take only a few impacted data subject for the EU data exporter to be in big enforcement trouble.
    As for article 32 GDPR, yes costs and measured approach on security is a factor but so also is state-of-the-art security.
    Concluding: whilst technical measures may limit the risk to some degree, any promises made by US importers are worth nothing in light of section 702 specially if gag orders come into play and as long as the data subjects impacted have no legal redress nor can be made aware of their data being scraped, this may simply not work.
    For other criminal cases etc. holds that processors are not allowed to pass the data onto law enforcement without permission of the data controller, doing so means they may well breach article 28.10 GDPR.
    A final note: let's also have a look at how many of the tech firms that export data from the EU fall under the section 702 mandates, if a large number this may invalidate the arguments in this article as well.
    For the final note that data is better protected inside than outside of the US because the US government simply will hack in and crap what they like, I'll say this: "give us the data we take good care of it, if you don't we'll scrape it anyway" seems a ludicrous solutions to satisfy the CJEU tests at best.
  • comment Lewis Barr • Aug 19, 2020
    Thank you, ZwillGen team, for this excellent analysis and the recommendations.
  • comment Jaipat Jain • Aug 19, 2020
    Thanks for drawing attention to Article 32.  As to use of SCCs and Section 702, some comments would be in order -
    1. SCCs themselves are a product of a larger law.  Footnote 2 - to which reference has been made - articulates a well-recognized exception which originates in Article 52(1) of the European Charter of Fundamental Rights. That article says: “Any limitation on the exercise of the rights and freedoms recognised by this Charter must be provided for by law and respect the essence of those rights and freedoms. Subject to the principle of proportionality, limitations may be made only if they are necessary and genuinely meet objectives of general interest recognised by the Union or the need to protect the rights and freedoms of others.”  In other words, laws that meet the above test are okay.
    2. Section 702 is not narrow in the sense it is limited to "electronic communication service providers" because ECSP is a wide and elastic term.  It means any "provider of telecommunication service," any "service which provides to users the ability to send or receive wire or electronic communications," any provider "to the public of computer storage or processing services by means of an electronic communications system," and any "other communication service provider who has access to wire or electronic communications either as such communications are transmitted or as such        communications are stored."  The foregoing does not include just the telecom companies but at least also all of the cloud service providers. 
    3. SCCs do not save one from the reach of Section 702.
  • comment Sylvia Johnson • Aug 19, 2020
    Stellar analysis.
  • comment Marc Zwillinger • Aug 20, 2020
    Thank you all for your comments.  To Jaipat, I would say that there are three separate points about 702 related to your comments.  First, while the universe of companies who could get a 702 directive is broad enough to encompass a variety of companies, it doesn't really matter if they can say they have never gotten one and would stop the import if they can no longer live up to their combined promises.  Second, the theoretical scope of 702 from a book perspective and the use of it in practice are different things.  Third, once you leave the question of whether the whole country is adequate and/or whether the privacy shield program as a whole is adequate, the inquiry turns to whether the specific transfer to the specific importer is permissible.  That assessment seems like it should take into account the practical risk assessment based on who the exporter and importer are.
  • comment Jaipat Jain • Aug 20, 2020
    Thanks Marc. I agree as to your third point.  As to others one could discuss more offline.  But, briefly, I wonder if a Verizon, ATT, AWS and any of the many others inform their customers if they receive a 702 request, or are obligated to under their contracts with their millions of customers? Second, the distinction between book and practice is, it seems, become suddenly relevant here.  To illustrate - in its ruling, CJEU did not compare EU member nations' practices (which, for some, might be more awful than the practice of the U.S.) with that of the U.S.  Instead, it weighed U.S. book vs EU's professed principles.   Article 8, Protection of personal data, Section 1, for instance says, "Everyone has the right to the protection of personal data concerning him or her." Everyone.  I have not read (and will be happy to) any paper that shows, for instance, that France (by way of example) affords redress rights to a non-France resident or citizen when the French Direction générale de la sécurité extérieure collects personal data outside France of that person.
  • comment Henrik von Kunhardt • Aug 21, 2020
    Picking up Jaipats remarks concerning non-french nationals redress possibilities, the theoretical answer is fairly simple (reality probably more cumbersome, maybe even having to go up all the way to CJEU) - there is one. GDPR is EU legislation. By rule EU legislation superseeds national law for EU member states. So, at least for EU nationals and any other nationals falling under the applicability of GDPR, redress is open to all natural persons falling within the scoppe of GDPR - in theory. It would definitely be interesting to see if CNIL would be willing to go into oppossition to DGSE...
  • comment Ray Everett • Aug 22, 2020
    I definitely like this idea. If we're going to be looking at bolstering the risk assessments in this area, the kinds of statements suggested above included in an addendum could address many of the questions and points of added scrutiny that would give greater confidence. If you have an addendum that allows you to periodically seek reconfirmation of no 702 directives, no cooperation with EO 12333, etc., you could incorporate periodic queries into a heightened risk assessment cadence and in so doing demonstrate greater attention to these considerations. Unless and until we see revised SCCs, or some new replacement for PS, this seems as good a solution as I've heard.
  • comment Wayne Sisk • Aug 25, 2020
    The scope of the number of companies potentially under ECSP I believe was vastly underappreciated - it is NOT just "Communications companies" -    "electronic communication service provider" means:
    
    (A) a telecommunications carrier, as that term is defined in section 3 of the Communications Act of 1934;
    (B) a provider of electronic communication service,
    (C) a provider of a remote computing service,
    (D) any other communication service provider who has access to wire or electronic communications either as such communications are transmitted or as such communications are stored; or
    (E) an officer, employee, or agent of an entity described in subparagraph (A), (B), (C), or (D).  
    
    (According to 50 USCS § 1881 [Title 50. War and National Defense; Chapter 36. Foreign Intelligence Surveillance; Additional Procedures Regarding Certain Persons outside the United States])
    
    Note "C"  which is also defined: 
    
     “a remote computing service is provided by an off-site computer that stores or processes data for a customer.”
    (Not stores AND processes;  stores OR processes)
    
    And:
    
    A service can only be a "remote computing service" if it is available "to the public." Services are available to the public if they are available to any member of the general population who complies with the requisite procedures and pays any requisite fees. For example, XXX  is a provider to the public: anyone can obtain a XXX account.
    
    This would include most any web present company running virtually any sort of SaaS B2B service (in any class)