How does SE&#39;s arbitration clause hold up under the GDPR? Today the new Terms of Service of Stack Exchange have been released, sparking a lot of unrest about its arbitration clause; see the comments and answers on the linked meta above, and also this question. Does the GDPR prevent Stack Exchange from using the arbitration clause against EU citizens? In the sense that when there's a massive data leak and a large class-action suit will be filed, can EU citizens do that collectively, as opposed to going through arbitration for each separate user? The below is no longer applicable, since on the 10th of May electronic opt-out was made available. Related to this it states that the opt-out currently is a physical letter send to Stack Exchange (how they'd tie that letter to my SO account is a bit vague for me, as I can type any odd user page on my letter, not only my own), but this comment suggests that under GDPR there should be a digital opt-out for digital services. Does that mean that the entire clause is invalid (or however that goes in law), when there is no digital opt-out currently available?
Not going to hold up. Dutch Supreme Court confirmed 2012-09-21 in LJN BW6135 that arbitration is still covered by the the right to an independent judge, as established in Golder v UK, ECHR 1975-02-21, nr. 4451/70. Stack Exchange can't decide the rules themselves. (The Dutch case confirms that sector-wide arbitration is in fact legal, with regard to a standard arbitration clause commonly used in the Dutch building sector. The arbiter was found to be independent in that case precisely because they weren't picked by the builder involved.) The GDPR is only indirectly relevant, but the fact that it's mentioned does mean that there is an indisputable intent to provide services to EU consumers. (See section 23 of the GDPR, or its national equivalents). As such, you can't hide behind a US business address. If you intend to do business in the EU, it's under EU laws - all of them. You can't say that only the GDPR applies, and not other rules. I'm having a bit of a problem finding a source, but I'm fairly confident that consumers have the right to sue at their own, local court, overruling the default of suing in the court where the counterparty is located. Finally, I have the right under national law (Dutch: BW 6:236 start and sub-n) to strike the arbitration clause up to 30 days after the conflict arises, and demand a court decision. That's not 30 days after I accept the "Public Network Terms", that's 30 days after the arbitration is invoked. Dutch law explicitly allows arbitration abroad, and arbiters may apply foreign law, but as written the arbitration clause has no legal basis in the Netherlands, and any arbitration resolution would therefore not be considered valid. You may wonder if it matters to Stack Exchange that the arbitration decision would not hold in the EU. Well, consider a clause like Indemnification, which demands the user indemnifies Stack Exchange. That's a pretty empty demand if it's not enforceable.
The material scope of the GDPR (Article 2) is limited to the processing of personal data (including mere storage) by automated means or as part of a filing system. The question of whether your activity falls within this scope hinges on what you actually do with the data once you take possession of it. You have mentioned saving the contact information of people you have met at conferences, which could refer to simply retaining it for later use, or to the technological process of storing data in a computer. The former, if not done in any structured way (a filing system) would not fall within the scope of the GDPR. The latter, even if poorly executed, such as a photo stored on a business smartphone or a text document thrown onto your workstation's desktop, would always fall within scope as computerised data is processed &quot;by automated means&quot;. When the contact information you receive identifies a specific person, as distinct from just a corporate switchboard number and company name for example, it is personal data. When you get that personal data from the person it identifies (data subject), and you're otherwise in scope, Article 13 is invoked, requiring you to provide a list of information, &quot;at the time when personal data are obtained&quot;, unless &quot;the data subject already has the information.&quot; This is known as the right to be informed. The requirements differ when personal data are not obtained directly from the data subject. I would argue it is unreasonable to be expected to provide the information to the data subject over a cup of coffee or in a quick business card exchange, but if you start entering it into a spreadsheet or your CRM, you need to provide the required information, which may be as simple as a follow-up email thanking them for their time and letting them know you'll keep their contact details on file, along with a link to your organisation's privacy policy, assuming it covers this use, or if not, a specific privacy notice. You will of course be required to comply with other requirements such as the principles of data minimisation and identify a lawful basis, maintain adequate security by implementing technical and organisational measures, hold contracts with any third parties who process personal data on your behalf, and have a process for upholding data subject rights and responding to requests to exercise them - among others - but you should already be doing that for your other processing activities unless exempt. Additional information Edits have been made as clarifications and questions were forthcoming. Email marketing You need to consider the applicable country's implementation of Directive 2002/58/EC as amended (&quot;ePrivacy Directive&quot;). For example, in the UK you could send such messages without consent to contacts at incorporated companies or public sector bodies, but would have required consent for sole traders, private individuals, or partners in an unincorporated partnership. In Ireland, you have an exemption to consent for existing customers who were offered the opportunity to opt out when their email address was collected, but must use the email address for marketing within 12 months. Each EU country will have a different implementation of the Directive. In the Netherlands, Article 17 of the Telecommunications Act implements Directive 2003/58/EC and thus provisions for direct marketing by email. Processing by automated means Processing by automated means refers to processing of personal data in electronic, rather than manual form. All electronic processing is within the material scope of the GDPR, while only manual processing that forms or is intended to form part of a filing system is. Recital 15: The protection of natural persons should apply to the processing of personal data by automated means, as well as to manual processing, if the personal data are contained or are intended to be contained in a filing system. Art. 4(2): ‘processing’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means ICO guidance What is personal data?: The GDPR covers the processing of personal data in two ways: personal data processed wholly or partly by automated means (that is, information in electronic form); and personal data processed in a non-automated manner which forms part of, or is intended to form part of, a ‘filing system’ (that is, manual information in a filing system).
EU Member State Data Protection Authorities (&quot;DPAs&quot;) have fined foreign legal entities (pursuant to Articles 58(2)(i) and 83 GDPR and further national provisions), however it is not publicly documented whether the specific situation you described has occured. Even if such situation would arise, I would think that it is unlikely that DPAs imposing administrative fines could enforce their (fine imposing) decisions outside the EU, even if the decision in question was confirmed by a court. For instance, in the Netherlands there is not a strong legal basis for the (mutual) recognition and enforcement of foreign administrative decisions. I could imagine that the same applies to other EU Member States. However, please note (possible) civil liability Your question seems to refer to enforcement of the GDPR under instruments of administrative / public law. Please note however that the GDPR can also be enforced by private individuals and organizations, e.g. through tortious liability claims. See for example Amsterdam District Court 2 september 2019, ECLI:NL:RBAMS:2019:6490 for a situation (albeit purely national), in which the Court awarded damages for a GDPR breach to a data subject. Possibly, a similar case could be brought against an entity outside the EU that processes data of EU data subjects, contingent upon the outcome of certain questions of International Private Law. With regard to civil damages, there is an extensive international legal framework that covers the cross-border enforcement of rewards for civil damages. Likely, such rewards for damages could more easily be enforced outside the EU. However, I must note that such (private) cross-border enforcement of the GDPR has not happened in practice (yet) either (as far as I know). (Please note that this answer assumes (per the question) that the GDPR is applicable and only deals with the question of the territorial aspects of subsequent enforcement. See about the territorial scope of the GDPR: What is the legal mechanism by which the GDPR might apply to a business with no presence in the EU?).
In my opinion, this should be enough. The GDPR regulation is general - it does not attempt to address these issues directly, precisely for the reasons we see here: You can never predict how the technology will develop. When interpreting the GDPR, we must keep the intended goal in mind. What is the purpose of the "right to erasure"? To prevent anyone from further processing the personal data. If you "crypto-shred" it, it can't be processed anymore, not even theoretically. The encryptec file cannot be used to identify the subject, therefore it is not even personal data anymore. In case it can be decrypted in the future... Well, that is just a speculation. The courts can go to great lengths in interpreting what personal data is (dynamic IP address is considered personal data, since it can be linked to a person by the police with a court order), but i am pretty sure that "it can be theoretically possible in some distant future" is beyond the limit. As for the second question, I am not aware of any applicable case-law, but I guess that current security and technological standards will be used to assess the delay. You have a right to protect your data, the subject has a right to erase them. Those rights must be balanced, neither fully overrules the other. The delay should be short enough so the right to erasure is effective, and it should not extremely long compared to other (economically viable) backup solutions available, in line with current industrial standards.
Not Allowed Under the GDPR The suggested method does not seem to comply with the GDPR, and would not be lawful for a Data Controller that is subject to the GDPR. Specific Provisions Let's consider some specific provisions of the GDPR: Article 4 Article 4 paragraph (11) states: &quot;consent&quot; 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, signifies agreement to the processing of personal data relating to him or her; If the choice is &quot;obscure&quot; then it is not clear, and legal consent has not been given. Article 7 Article 7 paragraph 3 reads: The data subject shall have the right to withdraw his or her consent at any time. The withdrawal of consent shall not affect the lawfulness of processing based on consent before its withdrawal. Prior to giving consent, the data subject shall be informed thereof. It shall be as easy to withdraw as to give consent. It does not appear in the situation described that the data subject has been clearly informed that consent is being given. Recital 42 Recital 42 reads in relevant part: In accordance with Council Directive 93/13/EEC a declaration of consent pre-formulated by the controller should be provided in an intelligible and easily accessible form, using clear and plain language and it should not contain unfair terms. ... Consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse or withdraw consent without detriment. The specified means do not seem to comply with R42 Recital 32 Recital 32 reads: Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject’s agreement to the processing of personal data relating to him or her, such as by a written statement, including by electronic means, or an oral statement. This could include ticking a box when visiting an internet website, choosing technical settings for information society services or another statement or conduct which clearly indicates in this context the data subject’s acceptance of the proposed processing of his or her personal data. Silence, pre-ticked boxes or inactivity should not therefore constitute consent. ... If the data subject’s consent is to be given following a request by electronic means, the request must be clear, concise and not unnecessarily disruptive to the use of the service for which it is provided. The format in the question seems to rely on inactivity as a way of giving consent, and is surely not clear.
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.
This is all outlined at Terms of Service - Stack Exchange When you ask a question, and/or comment on or answer a question, or otherwise participate on an SE site, you license your content to SE. You agree that all Subscriber Content that You contribute to the Network is perpetually and irrevocably licensed to Stack Exchange under the Creative Commons Attribution Share Alike license. In turn, (emphasis mine) Subscriber acknowledges that Stack Exchange has no control over, and no duty to take any action regarding: which users gains access to the Network; which Content Subscriber accesses via the Network; what effects the Content may have on Subscriber; how Subscriber may interpret or use the Content; or what actions Subscriber may take as a result of having been exposed to the Content. Much of the Content of the Network is provided by and is the responsibility of the user or subscriber who posted the Content. Stack Exchange does not monitor the Content of the Network and takes no responsibility for such Content. Subscriber releases Stack Exchange from all liability for Subscriber having acquired or not acquired Content through the Network. ... This doesn't mean someone can't sue you anyway, notwithstanding that disclaimer. Anyone can sue anyone in civil court. That's the way the system works. Someone could track you down and sue you for the (bad) advice you gave that cooked their Macbook, even though they got that advice on SE and SE states that SE is not responsible for any damages resulting from the use of the information. The TOS of all SE site(s) shows that anyone who uses SE sites is bound by this click-through agreement, even if they didn't read it. And that should suffice in a court if it gets that far. It should suffice for any attorney thinking of taking the case of someone who wants to sue you. Again, someone could sue you; but chances are really great that it will never go very far due to the legal nature of SE and your contributions. This SE site - Law SE - has more of a specialized TOS, as practicing law without a license is illegal, and giving legal information as a layperson (or even as an attorney, of which there are some who particpiate here) needs special terms; see the sidebar for this disclaimer and link: Law Stack Exchange is for educational purposes only and is not a substitute for individualized advice from a qualified legal practitioner. Communications on Law Stack Exchange are not privileged communications and do not create an attorney-client relationship. General Disclaimer - Law Stack Exchange So, if you do get sued by someone who cooked their Macbook by following your bad advice, you can ask about the lawsuit here on Law SE. But, unless your question is about general legal procedures, terms, case law, etc. (as outlined at What topics can I ask about here? - Law SE), your question will be closed because this site is not for giving specific legal advice in specific legal situations, especially active lawsuits. You will be advised to talk to an attorney.
I'd rather not, but this might be compliant if you make sure that the personal data under your responsibility remains secure and protected even if it is processed abroad. Since the UK has left the EU, it is sometimes necessary to distinguish between implications of the EU GDPR and the UK GDPR. These are functionally equivalent, but in the matter of international data transfers the practical details have diverged. In my answer that you cited, I argued that any website processes personal data, and is thus potentially in-scope for the GDPR. If you cause another organization to process this personal data outside of the UK, you are performing an international data transfer (called “restricted transfer” in UK guidance). For example, such non-UK processing occurs if you use cloud services that run outside of the UK. The UK ICO has guidance on international data transfers. As in an EU GDPR context, you can only perform the transfer if the data remains suitably protected, or one of the exceptions applies. The data remains suitably protected if the target country was attested and “adequate” level of data protection, or if you have implemented appropriate safeguards. As of 2022, the list of countries considered adequate is generally equivalent to the EU list of adequacy decisions. Notably, the US is no longer on that list after the Schrems II decision that invalidated the Privacy Shield Agreement. Since this decision was made before Exit Day, it also applies in the UK. This leaves “appropriate safeguards” for UK→US restricted transfers. In the linked ICO page, read the section Is the restricted transfer covered by appropriate safeguards?. In brief, you will need to perform a Transfer Impact Assessment, and sign Standard Contractual Clauses with the US data importer. In a Transfer Impact Assessment (TIA), you check that the data remains protected despite the transfer into a country without an adequate level of data protection. There is no official guidance on conducting a TIA, but the IAPP has a template and the EU EDPB has recommendations on supplemental measures to protect data transfers, which might reduce the risk and affect a TIA in your favor. It's worth noting that the EDPB recommendations were written in the wake of the Schrems II ruling, and can be summarized as “compliance is impossible when using US-based cloud services”. But this is your assessment, and TBH it seems the UK is a bit more relaxed than the EU in this regard. The Standard Contractual Clauses (SCCs) are a pre-formulated contract that binds the foreign data importer to handle the data properly. In essence, this translates relevant aspects of the UK GDPR into contract law. Many service providers already provide a Data Processing Agreement that includes SCCs by reference, but you'll have to make sure that these contracts have been entered in a legally binding manner. Sometimes these apply automatically as part of the terms of service, sometimes you need to explicitly sign these documents. But SCCs are one detail where UK GDPR compliance and EU GDPR compliance diverges a bit. The old EU SCC templates from 2004/2010 can no longer be used and have been replaced. For compliance with the EU GDPR, the new 2021 SCCs must be used. For compliance with the UK GDPR, you have two options. You can either use the 2022 International Data Transfer Agreement (IDTA), or you can use the 2021 EU SCCs along with the 2022 UK International Data Transfer Addendum which modifies the EU SCCs in some details. Don't want to deal with TIAs and SCCs? Switch to a hosting provider that only processes the personal data under your control in the UK, or in a country with an adequacy decision (e.g. EU, Canada, Israel).