How can Standard Contractual Clauses overcome Schrems II?
<p>My understanding of Schrems II was that it essentially said the US did not provide adequate data protection because of the potential access intelligence agencies there have and the lack of legal recourse non-US citizens have, and consequently agreements such as Privacy Shield and Standard Contractual Clauses were invalid for making data transfers legal.</p>
<p>However, it seems multiple SaaS products still transfer data there under amended Standard Contractual Clauses, e.g:</p>
<p><a href="https://help.figma.com/hc/en-us/articles/360041060434-General-Data-Protection-Regulations-GDPR-" rel="nofollow noreferrer">Figma</a>:</p>
<blockquote>
<p>Figma relies on Standard Contractual Clauses for the transfer of personal data out of the EU and has implemented certain supplementary measures for EU to US data transfers based on the Schrems II decision</p>
</blockquote>
<p>I'm confused as to what supplementary measures Figma has/could even have added to a contract to change that? Is this likely to hold up, or also probably invalid and just not enforced/tested in court yet? How is it possible for Contractual Clauses to mitigate privacy risks enshrined by law in the US?</p>

<p>The <a href="https://curia.europa.eu/juris/document/document.jsf?text=&amp;docid=228677&amp;doclang=EN" rel="noreferrer">Schrems II decision (C-311/18)</a> primarily discussed the &quot;Privacy Shield&quot; adequacy decision, but also covered SCCs. The CJEU confirmed that SCCs are generally valid. However, the CJEU also pointed out that the data exporter must first consider whether SCCs can actually be used in their specific context. From paragraph 141 of the judgment:</p>
<blockquote>
<p>It follows that Clause 4(a) and Clause 5(a) and (b) in that annex oblige the controller established in the European Union and the recipient of personal data to satisfy themselves that the legislation of the third country of destination enables the recipient to comply with the standard data protection clauses in the annex to the SCC Decision, before transferring personal data to that third country. […]</p>
</blockquote>
<p>Translated to normal English: the SCC terms require the data exporter and data importer to check that the legal environment in the destination country actually allows the importer to comply with the terms of the SCCs. Since Schrems-II, it is common to prepare a &quot;transfer impact assessment (TIA)&quot; that contains such analysis.</p>
<h2>Options for valid SCC-based international transfers</h2>
<p>A Schrems-II compliant data transfer based on SCCs could work in the following scenarios:</p>
<ol>
<li>there are no problematic laws in the destination country</li>
<li>while there might be problematic laws, they do not apply to the data importer</li>
<li>even if the data importer is subject to problematic laws, supplemental safeguards such as end-to-end encryption prevent the personal data from falling into unauthorized hands</li>
<li>(unofficial theory:) even if the data importer is subject to problematic laws, the risk of these laws being invoked is negligible in practice</li>
</ol>
<p>Let's analyze these options for the case of EU to US transfers:</p>
<ol>
<li><p>The Schrems II case seems to deny the first option, since it explicitly found that the lack of legal redress means that the US do not provide an &quot;adequate&quot; level of data protection. After the judgment, some such as the US government argued that this was based on outdated laws (cases take a long long time), and that the current legal environment is perfectly fine. After additional changes to US government policy, the EU Commission later joined this argument and issued a new &quot;Data Privacy Framework&quot; adequacy decision in 2023.</p>
</li>
<li><p>I occasionally saw US companies arguing that they are not subject to problematic laws like FISA 702 because they are not a communications provider. If true, that may have been a valid argument.</p>
</li>
<li><p>The <a href="https://edpb.europa.eu/our-work-tools/our-documents/recommendations/recommendations-012020-measures-supplement-transfer_en" rel="noreferrer">EDPB published recommendations on implementing supplemental measures</a> such as pseudonymization or encryption to protect the GDPR-covered personal data even when it is processed in the US. However, these supplemental measures have to operate with an extreme threat model: successfully defending against access by US government three-letter agencies (NSA, FBI, CIA).</p>
<p>In practice, these recommendations ruled out any use of US-based cloud or SaaS services, and did not provide a reasonable option for continuing EU→US data transfers. But since claims about supplemental measures are easier to make than to verify (and since most data protection authorities did not actively seek out potential data transfer violations), this was a very common choice. Supervisory authorities note that details about the supplementary measures should be provided to data subjects on request, but this has been rare.</p>
<p>Where I have seen details about such measures, they were usually techniques like transport encryption (like HTTPS) and encryption at rest, which fall clearly short of the EDPB recommendations. Sometimes, I've seen attempts at anonymization, but usually implemented for an US-centric view of &quot;PII&quot; that ignores the nuances of the GDPR's &quot;personal data&quot; concept. Techniques that could actually work – like homomorphic encryption – have been largely absent in this space, but that unsurprising given the novelty and overhead of such technologies.</p>
</li>
<li><p>The EU's CJEU did not permit a risk-based approach to TIAs, but it has found blessing in the UK, and it has been widely practiced by industry.</p>
</li>
</ol>
<h2>In B2B, the customers might be on the hook</h2>
<p>In a B2B context, there is another aspect: Who is the data controller who is primarily responsible for GDPR compliance? Often, we have a US SaaS provider who offers a pre-formulated DPA/SCC, and an EU-based customer company. In many cases, the EU-based customer will be the data controller, and responsible for the international data transfer. The SaaS provider would typically be a &quot;data processor&quot;, who has no direct GDPR obligations and is only responsible for fulfilling their contract with their customers.</p>
<p>In such constellations, the US-based providers often advertise themselves as 100% GDPR-compliant, even though the real question is whether the customers can use that service in a GDPR-compliant manner.</p>
<h2>Figma's policies</h2>
<p>In the case of Figma, this means that most of the risk of having potentially invalid SCCs is not shouldered by Figma, but by their EU-based customers.</p>
<p>FYI, the <a href="https://help.figma.com/hc/en-us/articles/360041060434-General-Data-Protection-Regulations-GDPR-" rel="noreferrer">Figma GDPR FAQ</a> you linked in turn links to <a href="https://static.figma.com/uploads/6b3f57508ca7aa8464ae2a83809c8362c4a9b535" rel="noreferrer">their full DPA</a> (<a href="https://web.archive.org/web/20230719180626/https://static.figma.com/uploads/6b3f57508ca7aa8464ae2a83809c8362c4a9b535" rel="noreferrer">permalink</a>), which lists supposed supplementary measures in Exhibit C (in addition to the security measures in Exhibit B). These supplementary measures are of a solely organizational nature, such as consulting with expert legal counsel, nicely asking the government to contact the customer directly, and publishing an annual transparency report. The DPA also includes a transparency report, noting that between 1 July 2022 and 30 June 2022, zero US government requests were received, and that no court found Figma to be subject to FISA 702.</p>
<p>While I have my doubts about the suitability of such measures to <em>prevent</em> government access, a transparency report is useful for making risk-based arguments. I tried looking for their updated report which should be due this month, but realized that &quot;Figma Transparency&quot; is impossible to search for online :)</p>

gdpr data-protection