Is it possible for non-EU companies to avoid GDPR regulatory issues through filters and firewalls? Background Most internet feeds are unfiltered. Everyone who has ever rented or set up a server knows malicious traffic comes in from all over the world, including the European Union (but mostly from other places), as soon as a server is online, and passwords, keys, and/or facilities to firewall malicious traffic need to be ready beforehand. Scenario Small Town News USA Inc. (a fictional company) operates a newspaper and web site about Small Town, USA. Primary customers live in Small Town, USA. Recently, their corporate lawyer has suggested they need to pay several thousand dollars to do preparation and paperwork for European GDPR regulatory compliance that affects businesses worldwide with any EU citizen data. Management, thinking it would be less expensive to filter and inconvenience maybe 5-10 travelers and remote viewers who are accessing the website from Europe, decides that the easiest way to deal with GDPR liability is to reject internet traffic from non-USA viewers. Unfortunately, the commonly available technology to do this involves IP-sniffing. In more detail, a web server is designated as a &quot;firewall/Nginx-reverse-proxy&quot; and would take a connection , examine the IP address (personally identifiable information under GDPR; see FAQ What Constitutes Personal Data?) and then forward only USA connections to a different server containing the Small Town News web site. But &quot;Rejected&quot; connections are still processed by sending back a web page containing only: &quot;Sorry, we can't serve you at your current location.&quot; IP addresses and times are recorded in the web server logs. Furthermore, IT staff want web server logs to include IP addresses so that they can ban malicious traffic. This involves automated processing of behavioral data and also storing bad-behavior IPs in other files that update the firewall data, which is held in an operating system table. It turns out the USA-only filter is an imperfect technological measure. It does not filter out 100% of EU-resident traffic. First, there is no perfect mapping of IP addresses to locations. For instance, an IP address apparently owned by the US Navy could be traffic coming from an EU-resident civilian contractor on his lunch hour who works at a US naval base in, e.g. Italy. An EU-resident visitor to the USA could still access the full website from the USA. Another EU-resident could buy VPN (Virtual Private Network) service to disguise their computer's true location, and that could involve forwarding their traffic from a point within the USA which would allow fetching the full Small Town News website because the Small Town News firewall received a USA IP address. Enforcement For those who think this is scaremongering and unenforceable, perhaps read: How the EU can fine US companies for violating GDPR which isn't entirely certain, but does suggest the possibility of US cooperation for collecting EU civil fines. Maybe Location-sniffing is also illegal... The article &quot;Why the US and Other Non-European Companies Need to Comply with the GDPR&quot; on busineessknowhow.com claims: &quot;... identifying people within the EU and refusing them access to your site or service based on the geolocation of their IP address - is actually specifically prohibited by GDPR. GDPR contains a prohibition against 'profiling', which GDPR defines as &quot;any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyze or predict aspects concerning that natural person's performance at work, economic situation, health, personal preferences, interests, reliability, behavior, LOCATION or movements.&quot; Since this doesn't cite specific sections of the 100+ page regulation, I don't know if it is correct. It all sounds like a great welfare project for lawyers, regulators, and IT pros who take the time to specialize in this area and bad for the creative entrepreneur who simply wants to put something online. Question Is Small Town News GDPR compliant under their (unfortunate) EU-blocking policy? Or can they only become compliant by outsourcing the filtering to some other company, who can be the scapegoat when filtering is imperfect?
Yes, this is a viable option. And no, it doesn't need to be perfect. The use of such a filter is a technical means, but it also serves to communicate that Small Town News explicitly does not envisage to provide service to Europeans or others resident in the EU. If a user chooses to use a VPN to do visit Small Town News webpages, it's reasonable to expect that this would be comparable to buying the Small Town News paper in print while physically in the USA. It's a common principle that courts have to decide on jurisdiction, and actions of a party can factor in this decision.
Please note that Google Analytics do not anonymize the data you collect on its behalf unless you configure it to do IP-anonymization. If you use Google Analytics and do not use this feature, you need to have a DPA (Data Processing Addendum) in place with Google in order to comply with the GDPR. This is a real hassle, so unless you absolutely need fine-grained demographic data, it is strongly recommended that you use IP-anonymization. According to our data protection supervisory authority, this is sufficient to comply with the GDPR vis-a-vis Google Analytics. Does data that is anonymized need to be collect in the event of a GDPR Subject Access Request? No. But as the controller, you need to make sure that is is anonymized.
Yes, there would still be an obligation to comply with erasure requests – if the data subject can be identified, and if the GDPR applies. This is a case for Art 11 GDPR: processing which does not require identification. The pastebin site is not required to collect identifying info just in order to facilitate later deletion. If the site is unable to identify the data subjects, then the data subject rights (like access, rectification, erasure, restriction, or data portability) do not apply. Other rights like the right to be informed and the right to object do remain, though. But if the data subject provides sufficient additional information that makes it possible to identify their records, then the data subject rights apply again. In practice, this is likely going to mean that anyone with access to a paste will be able to request deletion, since the site would have no ability to verify the identity of the data subject beyond the information in the paste. None of this absolves the site from implementing appropriate technical and organizational measures to ensure the security of this data. Even though the pastes might not be directly identifying, they are personal data and are far from anonymous. Common practices like numbering pastes with a sequential ID or showing recent pastes on a homepage have to be viewed critically. My go-to recommendation is to assign a cryptographically random UUIDv4 ID to the post, so that it is practically impossible for anyone to find the paste unless they were given a link by the uploader. Your idea to delete pastes after a fairly short retention period is also good. This helps with security, and it is in line with the GDPR's data minimization and storage limitation principles: data may only be kept as long as necessary for its purpose. On the other hand, quick deletion might not be in line with the purpose of these pastes – it all depends on context. You mention that this is an US-based site. If so, there's a question whether GDPR would even apply. GDPR will apply per Art 3(2) if the data controller is offering its services to people who are in Europe. Here, “offering” does not mean mere availability of the website, but that the data controller intends the service to be used by such people, in particular if the service is somehow targeted or marketed to such people.
The GDPR applies regardless of where and how data is processed. But it is necessary to look at what the processing activities in question are, and who is the controller for these activities by determining their purposes and means. This argument is supported: by the absence of relevant exemptions in the GDPR by the GDPR's broad definition of the data controller by the ECJ's analysis in the Fashion ID case GDPR Exemptions For certain constellations (e.g. controller = natural person, purposes = purely personal or household activities) that processing is exempt from GDPR compliance (see GDPR Art 2(2)). However per GDPR Recital 18, the GDPR would still apply “to controllers or processors which provide the means for processing data for such personal or household activities.” For example, this means that I am able to use WhatsApp to process my friends' contact information for purely personal purposes because I'm exempt from the GDPR with respect to that processing, but Facebook is still subject to the GDPR regarding how they process personal data collected via WhatsApp. Already on the basis of the GDPR providing no exception for processing on someone else's computer, I disagree strongly with the answer you cited (and have already written a competing answer). It seems entirely counterfactual. How to figure out who the controller is. Per GDPR Art 4(7), controller is whoever “alone or jointly with others, determines the purposes and means of the processing of personal data”, although other laws might provide more specific criteria for individual purposes or means. We will return to that definition in the next section. The ICO has provided a checklist to figure out if you're a data controller or perhaps a joint controller. Some of the questions are aligned with the above definition, like “We decided what the purpose or outcome of the processing was to be”. Other questions are there as a contrast to the data processor role, e.g. “We have complete autonomy as to how the personal data is processed”. Analysis of the Fashion ID case (ECJ C-40/17) This judgement provides a detailed analysis of who the data controller is, and is therefore relevant to the question. Fashion ID had embedded a Facebook “Like” button on their website, thus causing the visitor's browser to transmit personal data to Facebook. Fashion ID asserted that they were not the data controller, since they had no control over what data was collected by the Like button and how it was subsequently used by Facebook. Fashion ID relied in part of the argument that they weren't the controller because processing happened on the visitor's computer. This ruling was made on the basis of the Data Protection Directive 95/46 which was repealed by the GDPR. However, since the DPD and GDPR have effectively identical definitions of “controller” and “processing”, the court's analysis remains highly relevant. In the following I'll “translate” all DPD references to the GDPR, in analogy to GDPR Art 94(2). The court found that Fashion ID was a data controller for the processing by the Like button, and that it was a joint controller with Facebook for this processing. However, Fashion ID was only a controller for those processing activities in which they played a part, not for subsequent processing of the data that was controlled by Facebook alone. Relevant details from the Judgment (ECLI:EU:C:2019:629): Paragraphs 65–66: The GDPR tries to achieve a high level of data protection through a broad definition of “controller”. Thus, an overly narrow interpretation that counteracts this goal is incompatible with the law. Paragraph 68: An entity is a controller when it exerts influence over the processing for its own purposes, thereby participating in determining the purposes and means of processing. Compare the GDPR Art 4(7) definition of “controller”. case law: C-25/17 Jehovan todistajat, ECLI:EU:C:2018:551, paragraph 68: “However, a natural or legal person who exerts influence over the processing of personal data, for his own purposes, and who participates, as a result, in the determination of the purposes and means of that processing, may be regarded as a controller”. Paragraphs 67, 69–70, 82: It is not necessary to have a single controller, there can be multiple joint controllers. The joint controllers can be involved to different degrees. You can be a joint controller without having access to the personal data. case law: C-25/17 Jehovan todistajat, ECLI:EU:C:2018:551, paragraph 69: “Furthermore, the joint responsibility of several actors for the same processing, under that provision, does not require each of them to have access to the personal data concerned”. case law: C-210/16 Wirtschaftsakademie Schleswig-Holstein, ECLI:EU:C:2018:388, paragraph: 38: “In any event, [GDPR] does not, where several operators are jointly responsible for the same processing, require each of them to have access to the personal data concerned.” Paragraphs 71–74: Processing can consist of many different individual activities. A controller might only be involved in some of them, and can only be a controller for those activities for which they (jointly) determine purposes and means of processing. Paragraphs 76–79: Fashion ID was able to determine the purposes and means of processing regarding data collection and transmission by the Like button. The act of embedding the button showed that they had decisive influence over the processing: without the embedding, the data processing would not have occurred. To summarize the relevant conclusions: someone is a data controller when they participate in determining the purposes and means of processing for some processing activity for joint controllers, this holds regardless of whether they have access to the data or participate in the processing itself one cannot be a controller for a processing activity for which they cannot determine purposes and means. Conclusion and application to the question This analysis reaffirms my competing answer to the cited answer that it is important to determine who the data controller is. The Fashion ID case shows that is important to perform this analysis on a fairly granular manner, on the level of individual processing activities. For processing on a data subject's computer by a program written by another provider, this means: some processing activities might be solely under the user's control, then they are the sole data controller (or might be exempt from GDPR) for some processing activities, the software developer might decide alone for which purposes and through which means the processing is carried out for other activities, the user and data controller might be joint controllers. This does not require explicit agreement but can result implicitly. This does not require that the software developer has access to the personal data undergoing processing. For example, a spreadsheet application might be used by an end user to process personal data on their own computer (or via a cloud application, with the same conclusions). We can consider different processing activities performed by the software: sorting, transforming, and other processing of the data in the spreadsheet is solely under the end users control, so they are the data controller (if they aren't exempt) collecting usage analytics (where those analytics signals are personal data for which the end user is the data subject) is solely under the software developers control uploading crash reports (where those reports contain personal data from the end user and contain contents from the currently opened spreadsheet) is more complicated. The software developer is definitely a controller. The end user has a dual role here as a data subject and a joint controller (if they aren't exempt) because the crash report processes personal data for which they are the controller.
You premise is correct. The processor is someone that processes data on your behalf, and since the GDPR definition of processing is extremely broad, that is about every third party subcontractor that you use for data processing, including various cloud providers. I'm afraid it will soon become a huge mess with a gazillion contracts to sign. I disagree. Yes, the GDPR says that a contract between the controller and processor must exist, but Article 28 of the GDPR does not say anything about how the controller shall document these instructions. Basically, in cases like the one you describe where John Doe relies on a web agency for having a contact form on the web, there will be a standardized (by the web agency) service agreement between the John Doe (controller) and the web agency (processor). There is nothing stopping the parties from agreeing that this service agreement that John Doe accepted as part of the onboarding procedure is also the DPA as required by the GDPR. Putting something like the following in the service agreement would do it: The parties agree that this Service Agreement between You (controller) and Us (processor) set out Your complete and final instructions to Us in relation to the processing of Personal Data and that processing outside the scope of these instructions (if any) shall require prior written agreement between You and Us. You also agree that We may engage Sub-processors to process Personal Data on Your behalf. The Sub-processors currently engaged by Us and authorized by You are listed in Annex A. I think we will se a lot of amendments in service contracts as the GDPR gets better understood, but I don't really see a flood of DPAs in addition to these amended service contracts.
GDPR defines the responsibility of Companies to ensure that Personal Data in their possession is maintained Secure ensuring Confidentiality and Privacy towards the Data Subjects to whom it pertains. Prior to the Articles themselves, there are notes and over (49) one may read that companies must have in place (where applicable) mechanisms like CERT and any other SECURITY assuring tools/ processes. (83) again is all about ensuring Security. (94) reads that if the Controller (company) find it cannot ensure Security it must stop processing activities and report to the Supervisory Authority for guidance and support. Then we have Article 3 (f) establishing that it is the company responsibility to "... ensures appropriate security of the personal data, including protection against unauthorized or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organizational measures (‘integrity and confidentiality’)..." Bottom line... T&amp;C Companies must ensure that Personal Data is processed by them (and that includes communications) are Secure while ensuring Confidentiality and Pricavy towards the Data Subjects. The wording "...commercially reasonable efforts..." is wrong, because it is not something that may be a legal requirement or not depending on "cost"; it is a Legal Obligation. Then "... the Internet is not an inherently secure environment and so we cannot guarantee the security of your Personal Information..."; this is just "poor legal advice" for GDPR does expect companies to make the Internet safe, it expects companies to maintain their IT Landscape safe... an analogy can be made about going through a group of sharks in the ocean while just swimming or on board of a big boat... the ocean is dangerous due to the sharks, yet if you are in a big boat, you won't even notice them. Then the "cherry on top"; "... e assume no liability for any disclosure of data due to errors in transmission, unauthorized third-party access or other acts of third parties, or acts or omissions beyond our reasonable control..."; now i really do not know which lawyer has written this, but it basically reads something like: "the law obliges me to ensure you are safe... however I am not able to". Now, I have seen similar "statements", but I must confess it was like 2 or 3 years ago... most companies have corrected them over time and since they become aware that penalties were for real. Just a final disclaimer It is a fact that while in transit (over the Internet) a message being delivered through a T&amp;C Company Services will travel through 3rd party infrastructure contexts, rendering it at risk ... however, if it is properly encrypted (as it should) the transition time will not be sufficient for a successful breach attempt. So, yes they are capable of ensuring all they have stated they can not.
It is absolutely not the case that Providers are not allowed to keep PII without consent. Article 6 of the GDPR identifies six possible lawful bases for processing personal information. These are: (a) the data subject has given consent ... (b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; (c) processing is necessary for compliance with a legal obligation to which the controller is subject; (d) processing is necessary in order to protect the vital interests of the data subject or of another natural person; (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Point (f) of the first subparagraph shall not apply to processing carried out by public authorities in the performance of their tasks. If a person requests services from an online service provider, basis (b) will apply, at least to some information. If there is evidence of criminal activity, basis (c) may well apply, as it also will for much routine record keeping. Any in many such cases, basis (e) or (f) will also apply. In short, article 6 does not create a &quot;haven for online criminals/hackers&quot;. In a comment on another answer the OP writes: The offender has the right to not be identifiable and he can't be denied this right That is simply not correct. Nothing in the GDPR says anything of the sort. It is true that consent may not be forced, but if a user requests a service that service may require the user to identify him- or herself. For example, one cannot order physical goods without giving a name and a shipping address. And the provider may retain PI and even PII when it has a &quot;legitimate interest&quot; in doing so, although if challenged it must justify that legitimate interest.
GDPR gives you a lot of flexibility here to choose either DPA. From Art 77: Without prejudice to any other administrative or judicial remedy, every data subject shall have the right to lodge a complaint with a supervisory authority, in particular in the Member State of his or her habitual residence, place of work or place of the alleged infringement if the data subject considers that the processing of personal data relating to him or her infringes this Regulation. However, the DPA from the company's country would be designated the lead supervisory authority for this investigation. If multiple DPAs are involved, they would coordinate with each other. There is no EU body that you could contact directly. But if the different DPAs have a dispute regarding this investigation, the EDPB would provide a consistency mechanism. This mechanism has been used in the past e.g. to force the Irish DPA to correctly apply the GDPR against companies from the Meta group, like WhatsApp and Instagram. Though it might slow things down, it could be advantageous to have multiple DPAs involved, precisely so that the investigation is double-checked. If the lead supervisory authority declines the case, this would also enable the other DPA to do its own investigation. So, it would be a good idea to lodge a complaint with the DPA of your home country, and let it forward the issue to other DPAs as needed. However, contacting the DPA in the company's country would also be fine, especially if you are fluent in the relevant official language, and/or if you live in Ireland.