Essential cookies - legal responsibilities I'm using Stripe to process payments on my site The only cookies the site uses are set and processed entirely by Stripe The cookies would only apply to users who have 1) created an account, and 2) signed up for a paid subscription When signing up for an account, all users must accept the terms and conditions and privacy policy, which mentions the following: We may use cookies and other tracking technologies to collect and store your information. and under the Personal Information section: Payment Data. We may collect data necessary to process your payment if you make purchases, such as your payment instrument number (such as a credit card number), and the security code associated with your payment instrument. All payment data is store by Stripe. You may find their privacy notice link(s) here: https://stripe.com/privacy I've read in some answers like this one that the cookies are still my responsibility, since it's happening on my site, so I want to be sure I'm legally covered here in terms of GDPR and other cookie laws. This answer and others suggest that only non-essential cookies need to be announced with a banner and have the option to be turned off. My understanding is that for essential cookies, the legal requirement is to just disclose that cookies are used and for what purpose. So with all that in mind, my questions are: Do my Stripe cookies count as essential cookies? If the Stripe cookies count as essential, is it legal to provide no option to turn them off? Have I met my legal requirements in terms of disclosure? The terms and conditions and privacy policy were generated by Termly.
If the GDPR applies, then the e-privacy directive (EPD) (formally Directive 2002/58/EC of the European Parliament and of the Council of 12 July 2002) almost surely also applies. However, this being a directive rather than a regulation, the implement6ing laws may vary in different countries. The relevant provision is Article 5 paragraph (3) which reads: Member States shall ensure that the use of electronic communications networks to store information or to gain access to information stored in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned is provided with clear and comprehensive information in accordance with Directive 95/46/EC, inter alia [among others] about the purposes of the processing, and is offered the right to refuse such processing by the data controller. This shall not prevent any technical storage or access for the sole purpose of carrying out or facilitating the transmission of a communication over an electronic communications network, or as strictly necessary in order to provide an information society service explicitly requested by the subscriber or user. This governs cookies and any other local data, that is, data stored on or read from the user's equipment. What this means is: A site operator must disclose, in detail, what cookies or other local data the site stores on or reads from the user's device. Even strictly required data (cookies) must be disclosed. A site may not store or read any local data until after consent has been obtained. The user must have the option to consent to or refuse consent to individual data items separately. Giving consent may not be a condition of permission to use the site. Consent must be opt-in, not opt-out, that is the default must be &quot;No consent&quot;. Local data (including cookies) that is &quot;strictly necessary&quot; for the operation of the site is exempt from the requirement of consent, but not from the requirement of disclosure, and that means specific disclosure. It must be at least as easy to cancel consent later as it was to give consent initially. Do my Stripe cookies count as essential cookies? If the Stripe cookies count as essential, is it legal to provide no option to turn them off? Have I met my legal requirements in terms of disclosure? The terms and conditions and privacy policy were generated by Termly. I don't know stripe well enough to be sure, but they might. What do they do that is essential for operating the site? Yes. No, not if the disclosures in the question are the only ones you make. As I understand it, you must provide at least a link to a page that shows each specific cookie that you read or set, and what data is stored in that cookie, even for strictly required cookies. Update: I should mention t6hat although the above describes my understanding of the current legal requirements, I have read that enforcement of those requirements does not seem to be a priority for the relevant authorities at this time. Other aspects of data protection, such as proper security to avoid data breaches, and having a proper legal basis for processing, and other GDPR requirements, as opposed to e-Privacy requirements, seem to get more attention and resources from the relevant authorities. Having read the comment by the OP, it does seem that at least some of the stripe cookies are strictly required and need not have consent. The stripe cookie policy linked to is better than many sites currently offer. It does not go into fully specific detail, but it may be that the dashboard does, and that together the two are fully compliant. Linking to this policy (and if possible directly to the stripe cookie dashboard) would seem to me to cover most of the issues here.
Think of a website that has gives no option for the users to delete what they have posted -but still the users can delete their account completely. That's easy - this is exactly how all StackExchange sites (including this one) work :-). See for example: How does deleting work? on meta.SE. Is it against the right to erasure mentioned here as a part of GDPR? No, it is not (otherwise StackExchange would be in rather big trouble). The "right to be forgotten" is subject to limitations. Most importantly, it only applies to personal data. Personal data is defined as (GDPR, art.4): any information relating to an identified or identifiable natural person (‘data subject’) If what you posted contains no personal information about you, it is not "relating to" you. The details are complicated (as usual, see e.g. The GDPR: What exactly is personal data?), but "personal data" is things about you (your name, your address, your sexual history, maybe even your IP address). On the other hand, if someone asks how to solve a programming problem, and you write an answer explaining what API to call, that answer is not personal data. In addition to that, even personal data may be retained if the data controller has a need to retain that information. This is also covered in article 4. For example, the controller may retain information "for the establishment, exercise or defence of legal claims" - otherwise you could buy something online without paying, and then ask the seller to forget about your purchases so they cannot collect the outstanding payment. So, in summary: A website will need to allow users to delete or hide personal data that they posted - such as their user profile information, or personal information in their posts. That does not mean they are allowed to delete entire posts - it is enough if personal information is redacted or anonymized. The website may be allowed to retain that information (hidden) if they can show legitimate interest - for example billing information, or posts that are the subject of a lawsuit. The StackExchange network, for example, covers this by allowing users to: disassociate posts from their account delete their account entirely (thus effectively disassociating all posts from personal information) asking a moderator for redaction of personal data
You are responsible for what data is being processed by your website. When you embed third party components on your website (e.g. iframes, scripts), you are at least jointly responsible with the third party providing these components. You are only responsible for what happens on the website (i.e. what processing is under your control), not for what the third party provider does with collected data on their services. However, note that information will be transferred to Google's servers regardless of whether the visitor has a Google account! The Fashion ID case is relevant case law establishing and explaining these points. Since you are (jointly) responsible, you need a legal basis for collecting personal data through the tracking snippet and sharing it with the third party (here Google). For example, the legal basis could be a legitimate interest, or could be consent. A legitimate interest requires that you balance this interests against the interests, rights, and freedoms of the data subject (the site visitor). If the data subject wouldn't reasonably expect this tracking, you cannot rely on a legitimate interest. Consent can always work, except that it is a freely given, informed opt-in – likely unsuitable for conversion tracking. Which legal basis to use is primarily your responsibility. You argue that the tracking snippet does not collect personal data. However, this argument is not well supported. Under the GDPR, personal data does not only include directly identifying information such as an email address, but also any information “relating” to an identifiable person. Identification includes the ability to single out someone, e.g. by a browser fingerprint. For purposes of conversion tracking, Google will clearly try to collect data that allows the visitor to be singled out, thus collecting personal data. Furthermore, specific kinds of information are regulated by the ePrivacy directive. This includes “traffic data” and “information stored on a terminal device”, regardless of whether this information is personal data under the GDPR. Under ePrivacy, such information can only be used as strictly necessary to provide the service requested by the user (and conversion tracking is not strictly necessary), or when the user gives their consent. Depending on what information is collected by the tracking snippet and on whether you are subject to ePrivacy, you would have to collect consent anyway. There is also the issue that Google Ads is an US-based service, and transferring data to the US is largely illegal since the 2020 Schrems II ruling. The US do not provide an adequate level of data protection, so that transfers would require additional safeguards. Standard Contractual Clauses (SCCs) for Controller to Controller transfers are not sufficient by itself. Of course those extra safeguards are effectively impossible to implement and no one is doing this correctly, but it's worth considering that there is additional legal risk. Explicit consent can provide a legal basis for transfers even to a country with inadequate protections, but that mechanism is intended for occasional transfers. In conclusion: you have wrongly concluded that no personal data would be involved you are jointly responsible with Google for whatever data is processed by the conversion tracking snippet you need a legal basis for sharing this data with Google legitimate interest may be sufficient, depending on what data is involved (consider ePrivacy) and depending on the result of your legitimate interest balancing test alternatively, you may require every visitors consent to track their conversions – unlikely to result in good data additionally, such use of Google Ads may run into issues around international transfers due to the Schrems II ruling this kind of stuff is difficult, and no one is really doing this correctly :/
Belgium enacted an implementing law, the Act of 30th July 2018 on the protection of natural persons with regard to the processing of personal data. This, along with the GDPR, are the key legislative references that relate to your question. On 5th September 2017 the ECHR judged that it "considers that States should ensure that, when an employer takes measures to monitor employees' communications, these measures are accompanied by adequate and sufficient safeguards against abuse". This case set a precedent relevant to employee monitoring in Belgium. This is most definitely a data protection or privacy law matter and the DPO should be consulted. If they have to do research, that shouldn't be your concern as that is their job. The company must support the DPO in what they need to do that job, as such is literally written into the GDPR. Furthermore, in this case it would, by my evaluation, be necessary to conduct a Data Protection Impact Assessment (DPIA) for the monitoring activity, and if one has been done, it should document the recommendations and requirements or what is already in place. You as an individual may also ask a question of the Data Protection Authority: (NL) https://www.gegevensbeschermingsautoriteit.be/verzoek-klacht-indienen (FR) https://www.autoriteprotectiondonnees.be/introduire-une-requete-une-plainte You might ask them about your position and liability as an employee, but I would be more concerned, if I were you, with verifying that your actions are above board rather than trying to cover your ass just in case they aren't. Do the right thing, even if that means questioning the direction you've been given. AD logons still identify the person logging on, and may include source IP, which is specifically listed in the GDPR as within the scope of 'personal data'. So while there may be a legitimate need to process such data, it needs to be gone about in the right way. Actions taken by an employee are taken by the organisation in terms of processing personal data, so whatever you are asked or ordered to do, will be done by the company. If you are being offered no legal justification for doing so, you might document the direction you are given and question it respectfully, pointing out that if found to be unlawful, it is the company that would be in trouble, all while knowing that should there be for example an unfair dismissal, you have a record of who asked you to do what, how you challenged or questioned it, and what was the outcome.
If a data controller fails to fulfil your data subject rights, lodge a complaint with your data protection authority. In Hamburg, the appropriate form is here. However, they are not required to investigate your complaint. Independently from a complaint, you could consider suing Wordpress for compliance – Automattic has a subsidiary in Ireland so this might actually be feasible. I'm not quite sure though that Automattic is indeed the data controller for wordpress.org, as opposed to the .com domain – the privacy policy isn't quite GDPR compliant. While your GDPR Art 17 Right to Erasure might not apply in this case, there's a definite GDPR violation because the data controller failed to respond to your request within a month as per Art 12(4). That your posts on the bugtracker were deleted doesn't look like an issue in this context, what does matter is that they didn't respond to emails to the addresses mentioned in their privacy policy. Whether you have a right to erasure depends on the legal basis for storing your data. In general, you have a right to erasure if: the data is no longer necessary; processing is based on consent (because you can always withdraw consent); or processing is based on a legitimate interest and they have no overriding legitimate grounds to continue processing despite your objection (Art 21). The data is still necessary to identify you for your actions on the bugtracker, but depending on your particular situation you may be able to object successfully and force them to anonymize your posts.
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.
Your analysis so far seems correct. You must comply with all applicable laws. The GDPR's Art 6(1)(c) legal basis clarifies that having to provide personal data is no excuse: that legal obligation is all the legal basis you need for sharing the personal data in accordance with your obligations. However, that legal basis doesn't generally excuse you from your other data controller obligations. For example, you should still inform the data subjects about the processing as per Art 13(3).
No, you do not need to show a privacy policy just for running a publicly accessible server, as long as any traffic data such as IP addresses is only used as strictly necessary for providing the service requested by the user. The background here is that while GDPR is a very general law, the ePrivacy directive (ePD) provides more details for telecommunication and information society services, which also includes SSH servers. Per ePD Art 6, traffic data may be used (1) for the purpose of the transmission/service or when the data has been anonymized, (2) for billing purposes, or (3) for marketing or value added services, when the user has given their consent. Information about the processing is only required under ePrivacy for cases (2) and (3), but not for processing that is strictly necessary. Now the tricky question is under what circumstances you can log (failed) log-in attempts or use tools like fail2ban. One argument is that such measures are strictly necessary to ensure the security of the communication, but these measures are evidently not necessary for performing the transmission in the sense of ePD. There are a few ways to resolve this: necessity has to be interpreted more broadly, and security measures are indeed necessary. For example, ePD Art 6(5) mentions fraud detection, without authorizing it explicitly. an IP address is effectively anonymized in the sense of the ePD since you do not realistically have means for linking the IP address to any particular person. This is a fairly weak argument, but could be supported by GDPR Recital 26 which defines anonymous data. Counterpoint: IP addresses are online identifiers which are explicitly included in the definition of personal data in GDPR Art 4(1). an IP address is not just traffic data that falls under the ePD, but also personal data that falls under the GDPR. When the IP address is merely used to make a transmission, it is not processed as personal data and only ePD concerns apply. But when we process it to ban the IP, it is processed as personal data under a legitimate interest. This processing does not fall under any of the categories from ePD Art 6, so that only GDPR concerns apply. These include a requirement to inform the data subject about the processing at the time in accordance with GDPR Art 13, which could be satisfied by displaying a link to a privacy policy in the course of the login process. For a legitimate interest argument, it also depends on the expectations of the typical data subject. Since some security measures such as security logs are normal and should be expected, a legitimate interest argument is likely to be strong. I think this is the correct conclusion, even though the “it's not traffic data, or at least doesn't fall under the ePD” argument is quite weak. It hinges on the assumption that security measures are not “value added services”. This fits the intent of the ePD, but not the actual definition of value added services. In any case, you do not need to ask for consent unless you're required to obtain consent e.g. under ePD Art 6(3) or because your processing of personal data relies on consent as the legal basis per GDPR Art 6. It also has to be noted that ePD has no immediate effect, but has to be implemented by each EU member state in national law. These laws can provide more specific guidance.