Is storing on EU-based servers sufficient to be GDPR-compliant with regard to the Schrems II arrest if they&#39;re controlled by a U.S. company? After the Schrems II decision, data transfers to US data processors are increasingly risky at best, for example to public cloud providers such as GCP, Azure, and AWS. A very common suggestion is to store your data in EU-based data centers of these cloud providers if your application isn't too latency-sensitive, for example in this answer. I fail to see how this makes a significant difference. All of the major public cloud providers are US companies, and their servers in Europe are still under their control, and so the US government can just as easily demand to hand over data hosted on EU servers as they can on US servers. In a strict sense of the word, data transfer to the US is indeed avoided, as the data physically remains on EU servers. But in a broader sense of the word, and really in the spirit of the Schrems II arrest and GDPR in general, the data is de facto transferred to a US controlled company the moment when it's stored on any GCP, Azure or AWS server, regardless of where that server is located. Thus, I feel as though hosting on EU-based servers of US-based public cloud providers doesn't solve anything at all, and simply provides a false sense of security and compliance. Is this correct, or am I missing something?
The tricky bit from a GDPR standpoint is that the US has a law that says a US-based company must hand over data to US government agencies even if the data is stored outside the US. This is US specific and a case where the US government gives itself jurisdiction outside the US but the EU can't directly do anything against it (outside of international negotiations). As you noticed this means if you store data at a US data processor there is no real difference whether the data is physically stored in the US or the EU. So to avoid transferring EU consumer data to the US several steps are needed. First the servers have to be physically located in the EU and second the company needs to be non-US based, EU based seems the obvious choice. AFAIK constructions of a US-based company creating a fully owned EU-based subsidary are currently used to achieve the second part. Whether this is sufficient may have to be decided in court.
As I understand it, the GDPR does not permit sending of personal information (which includes the IP address) without prior consent by the user. That's not exactly true, consent is merely one of six possible legal basis for processing (article 6). For example, processing of personal data can also be lawful if it necessary to perform a contract, legally mandatory, or in the public interest. The court decision acknowledges that but rules out another basis in this case because it considers that it is possible to serve fonts without relying on a third-party ([…] der Einsatz der Schriftarten auch möglich ist, ohne dass eine Verbindung von Besuchern zu externen Servern hergestellt werden muss). Confusingly, it only refers to article 6(1)(f) when it seems to me that (b) would also be plausible but maybe this wasn't raised during the proceedings? If the data controller cannot invoke any other basis for the lawfulness of the processing then yes, the only thing left is asking for consent, i.e. invoking article 6(1)(a). But that doesn't mean that you should expect to be asked for consent each and every time your personal information is being used. The consent form on the site also implicitly assumes consent, which I thought was also a violation. Yes, implying consent doesn't really make sense under the GDPR definition (article 4, see also article 7): ‘consent’ of the data subject means any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action European data protection authorities have issued guidelines that detail what that means and clearly reject “bundling” different data processing. The regulation also makes it clear that data subjects should be able to withdraw consent at any time, which does not seem possible with the fonts on golem.de My reading of all this is that assuming consent because you are using a service (or even created an account or checked a box at some point) simply isn't valid consent. Either you don't need consent at all in the first place or what you need is freely given, specific consent and “implying” consent or bundling it with a registration process achieves exactly nothing. But this is still extremely common and it might take some time before enforcement and case law definitively settle this question. Smart data controllers trying to avoid collecting consent (like Meta) have abandoned any claim that signing up to the their services would constitute consent (because that's transparently not the case) and try to bypass the issue entirely using another basis like contractual necessity. This is also being litigated. I know that a EU regulation can be implemented and interpreted differently from country to country, and that a single court ruling in Germany doesn't even mean that the national law was correctly applied. From what I've read, I get the impression that this particular ruling was not unlikely to be overturned by a higher instance, if it came down to it. So my question probably both pertains to German law specifically and the EU regulation itself. That sounds more like the way EU directives work. Regulations are supposed to be immediately applicable (no implementation in national law necessary) with minimal differences between countries (except when they explicitely provide for that). Of course, enforcement would still mostly be in the hands of national court systems and (in Germany) provincial data protection authorities but there are mechanisms to ensure consistency (the European Data Protection Board, prejudicial questions to the CJEU, infringement proceedings from the European Commission…).
I don't think you would be responsible for whether your software is used in a GDPR-compliant manner. For GDPR compliance, it is important who the data controller is. The data controller is whoever determines the purposes and means of a personal data processing activity, i.e. the why and how. The data controller alone is responsible for their GDPR compliance. When a data controller wants to run some software, it's the data controller's responsibility to ensure that this software is used in a GDPR-compliant manner (or possibly not at all). Determining purposes and means of processing When someone other than the developer runs a software, the question is who might be a controller: you as the developer, they as the operator, or neither, or both? The operator is clearly a controller: they determine a purpose for data processing (e.g. to manage staff) and have determined means to perform that processing (e.g. to use the software). The developer may or may not be a controller. Clearly, the developer has made choices about how the processing of personal data will be performed, i.e. has determined some means of processing. E.g. the developer has developed a particular architecture, chosen a way to store personal data, and has implemented some security measures. But determining some means is not sufficient to be a data controller, see discussion below. Has the developer participated in determining the purposes of processing? I think this will depend on the specific functionality provided by the software in question. If the software just does what it says and processes the data for the operator's purposes, everything should be fine. If the software also processes data for the developer's purposes, that developer might be a controller. For example, if analytics or crash reports are collected by the developer, that would be a clear indication that the developer would be a (joint) controller. So depending on specific factors, the operator might be the sole controller, or the operator and developer might be joint controllers. Essential vs non-essential means What about the developer determining some means? When does this make the developer a joint controller? The EDPB has created a theory of essential vs non-essential means: 40. As regards the determination of means, a distinction can be made between essential and non-essential means. “Essential means” are traditionally and inherently reserved to the controller. While non-essential means can also be determined by the processor, essential means are to be determined by the controller. “Essential means” are means that are closely linked to the purpose and the scope of the processing, such as the type of personal data which are processed (“which data shall be processed?”), the duration of the processing (“for how long shall they be processed?”), the categories of recipients (“who shall have access to them?”) and the categories of data subjects (“whose personal data are being processed?”). Together with the purpose of processing, the essential means are also closely linked to the question of whether the processing is lawful, necessary and proportionate. “Non-essential means” concern more practical aspects of implementation, such as the choice for a particular type of hard- or software or the detailed security measures which may be left to the processor to decide on. – EDPB guidelines 07/2020 on the concepts of controller and processor in the GDPR, added formatting for legibility Looking through that list of essential means, some might be determined by a software's developer, but I wouldn't expect this to be the case for this kind of open source software. types of personal data: the software certainly sets a framework for processing specific kinds of personal data, e.g. by providing database fields for names, contact details, and schedules. But ultimately, the developer does not control which data is actually collected and filled into those fields – the developer does not cause specific kinds of personal data to be processed with the system. duration of processing: unless the software is programmed with a fixed retention schedule, it should be impossible to argue that the developer has determined the duration of processing. Even then, it would also be the operator who has determined this duration to be appropriate, rather than editing the open-source software to change the duration. But typically, no such retention schedule is enforced, and retention would depend solely on the operator (who can use an admin interface or a database console to erase old records). categories of recipients: typically, the developer does not determine to whom the data in the system will be given. But if the system sends data to third parties by itself, this might change. For example, if the system is pre-configured to store data in an existing cloud database instance, or to a specific analytics server, the developer might be acting as a controller. Here, good software engineering and legal risk minimization coincide. Best practices for web apps state that account credentials and connection strings shouldn't be hardcoded or committed to a repository, and should instead be provided externally (e.g. via environment variables). categories of data subjects: this depends solely on how the software is used. The developer has no way to determine whose data the operator will enter into the system. If the developer isn't a controller, might they be a data processor instead? In a GDPR context, a data processor is whoever processes personal data on behalf of a controller. The developer is clearly not a processor in this scenario because both the “processing” and “on behalf” criteria fail. The developer has no access to the data in the operator's instance, so cannot process the personal data. There is no direct relationship between the developer and the operator. The operator has not delegated authority to the developer so that the developer would be acting “on behalf” of the operator. There is a legal relationship between the two roles (the developer has licensed the software to the operator) but that is entirely irrelevant in a data protection context. The GDPR isn't directly about cookies While the GDPR does cover how personal data can be processed with cookies, the famous “cookie law” is actually separate: those cookie consent requirements stem from EU member state's implementations of the ePrivacy directive. Instead of talking about “controllers”, ePrivacy has concepts such as the “provider of an information society service”. While this role fits perfectly to an operator/provider who runs a web app in a publicly accessible manner, it does not fit a developer who merely makes some source code available. Is the developer even subject to the GDPR? The GDPR can only apply to data controllers and processor who process personal data. As discussed above, the developer is probably not processing personal data at all. Even if the developer were processing personal data, it is questionable if GDPR would apply assuming the developer has no “establishment” in the EU (e.g. an office). Then, the question would be whether those processing activities are either related to offering goods or services to data subjects in Europe, or whether the processing activities involve monitoring the behavior of people who are physically in Europe. Unless the developer is actively targeting European businesses with marketing for this software, the answer is very likely “no”. Could the operator sue the developer for providing software that isn't GDPR-compliant? The operator can sue anyone for any reason, but is probably not going to win. As discussed, the operator is a data controller. They are responsible for ensuring that their purposes and means are GDPR-compliant. That involves selecting suitable software. The data controller would be neglecting their own responsibilities if they just download some random software and start feeding personal data into it. Things might be different if the operator specifically advertises GDPR compliance features but you're not going to do that. It's also worth noting that common open source licenses like the Apache License 2.0 include a warranty and liability disclaimer. To which degree they protect the developer ultimately depends on national laws, but they make it difficult for the operator to make a legal argument that they're entitled to a GDPR-compliant product. See also the related question: Do warranty disclaimers in software licenses carry any legal weight? What can you do? First, don't worry too much. Given how much bad software there is on the internet, surprisingly few developer get into legal trouble for writing source code that's buggy or missing some features. Second, consider choosing a license for your project that includes a reasonable warranty/liability disclaimer. Third, make the state of your project clear in your README file. If someone knows that this is alpha-quality software and that no compliance features were implemented, it's their own fault if they actually use that software.
[I'm not so well-versed on US and Russian law, thus I will limit my answer to EU law.] Your specific use of a user identifier, as I understood from your question, can be classified as personal data, so in your case, the GDPR seems to apply. This means that you need to have a) legitimate purposes to process that personal data (e.g. crash reporting) and b) a legal justification for each purpose of processing: it could be based on consent or another legitimate purpose (inc. your own legitimate interests). Consent might not be the best option for you, but it's up to you to decide. In any case, you need to assess the risks to the data subjects (your users) before you decide. How likely is it that you will get breached, and what potential harm will that cause to your users? These are some guidelines; my recommendation is that you read the law and the guidelines by the Article 29 Working Group and European Data Protection Board, or hire some good experts on this. There is no easy answer, or one size fits all solution. The GDPR isn't so hard to understand or implement, but it does require some change in mindset. With the new law, processing personal data carries a higher risk of penalties, so you should do it only when it's absolutely necessary, and with respect to the rights of your users.
The status of any PII (Personally Identifiable Information) is the same in GDPR regardless of location, or who enters it. Its goals are (among others) to stop any actor (company / government or other) from hiding responsibility about their use and practices around people's data. GDPR does even apply to anything offline and on paper. Basically it means you have to validate any entry field is free of PII before processing it. Or make it clear in your privacy statement how you handle this use-case.
If you operate from outside Germany but within the EU, it is generally sufficient to satisfy your own country's regulations. This is a foundational principle of the EU single market, though it's not quite realized yet and has exemptions for consumer protection purposes. However, the German TMG law which includes the Impressumspflicht explicitly enshrines this principle. So from the German Impressumspflicht perspective, you're good to go. However, you will not be able to operate anonymously, because of your country's laws. GDPR requires you to clearly state your identity and contact details in your privacy notice. If you engage in internet-based commerce, the EU eCommerce Directive will have caused your EU member state to pass legislation that requires you to disclose: your name the geographic address where you are established contact details incl an email address if applicable, registration numbers from trade registers or similar if applicable, your VAT ID Note that you must have a VAT ID for cross-border B2B sales within the EU. You state that you are not selling anything via your website, and are instead collecting payments via another website. What the consequences of this are would depend on the laws and caselaw in your jurisdiction, but you will have to make these disclosures on at least one of the two websites. About Germany going after bloggers who show ads: income from ads is taxable income, and operating a business requires registration. However, the German Impressumspflicht is rarely enforced by the state. Instead, other market participants (competitors) trawl the internet for potential violations and then send a cease-and-desist letter. They can do this because skirting legal obligations distorts the level playing field, which harms those competitors. There is a thriving cease-and-desist industry built around this, but it only affects businesses that operate within Germany.
You are responsible for any processing of data that happens under your control – but are you the data controller in this scenario? Since you have no meaningful influence over whether or not this backup happens on the operating system level, there could be a strong argument that you aren't a data controller for these backups. And if you aren't a data controller for that processing activity, you aren't responsible for compliance. However, if you were to integrate directly with relevant Google APIs in order to facilitate backups that could make you a controller. Then, Google would either have to be your data processor (won't be the case here), or you would need a legal basis for sharing the user's data with Google. For example, you could ask for the user's consent before activating such features.
GDPR &amp; EPD require user consent before storing a users personal information. Wrong. User consent is one of the ways that justify storing personal information, but there are others. You may check art.6 to see the several reasons that allow to store personal information. In this case, it seems reasonable to justify it under the paragraph f (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. Of course, that means that the data has to be used for this purpose. Avoiding spammers and other banned users would be such a purpose, but you should ensure that you do not send those e-mail address commercial information or even a Christmas greeting. In any case, be careful with anything you store. If along with the e-mail you stored more info, this could be interpreted as excessive and beyond the scope of paragraph f. For example, imagine storing &quot;User wrote nazi statements&quot; explaining why the e-mail is banned; EU laws are very restrictive about storing information about political or religious beliefs.