How can Standard Contractual Clauses overcome Schrems II? My understanding of Schrems II was that it essentially said the US did not provide adequate data protection because of the potential access intelligence agencies there have and the lack of legal recourse non-US citizens have, and consequently agreements such as Privacy Shield and Standard Contractual Clauses were invalid for making data transfers legal. However, it seems multiple SaaS products still transfer data there under amended Standard Contractual Clauses, e.g: Figma: Figma relies on Standard Contractual Clauses for the transfer of personal data out of the EU and has implemented certain supplementary measures for EU to US data transfers based on the Schrems II decision I'm confused as to what supplementary measures Figma has/could even have added to a contract to change that? Is this likely to hold up, or also probably invalid and just not enforced/tested in court yet? How is it possible for Contractual Clauses to mitigate privacy risks enshrined by law in the US?
The Schrems II decision (C-311/18) primarily discussed the &quot;Privacy Shield&quot; adequacy decision, but also covered SCCs. The CJEU confirmed that SCCs are generally valid. However, the CJEU also pointed out that the data exporter must first consider whether SCCs can actually be used in their specific context. From paragraph 141 of the judgment: It follows that Clause 4(a) and Clause 5(a) and (b) in that annex oblige the controller established in the European Union and the recipient of personal data to satisfy themselves that the legislation of the third country of destination enables the recipient to comply with the standard data protection clauses in the annex to the SCC Decision, before transferring personal data to that third country. […] Translated to normal English: the SCC terms require the data exporter and data importer to check that the legal environment in the destination country actually allows the importer to comply with the terms of the SCCs. Since Schrems-II, it is common to prepare a &quot;transfer impact assessment (TIA)&quot; that contains such analysis. Options for valid SCC-based international transfers A Schrems-II compliant data transfer based on SCCs could work in the following scenarios: there are no problematic laws in the destination country while there might be problematic laws, they do not apply to the data importer even if the data importer is subject to problematic laws, supplemental safeguards such as end-to-end encryption prevent the personal data from falling into unauthorized hands (unofficial theory:) even if the data importer is subject to problematic laws, the risk of these laws being invoked is negligible in practice Let's analyze these options for the case of EU to US transfers: The Schrems II case seems to deny the first option, since it explicitly found that the lack of legal redress means that the US do not provide an &quot;adequate&quot; level of data protection. After the judgment, some such as the US government argued that this was based on outdated laws (cases take a long long time), and that the current legal environment is perfectly fine. After additional changes to US government policy, the EU Commission later joined this argument and issued a new &quot;Data Privacy Framework&quot; adequacy decision in 2023. I occasionally saw US companies arguing that they are not subject to problematic laws like FISA 702 because they are not a communications provider. If true, that may have been a valid argument. The EDPB published recommendations on implementing supplemental measures such as pseudonymization or encryption to protect the GDPR-covered personal data even when it is processed in the US. However, these supplemental measures have to operate with an extreme threat model: successfully defending against access by US government three-letter agencies (NSA, FBI, CIA). In practice, these recommendations ruled out any use of US-based cloud or SaaS services, and did not provide a reasonable option for continuing EU→US data transfers. But since claims about supplemental measures are easier to make than to verify (and since most data protection authorities did not actively seek out potential data transfer violations), this was a very common choice. Supervisory authorities note that details about the supplementary measures should be provided to data subjects on request, but this has been rare. Where I have seen details about such measures, they were usually techniques like transport encryption (like HTTPS) and encryption at rest, which fall clearly short of the EDPB recommendations. Sometimes, I've seen attempts at anonymization, but usually implemented for an US-centric view of &quot;PII&quot; that ignores the nuances of the GDPR's &quot;personal data&quot; concept. Techniques that could actually work – like homomorphic encryption – have been largely absent in this space, but that unsurprising given the novelty and overhead of such technologies. The EU's CJEU did not permit a risk-based approach to TIAs, but it has found blessing in the UK, and it has been widely practiced by industry. In B2B, the customers might be on the hook In a B2B context, there is another aspect: Who is the data controller who is primarily responsible for GDPR compliance? Often, we have a US SaaS provider who offers a pre-formulated DPA/SCC, and an EU-based customer company. In many cases, the EU-based customer will be the data controller, and responsible for the international data transfer. The SaaS provider would typically be a &quot;data processor&quot;, who has no direct GDPR obligations and is only responsible for fulfilling their contract with their customers. In such constellations, the US-based providers often advertise themselves as 100% GDPR-compliant, even though the real question is whether the customers can use that service in a GDPR-compliant manner. Figma's policies In the case of Figma, this means that most of the risk of having potentially invalid SCCs is not shouldered by Figma, but by their EU-based customers. FYI, the Figma GDPR FAQ you linked in turn links to their full DPA (permalink), which lists supposed supplementary measures in Exhibit C (in addition to the security measures in Exhibit B). These supplementary measures are of a solely organizational nature, such as consulting with expert legal counsel, nicely asking the government to contact the customer directly, and publishing an annual transparency report. The DPA also includes a transparency report, noting that between 1 July 2022 and 30 June 2022, zero US government requests were received, and that no court found Figma to be subject to FISA 702. While I have my doubts about the suitability of such measures to prevent government access, a transparency report is useful for making risk-based arguments. I tried looking for their updated report which should be due this month, but realized that &quot;Figma Transparency&quot; is impossible to search for online :)
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).
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).
First of all, although the GDPR is stated to apply to any site which processes the data of any person who is in the EU, it is not clear how a site not located in the EU, does not business in the EU, and does not primarily target EU residents as its audience can be required to comply with the GDPR. To the best of my knowledge, no such case has yet been brought, much less decided. There has also been some debate on whether an IP address constitutes Personal Data under the GDPR, and if it always does so, or only under particular conditions. The European Court of Justice (ECJ) held that (under the predecessor Directive 95/46/EC) that a dynamic IP address was personal data. But in that case the web site was run by the German Federal Government, which surely has wider scope for getting info from a German ISP than a small private US web activist does. There is not yet any case law that I know of on the applicability of the GDPR to IP addresses in any case at all similar to the one in the question. Joe would in my view be wise to at least learn that logs are being kept, and post a disclosure of this on the site. Whether Joe needs to do more than that is less than clear at this time.
It is the data controller's responsibility to respond to data subject requests. If you provide a B2B service, you are most likely a data processor who only acts on the controller's behalf, on the controller's explicit instruction. This will depend on your contract with the controllers, your customers (see Art 28). Typically a processor would merely forward any data subject requests to the controller. Only if you are contractually obligated to serve data subject requests would it be possible for you to respond directly. If a processor were to fulfil a data subject request on their own initiative, that would arguably be a GDPR violation. However, the processor has to assist their controller with compliance per Art 28(3)(e), e.g. by implementing an admin interface through which the controller can service GDPR requests. The core issue here is that controllers and processors have slightly different obligations in order to be GDPR compliant. Controllers owe compliance to the data subjects, but processors only act on the controller's behalf and owe compliance to their controllers – they have no direct relationship with data subjects. Assuming you were a controller, then yes, I would assume you would have to decrypt any data that you are able to decrypt in order to fulfil a data subject request. Access requests can only be denied if: Art 12(5): they are “manifestly unfounded or excessive” (which the controller has to demonstrate), or Art 15(4): the access would “adversely affect the rights and freedoms of others”. Art 11(2): the controller can demonstrate that they are actually unable to identify the data subject so no data subject rights in Art 15–20 apply. A request is not automatically excessive just because it will require substantial CPU time, this exception is more often triggered when data subjects request the same data very frequently (e.g. every week). You are not required to provide or search data that you don't have access to (e.g. E2E encrypted data). Your use of per-field encryption is a very strong security measure (depending on how keys are managed). But GDPR is not about achieving maximum technical data protection, but merely requires appropriate safety measures (see GDPR Chapter 4, especially Art 32). Asymmetric encryption of small fields within a database is unlikely to be appropriate, taking into account the cost of processing and the data subject's ability to exercise their rights. A different security measure to ensure that every business only sees the correct data would be through testing and code review of your SQL queries, and full disk encryption of the server storing the database. In practice, asymmetric encryption is most often just used to encrypt a symmetric key, which is then used for the actual data. But which measures are appropriate also depends on the risk to data subjects – your approach could make sense for very sensitive data. Art 14 does not play a role here. It is about transparency of processing: that you need to (a) notify the data subject that you're processing their data, if feasible, and that you (b) provide information about this processing, usually in form of a privacy policy. Art 14 is the pendant to Art 13, which applies when data is obtained directly from the data subject. The Art 15 right to access and the Art 20 right to data portability are distinct from the right to be informed. In any case, it is the controller's responsibility to fulfil these rights.
Well actually... I think you'll just need to wait a little more. I monitor the situation quite closely and I can tell you that it's just a matter of time. Microsoft was one of the first (if not the first) to communicate openly about the GDPR and the changes that follow. From the blog post: If your organization collects, hosts or analyzes personal data of EU residents, GDPR provisions require you to use third-party data processors who guarantee their ability to implement the technical and organizational requirements of the GDPR. To further earn your trust, we are making contractual commitments available to you that provide key GDPR-related assurances about our services. Our contractual commitments guarantee that you can: Respond to requests to correct, amend or delete personal data. Detect and report personal data breaches. Demonstrate your compliance with the GDPR. Microsoft is the first global cloud services provider to publicly offer you these contractual commitments. We believe privacy is a fundamental right. The GDPR is an important step forward to further clarify and enable individual privacy rights and look forward to sharing additional updates how we can help you comply with this new regulation and, in the process, advance personal privacy protections. Microsoft has set up an informational site on GDPR here. If your eyes are on any other provider, I think the only way to learn more is getting in touch and inquiring about their progress and process. Hope this helps.
It is not possible for someone to forfeit their rights because the GDPR is compulsory law. In the EU, laws can be regulatory or compulsory. In case of an agreement, regulatory laws can be set aside, if both parties agree on that. But compulsory laws cannot be set aside. Of course laws can also be partly compulsory. For example provisions which cannot be changed in disadvantage of a consumer. So there is freedom of contract, but it's freedom is reduced by law for the common good or for example to avoid misuse of bargaining power. In particular consumer related laws are often compulsory because it has little power against the other parties. Companies can have their negotiations done by lawyers, so they can make a well informed an well negotiated decision. As an extreme example, you cannot kill someone, even if that person has given you written permission. See also "Peremptory norm" on wikipedia for international law examples.
Given a large database of email addresses that you can't prove have given consent to receive email, the only legal thing to do with it, is to (securely) delete it. (I am going to switch your question about a larger company to a bank: in the UK, big pharma is forbidden from advertising to individuals.) In principle the rules are the same for a huge bank and everything down to a self-employed plumber. In practice the plumber will be told "don't do that again" rather than fined. This case was treated under the Data Protection Act, which has a maximum fine of £500,000&nbsp;&ndash; so a big bank would probably have been fined more, but not necessarily much more. Under GDPR, fines are related to turnover, so the fine would be a lot bigger for a large bank. The incident is a year old now. Details here.