Why does the GDPR matter to me, a US citizen with no property in Europe? I run a Web site. I am a natural-born US citizen. I own no property outside the US. Why does my Web site have to be GDPR compliant? Even if a European court convicts me of a crime, does it really affect me?
As stated by GDPR article 3 you are required to follow it under the following circumstance: This Regulation applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to: the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or the monitoring of their behaviour as far as their behaviour takes place within the Union. You can read the recourse better at What is the legal mechanism by which the GDPR might apply to a business with no presence in the EU?, but in short the US will allow the EU court to press it's rulings due to wanting to keep its trades, treaties and other similar things in place.
Yes, it triggers the GDPR obligations Considerations: Can you surely identify those residing in Europe? In that case you should ask them to sign up again and confirm the consent. A lot of mailing lists are doing just that. Did they previously give consent and you can document it? If so, then you can argue that you have the required consent. Do you have business in Europe? If not then I don't think they would bother to go after you. You could just walk away from the fine. What other personal informastion are you storing? If you know who reside in Europe then you already have more info than just the email. The email address itself wouldn't be much of a documentation issue, SAR or Portability task.
The 2018 Data Protection Act specifically implemented the GDPR EU Regulation in the UK - while the regulation itself was directly binding it required member states to create their own legislation for implementing the details - setting up the required supervisory and accreditation bodies etc. The various 'opening clauses' in the regulation also provided the means for the members states to implement specifics in local legislation (so long as that legislation exceeded the minimums set out in GDPR). At the end of the Brexit transition period the UK was no longer a member state (and it's citizens were no longer EU citizens), keeping the DPA 2018 as was would have actually meant that UK citizens weren't eligible for the very protections it was intended to provide them! Therefore the basis of the law needed updating (as well as certain minor provisions that no longer made sense) hence the &quot;UK GDPR&quot; provided a substitute. The fundamentals are the same and crucially it also codified the necessary basis for the UK's data protection laws to have what is referred to as &quot;adequacy&quot; - which means that the EU considers the UK GDPR/DPA to provide &quot;essentially equivalent&quot; levels of protection and therefore data is allowed to continue to flow between the UK and the EU.
Is it GDPR compliant that I can't access the account that I created and the personal data that I shared because "I haven't completed their internal pre-qualification process"? Article 15 defines a “Right of access to the data subject” but it's difficult to see how this could be construed as a right to log into a specific website. Common sense suggests this would be a very bad idea. If they are willing to provide the data through another means (say a report or data dump of some sort), the obligation would seem to be met. In fact, article 15(3) even states that data controllers should merely provide the information in a “commonly used electronic form” (i.e. not necessarily through access to their systems or whatever form they are using internally for the processing). Have you asked for that and would you be satisfied by that resolution? Is it GDPR compliant that their answer to my deletion request is "We will delete the data..." The text of article 17 (right to erasure) explicitly specifies that such a request must be honored without “undue delay”. Article 12, which defines some of the modalities for the rights to access, rectification or erasure by the data subject, also provides that controllers shall “provide information on action taken on a request […] without undue delay and in any event within one month of receipt of the request”. You haven't provided any time frame and I don't think there is anything wrong with acknowledging the request by promising they “will” do it but in light of article 12, it seems you would indeed be entitled to know once they have actually taken further action. However, you implied you might want to access the data first and it's not clear to me whether you explicitly invoked the GDPR in earlier communications. So I would clarify and reiterate my request (access or erasure) and ask them for explicit confirmation once it has been satisfied.
IP addresses are personal data. That means you need a legal basis to process them, but not necessarily consent from the user. That IP addresses should be treated as personal data in most contexts is clear, regardless of whether you can associate the IP address with a user ID. That you make such an association affirms that both the IP address and user ID are personal data in your context though. As the answers in the questions you linked indicate, there are alternative legal bases to consent. The GDPR offers a choice of six legal bases (Art 6(1) lit a–f). In most cases, you would instead rely on a “legitimate interest” for logging. But it's not enough to claim that you have a legitimate interest. You must have a clear purpose for which such logs would be necessary, and you would then have to weigh this legitimate interest against the interests, rights, and freedoms of the affected data subjects. If such logs are necessary for security and anti-abuse purposes, your legitimate interest test is likely to prevail. However, you must limit retention of the logged data and the included information to what is actually necessary. For example, keeping user IDs in there might not be necessary. If the association of IP addresses and user IDs is not necessary for a legitimate interest, then you would indeed need consent. Discussion on why IP addresses are personal data. You see many answers and opinions that IP addresses might not be personal data. Some of these are technically correct, but most are misinformed or outdated. I know only a single well-informed person that still disagrees. For everyone else such as the EU Commission, IP addresses are clearly personal data. Under the GDPR, personal data is any information that relates to an (indirectly) identifiable natural person. In the context of log files we can assume that the entries usually “relate” to a person, namely the person making the request. The exception would be requests triggered by automated systems. The more interesting question is whether the person to which the log entry relates is identifiable. While the GDPR does provide further guidance on the concept of identification in Recital 26, it does not provide clear unambiguous criteria. Thus, there is lots of debate about what that precisely means. One approach is to sidestep that debate and and notice that the GDPR's definition of personal data explicitly notes that a person might be identified “in particular by reference to an identifier such as a name, an identification number, location data, an online identifier” (Art 4(1)). Another but otherwise unrelated part of the GDPR mentions “internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags” as examples of online identifiers (Recital 30). We can also look more deeply into Recital 26 and see that “singling out” already counts as identification. We can use the IP address to single out one person's log entries from the set of log entries, so this could be interpreted as meaning that any stable user ID renders the data personal data – and an IP address is sufficiently stable in this context. Another part of Recital 26 says that we must consider “all the means reasonably likely to be used” for identification, even if this involves additional information from third parties. This phrasing is virtually identical to the GDPR's predecessor, the EU Data Protection Directive. On the basis of that DPD, the EU's top court (ECJ/CJEU) was asked to rule on the question whether dynamic IP addresses are personal data (the Breyer case, C‑582/14, judgement from 2016-10-19). It said yes. “It did not say yes”, some people will object. And they are technically correct. When someone rents an internet connection from an ISP, the ISP will have logs that connect the user's real-world identity to the IP address they were assigned at a time. You don't have access to the ISP's logs. But, if that user violated your rights (e.g. a cyberattack or copyright infringement), then you could (depending on civil vs criminal matters) report this to the appropriate authorities or to petition the court and they would have the right to order the ISP to disclose this information. The CJEU said that if this chain (you → authorities → ISP → user identity) is grounded in law, then the IP address would be identifiable. But whether there are suitable laws to compel the ISP to disclose this data would be up to national laws, and the CJEU doesn't concern itself with that. Spoiler: such laws are pretty common. To summarize typical objections: The IP address doesn't relate to a person: Can be a valid objection, but is not typically the case for user-facing web services. The Recital 30 argument is not valid because it's about profiling, not identification, and it only says that IP addresses may be used for profiling, not that they are always identifying: Technically correct, but I think that Recital 30 merely expresses the implied understanding that of course an IP address is an online identifier and permits identification by itself. “Singling out” does not apply because SOME_REASON: Indeed, this is an ill-defined term with no case law to guide us. However, regulators such as the EDPB and their predecessor WP29 routinely use “singling out” to mean being able to distinguish one person's data from other people's data. An IP address lets us do that. The Breyer judgement is not applicable because the defendant in that case was the German state, and the state has other legal means than ordinary website operators: Nothing in that case was specific to the website operator being a state or other authority. If the website operator can contact the appropriate authority and if they have the right to order the ISP to disclose the relevant data, then the IP address is identifiable. The CJEU didn't say “yes” in Breyer, it said “if”. So I'll take that as a “no”: The CJEU concerns itself with the interpretation of EU law, not with national laws. Specifically in the Breyer case, lower courts confirmed that German law has the necessary means. In other EU member states, further checks would be necessary but it would surprise me if there wouldn't be equivalent subpoena powers. If the ISP doesn't have the data, then the IP addresses are anonymous: Indeed, the CJEU scenario collapses if there is no additional data to be linked with the IP address. However: The CJEU used this scenario as an example to show that IP addresses can be identifiable. If that particular scenario fails, there could be other scenarios that still allow identification. The question of whether IP addresses are identifiable had of course been the subject of wider debate at the time. That the GDPR explicitly mentions IP addresses can be seen as a reaction to this debate. Thus, in a sense, the Breyer case is moot. It is still useful as an explanation of how broad “reasonably likely means” must be interpreted.
This issue touches upon two distinct GDPR rights: Art 15 right to access: you have a right to receive a copy of all personal data concerning you that are undergoing processing (including storage). Access may only be denied where this would “adversely affect the rights and freedoms of others.” Art 20 right to data portability: if processing is being carried out by automated means, and processing is based on certain legal bases (consent or contract, but not legitimate interest), then you have a right to receive a copy of your personal data in a machine-readable format, for personal data that you have provided to the data controller. Whereas the right to access is fairly straightforward, the right to data portability applies under much more narrow conditions. Basically, it's a right that you can download any data that you've uploaded so that you can move to a different service. Google Takeout is primarily concerned with your right to data portability, and provides your data in a machine-readable format. Any photos that you've uploaded to Google Photos, you'll be able to download. Thus, it could be technically compliant to exclude information that they've inferred about your personal data, such as image-recognition results. Such results would still be personal data under the GDPR definition of the consent, and would be covered by your right to access. Google might argue that you already have access to this data through the web interface. In my opinion the GDPR clearly requires the data controller to provide a “copy”, i.e. the data in some durable form – not merely access through a web interface. Whereas your question is specifically about Google, the same issue applies to other services as well. E.g. Ruben Verborgh has an interesting blog series on trying to get access to all their data from Facebook, though unsuccessful so far. Similar to your scenario, Facebook offers a download for personal data but does not include all personal data in this download. In one of the documents provided by Facebook in the course of the exchange, they note that they allow access to photo tags through the web interface, but do not include this in downloaded data – without providing further justification.
No, it is not legal. Regardless of their location, the only legal options for companies serving to EU residents are to either deny access altogether or to make consent truly optional1 Recital 42 states (emphasis mine): Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject’s agreement[...] Recital 43 states: Consent is presumed not to be freely given [...] or if the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance. 1 Of course, remember that consent is only one of several means that allow them to process data. For example, if you were getting a trial account for a limited time, it would be considered a legitimate business need to ensure that you are not just opening new trial accounts when the old ones expire. So, if they wanted some data from you to ensure that you are not a previous user and you refused to provide it, then they could deny giving you that trial account without breaking the GDPR.
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. Definition of an international data transfer The GDPR unfortunately does not define what an international transfer is, and just explains when they may be lawful: 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 […]. […] This has been interpreted, in particular by the official EU SCCs and by EDPB guidance, to imply two roles: the data exporter, and the data importer. Per those EDPB guidelines, a transfer occurs when three criteria are fulfilled together: 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). The exporter discloses or makes available personal data to the importer. The importer is in a &quot;third country&quot; (for EU GDPR: anything outside the EU/EEA). 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. Applying this to your scenario How does this apply to your scenario? I am assuming Alice Inc is subject to the GDPR (criterion #1). Now, Alice Inc can process personal data, and that's not an international transfer, 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. 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. If those data importers are based in the EU/EEA, then criterion #3 is not fulfilled and there's no international transfer. For example, using an EU-based hosting providers would sidestep Chapter V of the GDPR completely. If those data importers are based outside of the EU/EEA, then criterion #3 is triggered and we have an international transfer. Lawfulness of international data transfers When there is an international transfer, it must be adequately protected. In order of decreasing priority: country has an EU adequacy decision appropriate safeguards for a group of companies: Binding Corporate Rules (BCRs) Standard Contractual Clauses (SCCs) Art 49 specific situations 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. 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. In the DPC Ireland decision against Meta Ireland (PDF), the DPC finds: 7.202 In summary, therefore, I am satisfied (and I so find) that: (1) US law does not provide a level of protection that is essentially equivalent to that provided by EU law; (2) Neither the 2010 SCCs nor the 2021 SCCs can compensate for the inadequate protection provided by US law; and (3) Meta Ireland does not have in place any supplemental measures which would compensate for the inadequate protection provided by US law. 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. Implications of using non-US vendors As already mentioned, using EU-based data processors avoids the international transfer problem due to the way how international transfers are defined. Even if an international transfer occurs, that might not be a problem. 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. 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. But isn't that a contradiction? You correctly point out a problem with the GDPR's approach to data transfers: 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. Yes, this is arguably a loophole. However: 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. 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). 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. This won't help Meta 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.