What actions to take when a Data Processor doesn&#39;t respect GDPR? We've recently exchanged emails with one of our Data Processors, because they don't grant the ability to permanently delete hosted documents (pdf, png, etc.) on their platform. Such documents might contain personal information. In the event where an end-user would want to permanently delete such documents, we don't have the ability to do it for them (because the Provider doesn't give us any tool for doing so). Thus, we can't comply with any privacy-related request from our end-users. It also seems even the Processor cannot perform such a request in the event where we would forward the request to them. (they don't seem to have the necessary tools, either) Therefore, we believe they don't comply with GDPR because of the Right to erasure/rectification. The Processor doesn't recognize their responsibility on this matter, and are stating they respect GDPR regulations. Although, they haven't provided us with any meaningful reply regarding that particular matter. They're basically saying they're doing things &quot;by the book&quot; and sending us links to their online documentation, which do not answer the issue at hand. At this point, we're concerned about what to do next. It feels like they won't acknowledge the issue and won't take responsibility about fixing it. We're thinking about opening an official enquiry, but we're unsure how to proceed. Edit: The data processor is based in the US, while we are based in France (EU). We have signed a DPA with them.
The data processor is not responsible for complying with the GDPR. You are ultimately responsible, since you are the data controller. The data processor is merely required to assist you, but it's unclear what that means in the presented scenario. Per Art 28(3)(e) GDPR, the DPA must require the data processor to provide reasonable assistance: That contract or other legal act shall stipulate, in particular, that the processor: […] taking into account the nature of the processing, assists the controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the controller’s obligation to respond to requests for exercising the data subject’s rights laid down in Chapter III; However, per Art 28(1) you can only engage processors that you deem sufficient to protect the data subject's rights: the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject. Here, it seems that your company failed to ensure that the processor provides the features you need for compliance. Many companies claim to be GDPR-compliant, but that doesn't mean that your use of their services will be GDPR-compliant as well. Depending on how the Art 28(3)(e) requirement was implemented in the DPA you may have a right to assistance even if the processor doesn't implement necessary features in their software, but enforcing this contract could require a lawsuit in a foreign jurisdiction (but that's par for the course for international B2B contracts). It is worth noting that the GDPR right to erasure doesn't always apply. In a processing activity where no erasure right is likely to arise, it would be perfectly fine to use a data processor that doesn't offer any possibility for erasure. Similarly, it can sometimes be legal to use technologies like Blockchain or Git that make erasure difficult or impossible. However, it is the responsibility of the data controller to analyze the impact of such a choice up front, before commencing the processing activities. In some cases, this could require a Data Protection Impact Assessment (DPIA). Note that transfers of personal data into the US are illegal or at least questionable in the wake of the 2020 Schrems II ruling. The Privacy Shield is no longer a legal basis for such transfers. Standard Contractual Clauses (SCCs) are technically allowed, but only “on condition that enforceable data subject rights and effective legal remedies for data subjects are available” (cf Art 46). The ECJ's judgement calls this into question. This could be a further incentive to migrate to a more GDPR-compliant service.
Overview As described, only the last of these seems to be compliant ways of obtaining consent, and indeed even that is not fully compliant, although features not described might make it so. However, if there is a lawful basis for processing PI other than consent, under GDPR article 6, then there is no need to obtain consent at all, and doing so in an improper way is irrelevant. However storage of or access to local information (such as cookies) requires consent unless such storage or access is &quot;strictly necessary&quot; for providing a service which the user has requested. Relevant GDPR Provisions GDPR article 6 lists six possible lawful bases for processing personal data. These are, in summery: (a) consent; (b) processing is necessary for the performance of a contract or to takwe steps requested by the Data Subject; (c) necessary for compliance with a legal obligation; (d) to protect the vital interests of the data subject or another person (e) or the performance of a task carried out in the public interest (f) legitimate interests of the Controller The other provisions cited here apply only to PI for which the lawful basis is consent. GDPR article 7 reads: (2) If the data subject’s consent is given in the context of a written declaration which also concerns other matters, the request for consent shall be presented in a manner which is clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language. Any part of such a declaration which constitutes an infringement of this Regulation shall not be binding. (3) 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. When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract. GDPR 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. Consent should cover all processing activities carried out for the same purpose or purposes. When the processing has multiple purposes, consent should be given for all of them. 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. GDPR Recital 42 reads: ... in particular in the context of a written declaration on another matter, safeguards should ensure that the data subject is aware of the fact that and the extent to which consent is given. 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. For consent to be informed, the data subject should be aware at least of the identity of the controller and the purposes of the processing for which the personal data are intended. 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. GDPR Recital 43 reads: ... Consent is presumed not to be freely given if it does not allow separate consent to be given to different personal data processing operations despite it being appropriate in the individual case, or if the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance. Analysis I will review each of the scenarios in the question in turn. Scenario 1: not allowing [a user] to use the site until the user clicks Accept. No options, just an &quot;Accept&quot; button. This does not constitute freely given consent, because: The giving of consent is not &quot;clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language&quot; (Art 7(2)). There appears to be no way to withdraw consent (Art 7(3)). It appears that the provision of a service (use of the site) is conditional on consent not needed for that service (Art 7(3)). Consent is not informed and unambiguous (Recital 32). The use has not been informed of the extent to which consent is given (Recital 42). The subject has not been made aware of purposes of the processing (Recital 42). the data subject has no genuine or free choice (Recital 42). There is no provision for separate consent to be given to different personal data processing operations. (Recital 43). Scenario 2: A banner stating that &quot;By browsing the site you accept the conditions&quot;. Just an &quot;x&quot; to close the banner. Using the site is allowed while the banner is displayed. This does not constitute freely given consent, because: Consent was not &quot;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&quot; (Art 7(2)). The giving of consent is not &quot;clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language&quot; (Art 7(2)). There appears to be no way to withdraw consent (Art 7(3)). Consent is not informed and unambiguous (Recital 32). The use has not been informed of the extent to which consent is given (Recital 42). The subject has not been made aware of purposes of the processing (Recital 42). the data subject has no genuine or free choice (Recital 42). There is no provision for separate consent to be given to different personal data processing operations. (Recital 43). Scenario 3: A banner with an &quot;Accept&quot; (and possibly &quot;Reject&quot;) button. No other options. Site navigation is allowed while the banner is displaying. This does not constitute freely given consent, because: The giving of consent is not &quot;clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language&quot; (Art 7(2)). There appears to be no way to withdraw consent (Art 7(3)). Consent is not informed and unambiguous (Recital 32). The use has not been informed of the extent to which consent is given (Recital 42). The subject has not been made aware of purposes of the processing (Recital 42). There is no provision for separate consent to be given to different personal data processing operations. (Recital 43). Scenario 4: A banner with an &quot;Accept&quot;, &quot;Reject&quot; and also a &quot;Settings&quot; options where the user can fine tune the way his data is being used by the site. This might constitute freely given consent, provided that: a document is displayed or linked to that describes the kinds of PI that will be processed, and the purposes of the processing; There is some easy and obvious manner to withdraw consent, and to change the individual choices on what to consent to, after the banner has closed, or on any subsequent visit to the site; The consent section of the settings dialog must be clearly distinguished from other sections that do not deal with consent; Just where the lines must be drawn between &quot;different personal data processing operations&quot; which each requires the possibility of separate consent is not yet fully clear. And again, if the site or service does not store or otherwise process PI, or has a lawful basis for doing so other than consent, and does not store or access local information, it need not obtain consent at all, and the question of what constitutes freely given consent becomes irrelevant. Of course many sites do depend on consent as the lawful basis for much of their activity.
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.
This issue touches upon two distinct GDPR rights: Art 15 right to access: you have a right to receive a copy of all personal data concerning you that are undergoing processing (including storage). Access may only be denied where this would “adversely affect the rights and freedoms of others.” Art 20 right to data portability: if processing is being carried out by automated means, and processing is based on certain legal bases (consent or contract, but not legitimate interest), then you have a right to receive a copy of your personal data in a machine-readable format, for personal data that you have provided to the data controller. Whereas the right to access is fairly straightforward, the right to data portability applies under much more narrow conditions. Basically, it's a right that you can download any data that you've uploaded so that you can move to a different service. Google Takeout is primarily concerned with your right to data portability, and provides your data in a machine-readable format. Any photos that you've uploaded to Google Photos, you'll be able to download. Thus, it could be technically compliant to exclude information that they've inferred about your personal data, such as image-recognition results. Such results would still be personal data under the GDPR definition of the consent, and would be covered by your right to access. Google might argue that you already have access to this data through the web interface. In my opinion the GDPR clearly requires the data controller to provide a “copy”, i.e. the data in some durable form – not merely access through a web interface. Whereas your question is specifically about Google, the same issue applies to other services as well. E.g. Ruben Verborgh has an interesting blog series on trying to get access to all their data from Facebook, though unsuccessful so far. Similar to your scenario, Facebook offers a download for personal data but does not include all personal data in this download. In one of the documents provided by Facebook in the course of the exchange, they note that they allow access to photo tags through the web interface, but do not include this in downloaded data – without providing further justification.
This is a good question, as it raises an issue which places the controller's interest in providing a smoothly functioning customer sign up process against customers' right not to have their data leaked. Note that it is not necessary to consider &quot;enumeration&quot; here. Even just being able to check whether one person has a registered account raises the issue. The relevant provisions of the EU GDPR (or in the UK, the UK GDPR as defined in sections 3(1) and 205(4) of the Data Protection Act 2018) are (emphasis added): Article 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, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction So, disclosure of the fact that a user has a registered account amounts to &quot;processing&quot;. Article 6(1): Processing shall be lawful only if and to the extent that at least one of the following applies: (a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes; (b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; (c) processing is necessary for compliance with a legal obligation to which the controller is subject; (d) processing is necessary in order to protect the vital interests of the data subject or of another natural person; (e) 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; (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Of these, only (a) and (f) are likely to be of any relevance: (a) is not too useful since it isn't feasible to design a sign-up system that depends on the user's consent (which they may not give). That leaves us with (f). As noted by the Information Commissioner's Office, &quot;Legitimate interests is the most flexible lawful basis for processing, but you cannot assume it will always be the most appropriate. It is likely to be most appropriate where you use people’s data in ways they would reasonably expect and which have a minimal privacy impact, or where there is a compelling justification for the processing.&quot;. The legitimate interest here would be that you need a sign up system which prevents duplicate registrations. Remember though that the processing has to be &quot;necessary&quot; for the purposes of the legitimate interest. One might argue that it is not since you could design the system to give the appearance of accepting the duplicate registration followed by sending an email to the account holder to inform them. On the other hand this will result in a less user friendly experience which could itself be a legitimate interest. Ultimately this is a balancing exercise and it is hard to say whether you have struck the right balance until someone complains to the ICO or the court and a decision is issued. The fact that the practice is widespread among well-resourced and large companies would tend to indicate that it is lawful albeit this is not conclusive in the absence of a court decision. I'm not aware of any cases involving this particular issue but would be interested to hear from others on this point. If the processing is unlawful then Article 18 is applicable: The data subject shall have the right to obtain from the controller restriction of processing where one of the following applies: [...] (b) the processing is unlawful and the data subject opposes the erasure of the personal data and requests the restriction of their use instead Where processing has been restricted under paragraph 1, such personal data shall, with the exception of storage, only be processed with the data subject’s consent or for the establishment, exercise or defence of legal claims or for the protection of the rights of another natural or legal person or for reasons of important public interest of the Union or of a Member State. In other words, the data subject could ask you not to disclose their registration status via the sign up page, and you would be obliged to comply with the request. Separately from the above points, in order to be lawful you must provide the data subject with certain prescribed information at the time when the data is collected. Of particular relevance here are the following items: Article 13(1): Where personal data relating to a data subject are collected from the data subject, the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information: [...] (c) the purposes of the processing for which the personal data are intended as well as the legal basis for the processing; (d) where the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party; So even if you conclude that the processing will be lawful you will have to give some consideration to the basis so that you can comply with the above provision.
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.
These documents constitute personal data and - in principle - you, as the subject, have the right to get a copy of them by issuing a "subject access request". The controller shall provide a copy of the personal data undergoing processing. For any further copies requested by the data subject, the controller may charge a reasonable fee based on administrative costs. Where the data subject makes the request by electronic means, and unless otherwise requested by the data subject, the information shall be provided in a commonly used electronic form. (Art. 15 (3) GDPR) GDPR applies to controllers of any kind, including government organisations. The subject access request can usually be a simple email. The ICO has a template for this: https://ico.org.uk/your-data-matters/your-right-of-access/ (but keep it simple, you can literally just ask for "all personal data" they have on you; no need to speculate on what kind of data they may have). The subject access request is sent to the actual controller, but if you don't get a response to your request after 30 days, you can file a complaint with the supervisory authority (see here for Germany; note that federal institutions are supervised by the BFDI, not the data protection authorities of the Länder). Also note that you may have to go through some trouble to be properly authenticated by the controller. They do need to be certain that you are the data subject. There are also reasons why a controller can refuse to provide some or all of the information (e.g. if your request is clearly excessive or unfounded, if it's impossible to comply without violating another data subject's rights), but I would be surprised if any of those applied in your case. Your rights can also be restricted depending on the legal basis for processing. This includes rights that are illogical as well as some that provide special protection for processors: You can't object to processing based on consent (but you can revoke your consent), fulfilment of contract (but you can cancel your contract), a legal obligation on the part of the processor, or a vital interest (but you still have the right to erasure) Your right to portability and right to erasure does not apply if processing is based on a legal obligation or a public task (justice, parliamentary or government functions, statutory functions etc.) your right to portability also doesn't apply if processing is based on vital interest (e.g to protect someone's life) or legitimate interest of the processor. It is possible that processing all or some of your data was based on the performance of a public task, in which case they will refuse your request.
Under GDPR Article 6 section 1(f), a lawful basis for processing is: processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. It seems that informing a data subject of the availability of a possibly better-focused related site would be a &quot;legitimate interest&quot;, and merely doing a broad geo-locate on the IP does not seem to impact the &quot;interests or fundamental rights and freedoms of the data subject&quot; so it would seem this could be done without specific consent in advance. I don't know of any legal case on this specific point, however.