Is MailChimp compliant with GDPR? In light of recent news of Facebook not being compliant with GDPR because it processes data in USA and not in europe, would a website using MailChimp for newsletter be GDPR compliant since it is based in USA and holds the data there? Their website claims that they are compliant with GDPR, but just looking at their cookie notice that has the full cookies preselected (and the selection is hidden) shows that isn't completely correct. But their website not being completely correct doesn't mean their service isn't, that's why I'm asking the question
Mailchimp as a company is probably mostly GDPR-compliant. But this doesn't mean that using the Mailchimp service would be compliant as well. This is because the GDPR has different compliance obligations for “data controllers” and “data processors”. The data controller is responsible for the compliance of all processing activities they determine the purposes and means for, regardless of whether those activities are actually outsourced. In contrast, the primary responsibility of a data processor is to only use the data as instructed by the controller, but not for the processor's own purposes. So Mailchimp probably doesn't abuse its customer's data, and offers an Art 28 GDPR conformant data processing agreement as part of its contracts. Mailchimp also offers features that assist with related privacy laws, such as collecting proper consent as required by the EU ePrivacy Directive. And Mailchimp has a page about European data transfers. This is where it gets tricky. Not the Mailchimp service, but the customer is the data exporter / data controller and is responsible for compliance with Chapter V of the GDPR. The data controller must decide themselves whether the international transfer into the US is legal. Briefly, the GDPR allows the following grounds for an international transfer of personal data: target country has an adequacy decision from the EU – no, because the EU–US Privacy Shield was invalidated in the Schrems II ruling Standard Contractual Clauses (SCCs) – maybe, see below discussion Binding Corporate Rules – not applicable exceptions, including explicit consent or only occasional transfers – not applicable The Mailchimp guide about EU data transfers correctly states that the Schrems II decision only invalidated the Privacy Shield, and did not invalidate the concept of SCCs. That means it is still legal to use SCCs as a basis to transfer personal data in non-EU countries. But this doesn't imply that SCCs can serve as a basis for transferring personal data specifically to Mailchimp in the US – a case by case analysis is necessary that determines whether security of processing is guaranteed and whether data subjects would have effective legal remedies if their rights were breached. It now happens that exactly the same reasons that caused the Privacy Shield to be invalid must also make us doubt whether SCCs can be valid in their place. The problem with transfers to the US never was the risk that the recipient would sell the personal data to the highest bidder, but that the US-based company is subject to US spy laws like FISA 702 and EO 12333 that do not provide effective legal remedies for foreign affected persons. (Mailchimp explicitly confirms that it is subject to those spy laws as an “electronic communication service”.) In the wake of the Schrems II ruling the EDPB has published a document with recommendations for supplemental safeguards that could make SCCs permissible, but these recommendations (like end to end encryption, or only transferring pseudoymized data) cannot work for US-based cloud services such as Mailchimp. Some (such as the US government) have argued that Schrems II was based on outdated information, but this standpoint is not shared by European regulators. So, the data controller – the Mailchimp customer – has to make their own judgement about this international transfer. If SCCs combined with Mailchimp's supplemental measures provide sufficient safeguards, then the international transfer is legal and GDPR-compliant. Mailchimp offers all the necessary paperwork such as DPAs, SCCs, and so on. If there are no sufficient safeguards, then the transfer is clearly illegal. My personal opinion is that Mailchimp's supplemental measure fall far short of what would be required per the EDPB recommendations. Lower courts in the EU now routinely consider all transfers to the US as illegal. A company using Mailchimp was also an early target of a post-Schrems II enforcement action, though it wasn't fined since it immediately stopped using the service. So while it's not possible to definitely say that using Mailchimp would be a GDPR-violation, it's very difficult to argue that such use could be compliant.
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.
The CEO wants to "fool" users You are essentially admitting that the company you are working for is about to deceit its customers and asking whether that is legal. The relevant set of laws is rather sparse and does not give direct answers in regards to oAuth tokens or other details of that level (which is probably making your CEO think he can "handle" the arising questions). Probably the most relevant bit of legislation that applies here is The Federal Trade Commission Act (15 U.S.C. §§41-58) which prohibits unfair or deceptive practices and has been applied to online privacy and data security policies. I am pretty sure that, in practice, if the users take your company to court, it will be held liable because: users are allowing us to read their CRM data and once we get the data, the data become ours, and we can do whatever we want with it. Is this true? While the users are still allowing you to read their data it is completely up to the Terms/EULA what you can do with it. However, once you have made the users think that they have withdrawn your access (e.g. they "deleted" oAuth tokens), you are no longer authorized to read the current data (although the Terms may still allow you to use the old data you obtained when you had access). Silently continuing to access their data without their knowledge/approval is definitely a deceit. The CEO wants us to download all of their emails and store them in our database There would be nothing wrong with that if it was in the Terms. But if it is not, that would be a blatant (and easily punishable) breach of privacy. Note that you may also be held personally liable for this wrongdoing (if/when proved so). "Just doing your job" claim will not work.
It seems like some law must have been breached during the sharing of this information? Possibly, even probably. The scrutiny of your personal account in order to glean personal data (your IP address) and then using that personal data to match accounts may contravene Recital 50 of the GDPR: The processing of personal data for purposes other than those for which the personal data were initially collected should be allowed only where the processing is compatible with the purposes for which the personal data were initially collected. If the website terms which you agreed to don't include this data matching, then that processing is not lawful. The rest of Recital 50 is relevant and worth quoting in full: If the 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, Union or Member State law may determine and specify the tasks and purposes for which the further processing should be regarded as compatible and lawful. Further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes should be considered to be compatible lawful processing operations. The legal basis provided by Union or Member State law for the processing of personal data may also provide a legal basis for further processing. In order to ascertain whether a purpose of further processing is compatible with the purpose for which the personal data are initially collected, the controller, after having met all the requirements for the lawfulness of the original processing, should take into account, inter alia: any link between those purposes and the purposes of the intended further processing; the context in which the personal data have been collected, in particular the reasonable expectations of data subjects based on their relationship with the controller as to their further use; the nature of the personal data; the consequences of the intended further processing for data subjects; and the existence of appropriate safeguards in both the original and intended further processing operations. It seems to me that an anonymous account could reasonably expect that the &quot;further processing&quot; of data matching is not in the public interest, an exercise of official authority, scientific or historical research or statistical. There is no link between the data matching exercise and the purpose for which IP addresses are normally collected: the operation and physical security of the website. Now, it may well be that the website terms do allow this data matching to discover links between accounts, or in any case prohibit having two accounts and allow reasonable methods to discover such links. It's also possible that a court has ordered the processing (as Iñaki Viggers has mentioned. We don't have that information; but ostensibly one wouldn't normally expect a personal account to be examined in this way, and certainly wouldn't expect any link discovered to be relayed to a third party.
The GDPR does not have specific rules on passwords. Instead, the GDPR imposes a more general requirement to ensure data protection by implementing “appropriate” technical and organizational measures, “[t]aking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons” (c.f. Art 24, 25, 32 GDPR). As of 2021, the state of the art for password storage is a special password hashing function such as Argon2, bcrypt, or scrypt. However, the nature and context of processing could reasonably lead to the conclusion that the usual hashed password storage is not appropriate, for example because the ability to find links between user accounts is more important. There is a trade-off between different aspects of security, and the data controller could reasonably arrive at an unusual conclusion. However: The data controller would still have to implement appropriate measures to protect these plaintext passwords, for example by storing them in an encrypted manner, keeping unforgeable access logs, and limiting access to plaintext passwords to specially trained staff. Encryption is one of the few things that are explicitly required whenever appropriate. The data controller better have a good analysis that shows that this unusual approach to security is appropriate. Even if not explicitly required, an Art 35 data protection impact assessment could be useful. The data controller has the burden of proof to show that these processing activities are GDPR-compliant. So is this data controller breaking the law or doing morally dubious stuff? Not necessarily! It is possible to find a scenario where they are doing the right thing. However, such a scenario is far-fetched and rather unlikely. Without further background, the most likely explanation is that the presented password handling scheme does not comply with GDPR.
Yes, their waiver has no legal basis and is invalid under the GDPR. They should have hired a better lawyer. GDPR rights cannot be waived (mrllp.com). The last bit should have been: Therefore, in consideration of my participation in any project, I understand that retaining my name and email address, as described above, does not require my consent and that the right of erasure, as spelled out in the GDRP Article 17 (1) b does not apply. The legal basis for our lawful processing of this personal data is Article 6 (1) f ("processing is necessary for the purposes of the legitimate interests pursued by the controller"). I.e. there is nothing in the GDPR that compels GitLab to erase this information, but their waiver is bogus. Keeping track of individual contributions in a software projects is necessary for a number of reasons, including security (if somebody contributes code that jeopardizes security, you want to audit everything that person has contributed).
The European Convention on Human Rights has an article about privacy (article 8). Note that this is from the Council of Europe, which is not the same as the European Union: non-EU member states such as Russia, Turkey, and Azerbaijan are also part of the Council of Europe and therefore the ECHR. I'm not sure if you first have to go to a lower court, but the European Court of Human Rights is the authority on this (commonly mistaken for the European Court of Justice, but they are distinct entities). According to this ruling of the ECtHR, it is not illegal to monitor your employees' communications per se. However, the monitoring has to be: for legitimate purposes ("the employer had only accessed the account in the sincere belief that it contained only messages of a professional, not personal, nature"), proportionate ("it was the only possible way available"), and communicated to the employee (or, if the monitoring is not announced, at least the restriction on personal use should be communicated, for example through company policy). In the European Union, there is also the GDPR, but this does not change much. It applies to your employer the same as any other organisation and basically says that they have to be reasonable about it: collect only what they need, for a legitimate purpose, and tell you about it. I think you should be able to request a copy of any data they collected about you, ask a human to review an automated decision, and your other usual rights. They don't need your consent to start collecting data, as Esa Jokinen already commented: "GDPR doesn't even require consent to handle PII data, but the consent is just the last option when there's no other legitimate reason to process the data." In fact, your employer probably cannot ask you for consent: because of the employer–employee imbalance of power, the consent would probably not be considered to be freely given (where this article mentions "The GDPR states", I think they are referring to recital 43).
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.