What is the legal mechanism by which the GDPR might apply to a business with no presence in the EU? My family has a small side business selling some things through the internet. As far as I know, we aren't likely to have any customers who are EU citizens, but it's certainly not outside the realm of possibility, and I wouldn't be opposed to shipping to the EU if I got an order from someone in an EU country. However, in reading about the GDPR, I have mostly seen what appears to me to be bare assertion of the GDPR's global applicability to any business, anywhere, who transacts with an EU citizen. My business only has a presence in the US. I am not a citizen of the EU, I'm not represented in any legislative body in an EU nation, neither am I represented in the European Parliament. I am not a subject of the EU in any way, shape or form. Why would the EU expect that any of its laws would apply to my business? More importantly, regardless of what the EU regulators think, how could they possibly enforce any of it against me?
Why would the EU expect that any of its laws would apply to my business? It doesn't. Unless you choose to do business in the EU (which is possible, thanks to the wonders of the World Wide Web). Then, and only then, do you have to comply with EU law, including the GDPR. From a comment by @BenCollins: I'm talking about non-EU online retail that does allow Europeans (particularly those not actually in the EU at the time of the transaction) to place orders. Basically, GDPR Article 3 says that the GDPR applies to the processing of personal data of data subjects who are in the Union The phrase &quot;in the union&quot; is clearly open to interpretation, but according to the website Security Now, Dr. Michèle Finck says this: Most people seem to agree that the relevant criterion is whether you're based in the EU at the moment data is collected - citizen or not (my emphasis). While Michèle Finck is a well-respected legal scholar, she is not an authoritative legal source, so we need to wait for to case-law to nail this. For what it is worth, (not much I am afraid) I think it would be against common sense to define the territorial scope so broad that brick and mortar stores in the USA risks to be prosecuted in Europe if they sold goods or services to European tourists. However, what most US based businesses that chooses to be open to business for orders that are placed by natural persons who are in the [European] Union need to know that there is this: According to European law, the GDRP does apply to them when they conduct such business. From a comment by @BenCollins: I question the notions that (a) there is a basis by which the law would apply The legal basis is European law, in particular GDPR Article 3. and (b) that it has any enforcement mechanisms outside the EU. As for enforcement, I think a good answer has already been provided by Dale M. but for completeness: The USA has treaties with EU that mean that after a legal case has been decided in a court of law in the EU, it can request that the USA enforce the judgement (typically by collecting the fine the USA-based business incurred when conducting business in Europe). To make this answer more general, here are a breakdown of the the regulation of territorial scope of the GDPR for businesses that are not located in the EU: The scope is clearly spelled out in Article 3, and if you're not &quot;a controller or a processor in the Union&quot;, you are only subject to the GDPR if your processing activities are related to: a) 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 b) the monitoring of their behaviour as far as their behaviour takes place within the Union. US based companies that engage in business practices that are illegal in Europe know about this, and has already taking steps to protect themselves from the being prosecuted in Europe under the GDPR by using firewalls to block access to their services from the EU. The bottom line is that if you: have no presence in Europe, and don't offer goods or services to people who are in the Union, and you don't collect personal data about European natural persons, then the GDPR does not apply to you. If at least one of the above applies then you need to follow the GDPR if you do not want to be prosecuted in the EU.
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.
The data processor is not responsible for complying with the GDPR. You are ultimately responsible, since you are the data controller. The data processor is merely required to assist you, but it's unclear what that means in the presented scenario. Per Art 28(3)(e) GDPR, the DPA must require the data processor to provide reasonable assistance: That contract or other legal act shall stipulate, in particular, that the processor: […] taking into account the nature of the processing, assists the controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the controller’s obligation to respond to requests for exercising the data subject’s rights laid down in Chapter III; However, per Art 28(1) you can only engage processors that you deem sufficient to protect the data subject's rights: the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject. Here, it seems that your company failed to ensure that the processor provides the features you need for compliance. Many companies claim to be GDPR-compliant, but that doesn't mean that your use of their services will be GDPR-compliant as well. Depending on how the Art 28(3)(e) requirement was implemented in the DPA you may have a right to assistance even if the processor doesn't implement necessary features in their software, but enforcing this contract could require a lawsuit in a foreign jurisdiction (but that's par for the course for international B2B contracts). It is worth noting that the GDPR right to erasure doesn't always apply. In a processing activity where no erasure right is likely to arise, it would be perfectly fine to use a data processor that doesn't offer any possibility for erasure. Similarly, it can sometimes be legal to use technologies like Blockchain or Git that make erasure difficult or impossible. However, it is the responsibility of the data controller to analyze the impact of such a choice up front, before commencing the processing activities. In some cases, this could require a Data Protection Impact Assessment (DPIA). Note that transfers of personal data into the US are illegal or at least questionable in the wake of the 2020 Schrems II ruling. The Privacy Shield is no longer a legal basis for such transfers. Standard Contractual Clauses (SCCs) are technically allowed, but only “on condition that enforceable data subject rights and effective legal remedies for data subjects are available” (cf Art 46). The ECJ's judgement calls this into question. This could be a further incentive to migrate to a more GDPR-compliant service.
GDPR rights and obligations cover different things: A duty of the data processor towards the government of the country where they operate to present certain documentation, and to implement technical and organizational measures to protect data. These would be audited by government agencies, not the individual customer. A single data subject cannot waive them. A duty of the data processor to process and store personal data only with a legal justification. User consent is one possible justification, if it is informed, revokable, etc. So a single data subject can waive a &quot;ban&quot; on storing his or her data in a database along with all the other users who waived that &quot;ban,&quot; but the duties towards the government regarding that data would still apply. A duty of the data processor to respond to an Article 15 request by the data subject in a certain way and timeframe. If a data subject writes a letter to the data processor and explicitly states that the letter is not an Article 15 request, then Article 15 does not apply. The data subject would of course have the right to make an Article 15 request at a later time.
If you want some boilerplate text to just drop in and have done, you are going to be disappointed. But you don't need a lawyer either. Treat it as a coding job. First, list all the ways you are going to store and process identifiable user data. If someone is going to process it on your behalf, identify them too. Draw a chart showing the paths that user data is going to take. (Storage is a form of processing) Then look at the 6 bases for processing user data and figure out which ones apply to each step. E.g. if the user asks you to do something then that is one basis under which you can process their data. See how much coverage you can get without asking for consent. For each third party (e.g. Google) figure out what data is to be sent to them, and where they will be. Google has data centres in the EU specifically so you can get them to process user data without sending it outside the EU. Check the third party contracts for these services, including the confidentiality clauses. Link that to the processing they will do for you. Finally, pull all this together into a single summary of what you are going to do with the data and the bases under which you will do it.
The GDPR as such puts obligations on the Data Controller (DC), that is the person or firm or other entity who determines the purposes for which data is processed. The entity that hires the developer and operates the web site is responsible for compliance with the GDPR and other laws and regulations, such as the e-privacy directive and its implementing laws. However, it is highly likely that in commissioning a web site the DC would specify that it be designed to aid compliance with the GDPR and other relevant laws, and if the developer did not do that it might be a breach of contract. Indeed, even if GDPR-friendliness was not explicitly required by the contract between the developer and the DC, the implied warranties of merchantability and fitness for the purpose would probably apply. A designer who, knowing the site is to be hosted and operated within the EU, failed to design it to facilitate GDPR compliance might well be in violation of those warranties. But that would depend on the specifics of Italian law. But note that GDPR compliance is not a matter of web site design, but of the ongoing practices of the operation of the site. There are various ways to comply with the GDPR, no specific technology or design need be used. The DC must so operate the site as to comply. If the DC fails to do that, penalties could be imposed on the DC, not on the developer.
Corrections to your statements or quotations Your quotation "To fall within the remit of the GDPR, the processing has to be part of an "enterprise" (...)" is not from the GDPR, and is an erroneous statement. Also, the threshold of 250 employees you refer to, is only relevant with regards to the record-keeping obligations of Article 30. GDPR provisions relevant to your question The GDPR applies to individuals or students in accordance with the material scope of the GDPR, which is treated in Article 2 (2) c) where GDPR states that "This Regulation does not apply to the processing of personal data: (...) by a natural person in the course of a purely personal or household activity;" The Recital 18 of the GDPR gives some insight as to what would be a purely personal or household activity as follows: (18) This Regulation does not apply to the processing of personal data by a natural person in the course of a purely personal or household activity and thus with no connection to a professional or commercial activity. Personal or household activities could include correspondence and the holding of addresses, or social networking and online activity undertaken within the context of such activities. However, this Regulation applies to controllers or processors which provide the means for processing personal data for such personal or household activities. Interpretation To my knowledge, there are no specific guidelines regarding this matter to date from WP29. Those may be adopted in the future, or some requirements may already exist in local laws in one of the EU countries or from documentation available from local data protection authorities. If you are based in the EU, you could check this with your local data protection authority. There is, however, case law from the European Court of Justice as pointed out by Free Radical, interpreting the scope of the "personal use exception" in Directive 95/46/EC (which provisions are similar to the GDPR in this matter). If your hobby is not limited to your personal circle (yourself and the persons in your household), and thus if you plan to share the results of your data collection and processing with third parties (possibly teachers, other fellow students, or anybody else if you publish the results of your work) resulting from your "hobby" activity, you certainly would not fall in this exception to the scope. Case C-101/01 is an example of publication on the Internet made by an individual claiming to use its "freedom of expression to create internet pages in the course of a non-profit-making or leisure activity". The court clarified that: exception must (...) be interpreted as relating only to activities which are carried out in the course of private or family life of individuals, which is clearly not the case with the processing of personal data consisting in publication on the internet so that those data are made accessible to an indefinite number of people Another, less optimistic interpretation from the examples given by the GDPR recitals, could derive from the spirit in which purely personal or household activity are to be understood. These examples actually refer to limited amounts of data and which are related to the individual itself (his own address book, his social networking activity, etc.), and creating limited risks relevant to the person herself and its contacts. In this view, there is a risk that a "hobby" in which you collect data about thousands of persons unrelated to you, could be considered as not being really purely personal. Actually, an interpretation of case law C-212/13 from the European Court of Justice also mentioned by Free Radical could support this reasoning. In this case, a video recording of people was stored from cameras installed by an individual on his family home for its own security purposes, but the cameras were also monitoring a public space. The court ruled that: To the extent that video surveillance such as that at issue in the main proceedings covers, even partially, a public space and is accordingly directed outwards from the private setting of the person processing the data in that manner, it cannot be regarded as an activity which is a purely ‘personal or household’ activity (...) Extending this reasoning to your question, a "hobby" consisting of collecting "huge list of names, emails, zipcodes" unrelated to you could be regarded as "directed outwards from the private setting (...)". Conclusion As a hobbyist, or a student, if you can work on fake computer generated data and achieve the same results in your personal learning purposes you should definitely consider doing so.
Term 1 isn't going to hold up, but that is not a GDPR matter. It's just a matter of basic consumer protection law in the EU. You can't offload responsibility for your mistakes. Looking at 2, Dale M. already pointer out that it's now how the GDPR works. You are the Data Controller. X,Y and Z are Data Processors. Article 28(1) of the GDPR is in direct conflict with your disclaimer. You accept zero responsibility, the GDPR says you are fully responsible. That's the exact opposite.