Home Blog An Update on Schrems II An Update on Schrems II Jun 25, 2021 By Marcus Grazette, Europe Policy Lead at Privitar The Schrems II judgment continues to be one of the most talked-about developments in data protection policy. My blog on 30 April covered what Schrems II is and why it matters, so check that out if you are looking for the full background and context. This blog covers two new developments this month relating to Schrems II and international data transfers: the European Commission adopted new Standard Contractual Clauses (SCCs) and the European Data Protection Board (EDPB) finalized their recommendations on supplementary transfer tools. What do the new SCCs mean for international transfers? The new SCCs came into force on 27 June 2021. The European Commission envisages a transition period; organizations will have until 27 December 2022 to migrate to the new SCCs. The new SCCs aim to address the specific concerns around government access to data described in Schrems II. Crucially, the new SCCs allow the parties to the contract to consider the real world situation with respect to government requests for access to data. The European Commission notes that the parties should take account of the “existence or absence of requests in the same sector” and the “documented practical experience of the data exporter and/or data importer.” In other words, the legal challenge in Schrems II was based on the possibility of data access, whereas the assessment required for SCCs is based on the reality. The new SCCs also require the data exporter to use “reasonable efforts” to determine whether the data importer is able to meet their obligations under the SCCs. The European Commission explains that the parties should take account of the specific circumstances of the transfer (e.g. type of data, purposes of processing, and so on), the laws in the recipient country, and supplementary measures in place. What has changed in the EDPB’s recommendations on supplementary measures? The final EDPB recommendations retain the option for transferring pseudonymized data, if the pseudonymization process meets four requirements. The three technical requirements are unchanged, but the fourth, procedural requirement has been updated. In summary, the four requirements are: The data should be pseudonymous as defined in Article 4(5) of the GDPR. In other words, the data can no longer be attributed to a specific individual, nor used to single out an individual in a group, without the use of additional information. That additional information should be held exclusively by the data exporter. The data exporter should implement appropriate technical and organisational controls to keep the additional information safe. The data exporter should assess the pseudonymized data and, taking account of “any information that the public authorities of the recipient country may be expected to possess and use”, establish that the pseudonymized data cannot be re-identified if cross references with that information. The fourth requirement now allows the parties to consider what information the public authorities “may be expected” to use, rather than the broader “may possess” wording in the previous draft. This brings the EBDP guidance closer to the existing GDPR standard for assessing identifiability, based on the “means reasonably likely to be used.” What does this mean for organizations? Taken together, the new SCCs and EDPB guidance suggest that organizations can take existing practice into account when assessing whether data access by a government agency is likely. Many SaaS and cloud providers publish statistics on government requests for access to information, usually broken down by requests for content (e.g. the text of an email) or metadata (e.g. the time a user accessed their account) for example Google’s Transparency Report and Amazon’s Information Request Report. We may see organizations using this data to argue that requests for access to personal data by public authorities are relatively unlikely. Statistics from Microsoft to illustrate the point. Microsoft received 109 requests from law enforcement relating to enterprise cloud customers from July to December 2020. Microsoft defines an enterprise customer as an organization with 50+ ‘seats’ for a commercial offering, such as Azure, or Microsoft 365. Of those 109 requests, Microsoft was compelled to provide information in 40 cases. The remaining 69 were rejected, withdrawn or redirected to the customer. Microsoft publishes separate statistics on requests pursuant to national security laws, such as the Foreign Intelligence Surveillance Act (FISA). In January – June 2020, Microsoft received between 0 – 499 orders seeking disclosure of content, affecting between 14,000 – 14,999 accounts. Reporting restrictions mean that this data is less precise. We can’t be sure how many requests relate to enterprise customers, the number of individuals affected (as an individual may have more than one account) or how many orders actually resulted in disclosure. How can Privitar help? Privitar’s Data Privacy Platform can produce data meeting the EDPB’s technical requirements. Organizations will need to assess whether they can meet the procedural requirement in each case. Our experts can help you to understand the factors contributing to contextual risk, and how to manage them. To learn more about how Privitar can help your organization, speak with one of our privacy experts about your data privacy journey or request a demo. Data transfer Schrems II