Can a data controller change their privacy policy without explicit consent? While I read one of the updated privacy policies (PP) this week, the following section of a privacy policy seemed… off: We may change this Privacy Policy from time to time, and all changes will be effective at the time we post them. If we believe there is a significant change to this Privacy Policy or our data collection and use practices, we will indicate on our websites that our Privacy Policy has changed prior to the change becoming effective. While the website indication is probably enough if I'm an active user, this service stores account information, and I might not visit it for a long time and therefore miss the indication on the website. If the new PP now contains a section that allows third parties to use my data I might notice that too late. For simplicity, this question concerns data that was already stored when a privacy policy changed, not newly acquired data afterwards. Is a change of a privacy policy without explicit consent valid under the GDPR? If I understand Article 6 (1) a) correctly, the PP must not add change the purposes a data subject has given consent to, unless at least one of Article 6 (1) b)-f) holds. (This is related to terms-of-service changes without notice, which, at least in Germany, are only allowed if the possible causes where explicitly listed, as far as I know).
The consent presented in the question is a text-book example on how to not secure consent under the GDPR. The GDPR requires concent to be explicit, specific, freely given, and informed. This particular privacy policy does not measure up to any of these requirements. The GDPR goes to great lengths to regulate consent. For instance, in Article 7 (2) is says: Any part of such a declaration [of consent] which constitutes an infringement of this Regulation shall not be binding. So if the consent obtained is not explicit, specific, freely given, and informed, and the company relies on consent to ensure lawfulness of processing, it is breaking the law (and may be fined under the GDPR). The big problem with this privacy policy is this sentence: Your continued access to or use of any of the Services shall be deemed your acceptance of the Privacy Policy. As you've noted, the GDPR requires consent to be explicit. What "explicit" means is spelled out in Recital 32, which (among other things) says: Silence, pre-ticked boxes or inactivity should not therefore constitute consent. And Recital 32 goes on state that consent must be specific: When the processing has multiple purposes, consent should be given for all of them. The full privacy policy lists 16 different purposes for which personal data is collected, but do not seek specific consent for any of them. Consent under GDPR must also be freely given. Recital 42 says (among other things): 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. Here the company states that continued use of the service "shall be deemed your acceptance". The only way the data subject can refuse consent is to not use the service, which is to the detriment of the data subject. This also makes the consent invalid. Finally, the GDPR also requires consent to be informed. What this means is spelled out in Recital 42, which (among other things say): For consent to be informed, the data subject should be aware at least [...] the purposes of the processing for which the personal data are intended. Here the data subject is supposed to consent to some unknown, future change which may be to allow different purposes of the processing. This also invalidates the consent.
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.
GDPR compliance is a matter between every customer and the business, not between different customers. How did you get the other customer's contact details? If they were provided or leaked by the business, that might be a failure of the business's obligation as a data controller to protect the personal data they are processing, possibly even a data breach in the sense of the GDPR. When you contacted the other person this was presumably a purely private or household activity, just like contacting any other personal acquaintance. In that case, the GDPR simply does not apply to any “processing” you may have done (compare Art 2(2)(c)). Things would be very different if you were promoting your own business, but that doesn't seem to have been the case. If the matter really is as plain as you described, then you can effectively ignore their references to the GDPR until you are contacted by your data protection authority, by their lawyer, or are served with court papers. None of these should happen: even if you were a “data controller” and your processing were subject to the GDPR – only the other customer and not the business would be the data subject, and only a data subject has a right for remedies like making complaints to the data protection agency and only the data subject would have standing to sue you in court for GDPR violations.
In principle, the data subject's right to access involves a copy of all personal data the controller holds on them. There are no time limits by default. Of course, the controller can ask a data subject to clarify their request, e.g. to focus on a particular time frame. There is an implied time limit though: personal data may only be processed/stored for as long as the data is necessary to achieve the purposes for which it was collected. Afterwards, it must be deleted. A controller with good data management will be able to limit their effort by having as short retention periods as possible for their different records. Furthermore, a lot of data is not personal data, or falls out of scope of the GDPR because it is not processed with automated means or forms part of a filing system. For example, if thousands of old invoices were archived in paper form in boxes that are only sorted by year, there might be an argument that this isn't a filing system in the sense of the GDPR and that a DSAR would not have to involve looking through all the archived invoices (compare also Art 11). In your scenario, there is a clear retention period of six years. You are asking for records about how that data might have been used further in the past. To the degree that such data is actually available, that could reasonably be personal data and should be included in a response to a DSAR. E.g. they might have information like this: “File #1234 was included in a data set that was sold to EvilCorp in 2007. The entries in File #1234 that are older than 2014 have been purged, so we do not know which entries were included in the data set. The current name on File #1234 is Dave.” This information about the sale would be personal data because it relates to you, and you are identifiable. Of course, the controller might not be set up to perform this search unless specifically asked. However, more unspecific information might not be personal data. For example: “About 70% of our files were included in a data set that was sold to EvilCorp in 2007. We no longer have records indicating whether your file was included.” Since there is no link between the sale and your personal data, I don't think it would have to be included in a DSAR response. The primary reason why you should be told about sales of personal data is that per Art 15(1)(c), you should be informed about “the recipients or categories of recipient to whom the personal data have been or will be disclosed” in a DSAR response. So when making a data subject access request, it could make sense to explicitly referencing this paragraph. So you would be interested in receiving a copy of your personal data as per Art 15 GDPR, and in particular any available information per Art 15(1)(c) GDPR about the recipients or categories of recipients to whom your personal data has been or may have been disclosed in the past. Quite likely the response will be underwhelming, e.g. by just giving a broad category such as “potential creditors who are contractually obligated to use the data only in accordance with our policies”. Whether such responses are compliant (I don't necessarily think so) will not be clear until there's a good precedent, and that would require that someone sorts this out in court.
Yes, GDPR applies: you are a data controller established/living in the UK or are offering services to people in the UK you fall under the material scope of the GDPR. The Art 2(2)(c) exemption for “purely personal or household activity” does not apply since you're offering the service to the public. You must consider GDPR compliance here. This is especially important as you are showing personal data to the public. Don't do that unless you have a very good reason, appropriate safeguards, and are clear to users how their information will be shown. On a high level, GDPR compliance involves working on the following questions: For what purpose are you processing personal data? Context: purpose limitation principle per GDPR Art 5(1)(b) What is the legal basis for processing? GDPR Art 6(1) lists the available legal bases. Here, consent, necessity for performance of a contract, or a legitimate interest could be a legal basis. They may have further obligations attached. A legitimate interest requires a balancing test that considers the data subject's rights and freedoms. Consent must fulfil the conditions per Art 7 in order to be valid. What is the minimal data necessary to achieve the purpose? Per the Art 5(1)(c) data minimisation principle, it is illegal to process personal data beyond what is necessary and adequate. You must provide data protection by design and by default per Art 25. Special categories of data per Art 9 such as health data are illegal to process outside of narrow exemptions. You must delete data once it is no longer necessary. What appropriate safeguards and security measures should you apply? Per Art 24 and 25, you are responsible for determining and implementing appropriate measures. This depends a lot on your specific context, so there's no checklist you can apply. Per Art 25(1) you must pseudonymize the processed information if that is compatible with the processing purpose. What further compliance measures do you have to consider? There are additional GDPR and non-GDPR compliance measures. From the GDPR side: Use the answers to these questions to write a privacy policy, including the information that you must provide to data subjects per Art 13. Consider whether you have to maintain a Records of Processing document per Art 30, or if you have to make a Data Protection Impact Assessment per Art 35. If you use third party services, figure out whether they are a joint controller or data processor and apply appropriate safeguards. If you have data processors, ensure that you have a contract in place that covers the items from Art 28(3). If you share data with other controllers (not processors) you need a legal basis for doing so. If you transfer data into a non-EU/EEA country (after 2020: non-UK country) you need a legal basis per Art 44 and have to cover additional items in your privacy policy. Ideally, the target country is covered by an EC adequacy decision per Art 45. For US-based companies, this is the case only when they have self-certified under the Privacy Shield framework. Non-GDPR compliance steps could include cookie consent banners, or showing a VAT ID. How can you prepare for data subject requests? Data subjects have various rights per Arts 15–23, subject to the modalities in Art 12. For example, a data subject could request that their information is erased from your website. The exact rights also depend on the legal basis you selected. You should figure out in advance how to deal with such requests.
Your title is not necessarily consistent with your example. Can a website demand acceptance of non-essential cookies to allow access? As you have found, GDPR prohibits conditioning the provision of service on consent to the processing of personal data. Cookie walls without alternative means of access are generally considered violations of the GDPR. Can a website demand acceptance of non-essential cookies to allow free access? The situation of a &quot;consent or pay&quot; scheme (or &quot;cookie paywalls&quot;) is more uncertain and has not been clearly settled at the EU level. There are data protection authorities that do not consider such scheme necessarily a GDPR violation (Austria, France) if a reasonable alternative access, without requiring non-essential cookies, is provided. For what it is worth, the French data protection authority (CNIL) held initially that all cookie walls are illegal, but on appeal from publishers and advertisers, the French supreme administrative court annulled CNIL's initial guidelines for being too absolute. German and Italian authorities are still examining the validity of such scheme. More reading: Consent or Pay: Privacy Considerations with Cookiewall-Paywall Hybrid Solution, https://securiti.ai/blog/cookie-paywall/ Is the use of a cookie wall allowed in European Countries, https://www.iubenda.com/en/help/24487-cookie-walls-gdpr
Among other things, GDPR regulates what you may do with the data within your systems. You can use it for the contracted purpose, or in accordance to law, or with informed and revokable consent, or for some other enumerated purposes. Even with consent, you have to take security measures to avoid the misuse of the data. Remember the software shrink-wrap licenses? &quot;By opening the package, you agree to the terms inside.&quot; GDPR makes the equivalent in the cloud world impossible. You have to document exactly what you do with the data, and for any use that is not necessary to perform the service the customer can opt out. In the scenario you describe, it is possible that you are not the data controller under GDPR but the data processor, and that you have a duty to keep the data from separate controllers apart. And delete any batch at the end of contract. If you want to do this professionally, you need to consult a lawyer for your specific plans.
The GDPR will probably not allow a successful demand for erasure in these circumstances. The company does not need to argue &quot;that they can't delete user information for fear of be liable for.something&quot; because GDPR art 17 1(c), 3(b), and 3(e) already make that case for the company. Lets look at the relevant law. GDPR Article 17 reads in relevant part: (1) The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies: (1) (a) the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed; (1) (b) the data subject withdraws consent on which the processing is based according to point (a) of Article 6(1), or point (a) of Article 9(2), and where there is no other legal ground for the processing; (1) (c) the data subject objects to the processing pursuant to Article 21(1) and there are no overriding legitimate grounds for the processing, or the data subject objects to the processing pursuant to Article 21(2); ... (3) Paragraphs 1 and 2 shall not apply to the extent that processing is necessary: (3) (a) for exercising the right of freedom of expression and information; (3) (b) for compliance with a legal obligation which requires processing by Union or Member State law to which the controller is subject or for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; ... (3) (e) for the establishment, exercise or defence of legal claims. Art 17 Par 1 (a) only allows erasure when data are &quot;no longer necessary&quot;. But depending on how the purposes were worded by the Controller, they may well still be necessary Art 17 Par 1 (b) only allows erasure when consent is withdrawn and consent was the legal basis for processing. But a contract with the user is a much more likely basis for processing for a financial service. Art 17 Par 1 (c) requires erasure if the user objects and there is no &quot;overriding legitimate grounds for the processing&quot; but the needs to maintain financial records of a transaction is probably an &quot;overriding legitimate ground&quot;. In any case par 3 alloys erasure to be refused &quot;for compliance with a legal obligation&quot; or &quot;for the establishment, exercise or defence of legal claims&quot;. Financial records may well fall into one or both of these categories, at least as regards transaction data. In short it is far from clear that the GDPR will require erasure in these circumstances.