united-states gdpr is-x-legal
Does a US company moving its PII and web servers to the EU solve the Meta fine problem?
<p><a href="https://law.stackexchange.com/questions/92634/are-global-user-account-systems-now-illegal-following-facebook-fine">As discussed in this question</a> <a href="https://www.theguardian.com/technology/2023/may/22/facebook-fined-mishandling-user-information-ireland-eu-meta" rel="noreferrer">about the Meta fine</a> it is a problem for companies that host websites with access to EU user registration data in US datacenters.  This is based on the <a href="https://curia.europa.eu/juris/document/document.jsf?text=&amp;docid=228677&amp;pageIndex=0&amp;doclang=en" rel="noreferrer">'Schrems II' decision in 2020 that the EU-U.S. Privacy Shield</a> fails to protect Europeans' rights to data privacy when companies are transferring those data to the U.S.  The details and requirements are discussed by the <a href="https://iapp.org/news/a/the-schrems-ii-decision-eu-us-data-transfers-in-question/" rel="noreferrer">International Association of Privacy Professionals</a>.</p>
<p>Suppose Alice Inc. was in this situation, in that they are a US company with their websites running on the cloud in US datacenters, let us say in a single docker container with apache and MySQL and their simple site.  They could with a simple purchase of alternative hosting and a few commands deploy their webserver on an EU host.  This would however have little effect on the access to the data, in that if US law enforcement turned up at the offices of Alice Inc. they could be required to hand over the data and their access to the data will not be changed in any way by the location of the web hosting.</p>
<p>If they did this, would this satisfy the particular aspect of the GDPR that was covered by the 'Schrems II' decision and the Meta fine?</p>

<p>Maybe this changes something, maybe not. But at first glance, yes, avoiding US-based vendors does help comply with Schrems II. They need not be EU-based.</p>
<h2>Definition of an international data transfer</h2>
<p>The GDPR unfortunately does not define what an international transfer is, and just explains when they may be lawful:</p>
<blockquote>
<p>Art 44: Any transfer of personal data which are undergoing processing or are intended for processing after transfer to a third country […] shall take place only if, subject to the other provisions of this Regulation, the conditions laid down in this Chapter are complied with by the controller and processor, including for onward transfers of personal data from the third country […] to another third country […]. […]</p>
</blockquote>
<p>This has been interpreted, in particular by the official EU SCCs and by <a href="https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052021-interplay-between-application-article-3_en" rel="nofollow noreferrer">EDPB guidance</a>, to imply two roles: the data exporter, and the data importer. Per those EDPB guidelines, a transfer occurs when three criteria are fulfilled together:</p>
<ol>
<li>The data exporter is subject to GDPR (e.g. as a controller via Art 3, or as a processor via an Art 28 data processing contract).</li>
<li>The exporter discloses or makes available personal data to the importer.</li>
<li>The importer is in a &quot;third country&quot; (for EU GDPR: anything outside the EU/EEA).</li>
</ol>
<p>Note that these importer/exporter aspects are independent from roles like &quot;controller&quot; or &quot;processor&quot;. It also does not depend on where in the world the exporter is situated.</p>
<h2>Applying this to your scenario</h2>
<p>How does this apply to your scenario?</p>
<ul>
<li><p>I am assuming Alice Inc is subject to the GDPR (criterion #1). Now, Alice Inc can process personal data, and <strong>that's not an international transfer</strong>, even if Alice Inc is in the US (or any other third country). The general GDPR rules apply, such as the requirement to implement appropriate technical and organizational measures to ensure compliance and security of processing operations.</p>
</li>
<li><p>If Alice Inc engages data processors to process personal data on Alice Inc's behalf, then this would fulfil criterion #2 (disclosure to a third party). For example, hosting providers generally act as data processors. Any other kind of data sharing (e.g. to other data processors) would also fall under this category. Tricky in an US context: while employees would be agents of Alice Inc and would not be separate recipients, contractors/freelancers would also be potential data importers.</p>
</li>
<li><p>If those data importers are based in the EU/EEA, then criterion #3 is not fulfilled and <strong>there's no international transfer</strong>. For example, using an EU-based hosting providers would sidestep Chapter V of the GDPR completely.</p>
</li>
<li><p>If those data importers are based outside of the EU/EEA, <strong>then criterion #3 is triggered and we have an international transfer</strong>.</p>
</li>
</ul>
<h2>Lawfulness of international data transfers</h2>
<p>When there is an international transfer, it must be adequately protected. In order of decreasing priority:</p>
<ul>
<li>country has an EU adequacy decision</li>
<li>appropriate safeguards
<ul>
<li>for a group of companies: Binding Corporate Rules (BCRs)</li>
<li>Standard Contractual Clauses (SCCs)</li>
</ul>
</li>
<li>Art 49 specific situations</li>
</ul>
<p>What SCCs and BCRs do is to translate enough of the GDPR from statutory law into a contract to ensure adequate protection. But to be effective, they must actually be enforceable, and the data importer must actually be able to comply with those rules.</p>
<p>In Schrems II, the CJEU found that the US (at that time) did not offer an adequate level of data protection, and that SCCs are probably invalid as well since importers cannot comply with both the SCCs and with US surveillance laws. Before using SCCs, it is effectively necessary to perform a transfer impact assessment (TIA) analyzing, among other things, the legal context of the importer's country. It may be possible to defuse this, for example by using supplemental security measures like end-to-end that prevent unlawful use of the data even if it falls into the wrong hands. However, such measures also tend to prevent intended use, especially in a cloud context.</p>
<p>In the <a href="https://edpb.europa.eu/system/files/2023-05/final_for_issue_ov_transfers_decision_12-05-23.pdf" rel="nofollow noreferrer">DPC Ireland decision against Meta Ireland (PDF)</a>, the DPC finds:</p>
<blockquote>
<p>7.202 In summary, therefore, I am satisfied (and I so find) that:</p>
<p>(1) US law does not provide a level of protection that is essentially equivalent to that provided by EU law;<br />
(2) Neither the 2010 SCCs nor the 2021 SCCs can compensate for the inadequate protection provided by US law; and<br />
(3) Meta Ireland does not have in place any supplemental measures which would
compensate for the inadequate protection provided by US law.</p>
<p>7.203 Accordingly, in making the Data Transfers, I find that, subject to the analysis contained at Section 8 below, Meta Ireland is infringing Article 46(1) GDPR.</p>
</blockquote>
<h2>Implications of using non-US vendors</h2>
<p>As already mentioned, using EU-based data processors avoids the international transfer problem due to the way how international transfers are defined.</p>
<p>Even if an international transfer occurs, that might not be a problem.</p>
<ul>
<li><p>Some countries have an EU adequacy decision, for example Canada, Israel, or South Korea. While there would nominally be an international data transfer that needs to be disclosed e.g. in a privacy notice, there is no additional bureaucracy required.</p>
</li>
<li><p>In other countries, transfer tools like SCCs might work. A TIA might show that that the issues discussed in the Schrems II decision and the DPC decision wouldn't apply there.</p>
</li>
</ul>
<h2>But isn't that a contradiction?</h2>
<p>You correctly point out a problem with the GDPR's approach to data transfers:</p>
<blockquote>
<p>This would however have little effect on the access to the data, in that if US law enforcement turned up at the offices of Alice Inc. they could be required to hand over the data and their access to the data will not be changed in any way by the location of the web hosting.</p>
</blockquote>
<p>Yes, this is arguably a loophole.</p>
<p>However:</p>
<ul>
<li><p>If the US-based Alice Inc is a data processor in behalf of another controller, that controller would likely be violating the GDPR by transferring personal data to Alice.</p>
</li>
<li><p>If Alice Inc is a data controller: while this might not be a violation of the Chapter V rules on international data transfers, such a scenario could be argued to be an Art 24 or Art 32 violation instead (requirement to ensure compliance and security).</p>
</li>
<li><p>When Alice Inc transfers personal data to data importers, that is less visible to data subjects, and outside of their immediate control. However, when Alice Inc collects data on data subjects, that is more visible to data subjects, in particular through an Art 13 or Art 14 privacy notice. That notice must also contain the identity of the data controller, which would disclose that Alice is US-based, which may enable to data subjects to make more informed choices.</p>
</li>
</ul>
<h2>This won't help Meta</h2>
<p>While moving to non-US data processors can be a sensible compliance approach for many companies, it is less useful for multinationals like Meta. In this context, Meta is an Irish data controller who engages platform and development services from an American company. Even if Meta Ireland tries to perform all GDPR-covered processing activities outside the US, it's actual corporate structure situates some processing activities such as administration tasks in the US and other third countries. If my above analysis is correct, it would have been easier for Meta to comply with GDPR if the US-based Meta company were the data controller.</p>
