Can I provide multiple legal bases for GDPR purposes? I used Termly's privacy policy generator, and in the policy that they generated there are four Article 6 legal bases: Consent Legitimate Interests Legal Obligations Vital Interests I took a screenshot of the section that lists the legal bases. Now, my question is, does Termly's approach work at all? Does it have any legal value? I thought that you can only choose one legal basis at a time. This is what the ICO has to say about changing the legal basis You must determine your lawful basis before starting to process personal data. It’s important to get this right first time. If you find at a later date that your chosen basis was actually inappropriate, it will be difficult to simply swap to a different one. Even if a different basis could have applied from the start, retrospectively switching lawful basis is likely to be inherently unfair to the individual and lead to breaches of accountability and transparency requirements.
There are two related aspects to this question: can multiple legal bases cover the same processing purpose, and how must this information be presented in the privacy notice? In the following, this answer will address the following sub-questions, listed here alongside a short summary. Do you need a clear mapping between processing purposes and corresponding legal bases? Yes, such a mapping is effectively necessary to satisfy your GDPR obligation to be able to demonstrate that all your processing activities are covered by a legal basis. If one legal basis doesn't work out, can you fall back to a different one? No. This is nonsensical considering how the individual legal bases work. However, it is possible that similar processing activities serve different purposes under different legal bases, and it can be worth evaluating different legal bases when trying to determine which one you should rely on. How should legal bases be presented in a privacy notice? While a Termly-style generic list of potential legal bases is common, there are good reasons to believe that this fails to achieve the GDPR's transparency goals. It is better to clearly associate each processing purpose with its legal basis. Appendix: positive examples of structuring a privacy notice Do you need a clear mapping between processing purposes and corresponding legal bases? Yes, the data controller must always have a clear understanding regarding which processing activity is conducted under which legal basis. Under Art 5 GDPR, personal data shall only be “collected for specified, explicit and legitimate purposes” and processed “lawfully, fairly and in a transparent manner”. “The controller shall be responsible for, and be able to demonstrate compliance with [these obligations]”. To be able to demonstrate that each processing activity is covered by a legal basis, it is necessary in practice to have a document that spells out the specific legal basis relied upon for each processing purpose. Some data controllers are formally required to maintain such Art 30 Records of Processing Activities (ROPAs), but keeping track of core information makes sense for all data controllers. The ICO writes in their guide on lawful basis for processing: You need therefore to keep a record of which basis you are relying on for each processing purpose, and a justification for why you believe it applies. There is no standard form for this, as long as you ensure that what you record is sufficient to demonstrate that a lawful basis applies. This will help you comply with accountability obligations, and will also help you when writing your privacy notices. It is your responsibility to ensure that you can demonstrate which lawful basis applies to the particular processing purpose. If one legal basis doesn't work out, can you fall back to a different one? Probably not. Processing for different purposes. In some cases, it will happen that data is processed for one purpose initially, and for another purpose under a different legal basis subsequently. For example, a web shop might collect payment information in order to execute a contract to buy goods. But once that contract is fulfilled, it is likely that the webshop will have to archive some of that information for multiple years due to legal obligations around financial recordkeeping. While in both cases the processing activity is similar (storage of the information), the purpose is different and so the legal basis can differ. In this context, it is useful to consider Art 6(4), which discusses when data that collected for one purpose can be reused for another purpose. This is possible whenever those purposes are “compatible”. Multiple legal bases for the same purpose. Some data controllers try to apply multiple legal bases to the same processing purpose, in the hope that some will stick. For example: We're showing personalized ads based on your consent. But if you decline consent we will show you personalized ads because we have a legitimate interest in making money. And if you object to the legitimate interest then showing you personalized ads is necessary for performance of a contract we have with you, namely in section 7(23)(f)(ii)(ξ) of our terms of service where “Service shall make reasonable effort to ensure that Content shown is relevant to User”. This doesn't work. Specifically in the case of consent, consent can only ever serve as a legal basis if the data subject has an actual choice. If the data controller just falls back to a different legal basis in case consent is declined or withdrawn, that choice is hollow. Similarly, having a fallback for legitimate interests makes no sense. The core aspect of a legitimate interest is that there must be a balancing test between the legitimate interests and the data subject's rights and interests. A legitimate interest can only serve as a legal basis if it outweighs the data subject's interests. A core factor here is whether the data subject can reasonably expect their data to be processed for the given purpose. Data subjects can object to the legitimate interests, which may make it necessary to re-run the balancing test taking into account the objecting data subject's individual circumstances. But it is quite possible that the legitimate interest still overrides the data subject's interests, so that processing can continue. On the other hand if the objection prevails, it is difficult to conceive a scenario where there could exist some fallback legal basis to continue despite the successful objection. Specifically for the issue of using Art 6(1)(b) necessity for performance of a contract instead of other legal bases, the EDPB has published guidelines 2/2019. They explain that whether processing is indeed “necessary” must be considered from the perspective of the data subject, so that many purposes like “service improvement” or advertising cannot be covered by this legal basis. Something does not become truly necessary for a contract just because it was unilaterally inserted into a terms of service document. Determining an appropriate legal basis. However, thinking in terms of fallbacks can be quite useful for determining an appropriate legal basis. In general, legal obligations or necessity for performance of a contract should be considered first, falling back to a legitimate balancing test otherwise. Consent is a choice of last resort when no other legal basis would apply, since consent can authorize nearly any processing activity, no matter how risky or disadvantageous to the data subject, if the consent was obtained in a valid manner. How should legal bases be presented in a privacy notice? The GDPR is slightly ambiguous here. Per Art 13(1)(c), your privacy notice must provide the purposes of the processing for which the personal data are intended as well as the legal basis for the processing It is possible to interpret this in two ways: you list the purposes of processing, and separately any legal bases that you may rely on for any purposes; or you list the purposes of processing, and for each purpose you also list which legal bases you rely on for that specific purpose. Providing an abstract list of legal bases. You very commonly see the first approach, that essentially just summarizes Art 6(1) GDPR for the convenience of the reader. This boilerplate approach is of course attractive for privacy policy generators that do not understand the context your specific processing purposes. While the relevant EDPB guidelines on transparency don't take a clear stand on this matter, I have doubts that this first approach is fully GDPR compliant. This fails to provide required transparency. The Art 13 and Art 14 information obligations are an expression of the Art 5 GDPR principles like “lawfulness, fairness and transparency”. Merely listing any potentially applicable legal bases does not make it transparent to the data subject what data is being processed under which rules. But knowing the legal basis covering a particular processing activity has direct impact on the data subject's rights such as the right to revoke consent, to object to legitimate interests, or to erasure. This fails to specify the actual legal basis. Such a generic listing might also fail to fully satisfy the conditions for certain legal bases. Where the legal basis is a “legal obligation”, it is not sufficient to generically refer to legal obligations in abstract. Rather, Art 6(3) says that The basis for the processing referred to in point (c) and (e) of paragraph 1 shall be laid down by: (a) Union law; or (b) Member State law to which the controller is subject. Thus, I would expect a fully compliant privacy notice to actually reference those laws, at least in a general sense (e.g. compliance with court orders, or for financial recordkeeping). Specifically in the case where legitimate interests are used as the legal basis, Art 13(1)(d) says that those legitimate interests shall be provided. Guidance from the EDPB WhatsApp decision. While the Transparency Guidelines linked above are not excessively helpful here, there is a body of regulatory interpretation for example in the form of the EDPB binding decision 1/2021 regarding WhatsApp. In section 5.1, it is discussed whether the WhatsApp privacy notice at the time satisfied Art 13(1)(d). Here, the EDPB quite unambiguously argues that only the second approach – per-purpose information – can be compliant. From para 56 and 59 in the decision: The EDPB is of the view, […] that providing full information on each and every processing operation respectively is the only approach that will ensure that the data subjects can: (a) exercise choice as to whether or not they might wish to exercise any of their data subject rights and, if so, which one(s); (b) assess whether or not they satisfy any conditionality associated with the entitlement to exercise a particular right; (c) assess whether or not theyare entitled to have a particular right enforced by the data controller concerned; and (d) assess whether or not they have a ground of complaint such as to be able to meaningfully assess whether or not they wish to exercise their right to lodge a complaint with a supervisory authority. […] The EDPB considers that in the Legal Basis Notice WhatsApp IE has not specified the provided information with regard to the corresponding processing operation such as information about what categories of personal data are being processed for which processing pursued under basis of each legitimate interest respectively. Practical impact. Termly's templates fall short of this standard, but their fine print also makes it clear that their service does not provide legal advice and that they aren't responsible for anything. It may also be worth considering that your privacy notices will likely face less scrutiny than WhatsApp, as in the decision cited above. That a very strict standard was applied to WhatsApp also has to do with Facebook's/Meta's/WhatsApp's history of playing games around appropriate legal bases and its extremely large user base, also involving children, making it very important to provide clear and comprehensive notices. Appendix: positive examples of structuring a privacy notice My suggestion would be to think about these transparency obligations in a tabular manner where you have an Excel sheet with columns for purpose, data involved, retention periods, and legal basis: purpose data retention legal basis personalized ads cookie identifiers, interest profile 6 months Art 6(1)(a) consent server security logs IP address 3 months Art(6)(1)(f) necessary for legitimate interest showing comments to other users username, comment until you delete the comment Art 6(1)(b) necessary for performing service ... ... ... Many data controllers will have exactly such information anyway when they keep Art 30 Records of Processing. Based on these records, it is then possible to write an accurate and understandable privacy notice that clearly relates processing purposes with other required information. I have seen privacy notices that use exactly such a tabular approach, though it's more common to provide a sub-section per purpose. For example: Purposes for which we process your personal data: Personalized ads. If you give consent (Art 6(1)(a) GDPR), we will show you personalized ads. For this we will set a cookie identifier (→ about cookies), and collect a profile of your interests based on the content that you interact with. The profile will be deleted 6 months after you last interact with our site. ... Showing comments to other users. When you post public comments, we will show them to other users. Providing this service is necessary to perform our contract with you (Art 6(1)(b) GPDR). The comment will publicly display your username, the date when you posted the comment, and the contents of the comment. The comment will be shown indefinitely, but you can delete it at any time (→ help center). Such an approach also fits well with a “layered approach” to transparency, where you split the information of the privacy notice across multiple pages, so that data subjects only have to read about those processing activities that are relevant to them. For example, an online marketplace company might have different notices covering browsing the listings on their site, buying a product, seller-side activities, and their employee recruiting processes. Another reasonably good approach I've seen is to have a section per aspect required by the GPDR, and to then provide a list that goes through each processing purpose. This is essentially a flattened version of the above table: Processing purposes: personalized ads server security logs showing comments to other users Legal basis for processing purposes: for personalized ads: your consent pursuant to Art 6(1)(a) GDPR for server security logs: our Art 6(1)(f) GDPR legitimate interest in ensuring the security of our services against hacks, DDoS attacks, or other criminal acts for showing comments to other users: Art 6(1)(b) necessity for performing our contract with you: showing comments is a core feature of our website, as covered by our terms of service (→ link). Which data is processed: for personalized ads: cookie identifiers, interest profile based on the content you interact with for server security logs: your IP address, a timestamp, and which pages you visit on our site for showing comments to other users: your username, date when you posted the comment, and the contents of the comment How long your data is kept: ...
Is it GDPR compliant that I can't access the account that I created and the personal data that I shared because "I haven't completed their internal pre-qualification process"? Article 15 defines a “Right of access to the data subject” but it's difficult to see how this could be construed as a right to log into a specific website. Common sense suggests this would be a very bad idea. If they are willing to provide the data through another means (say a report or data dump of some sort), the obligation would seem to be met. In fact, article 15(3) even states that data controllers should merely provide the information in a “commonly used electronic form” (i.e. not necessarily through access to their systems or whatever form they are using internally for the processing). Have you asked for that and would you be satisfied by that resolution? Is it GDPR compliant that their answer to my deletion request is "We will delete the data..." The text of article 17 (right to erasure) explicitly specifies that such a request must be honored without “undue delay”. Article 12, which defines some of the modalities for the rights to access, rectification or erasure by the data subject, also provides that controllers shall “provide information on action taken on a request […] without undue delay and in any event within one month of receipt of the request”. You haven't provided any time frame and I don't think there is anything wrong with acknowledging the request by promising they “will” do it but in light of article 12, it seems you would indeed be entitled to know once they have actually taken further action. However, you implied you might want to access the data first and it's not clear to me whether you explicitly invoked the GDPR in earlier communications. So I would clarify and reiterate my request (access or erasure) and ask them for explicit confirmation once it has been satisfied.
european-union (germany, spain, uk) The cookie consent law is the ePrivacy directive, which was implemented as national laws by all EU member states (including, at the time, the UK). Later, GDPR changed the applicable definition of consent so that implicit consent is no longer allowed. A notice in fine print as in the given example is not sufficient to meet this definition of consent, so any non-necessary cookies set in that context would be a violation. But it would be the national ePrivacy implementation that would be violated, not the GDPR. Thus, the GDPR's famous 4%/EUR 20M fines are not relevant here. Instead, each country can set its own fines. In Germany, this would probably be up to EUR 50k (§16 TMG) though German law doesn't implement this aspect of ePrivacy correctly. In the UK, PECR penalties are determined by more general data protection penalty legislation. Notable instances of cookie consent enforcement include the Planet 49 (ECJ judgement, German BGH verdict) case which basically affirmed that yes, the GDPR's definition of consent applies. Thus, any case law regarding GDPR consent is also applicable to the issue of cookies. Furthermore, the Spanish AEPD has issued an interesting fine due to insufficient cookie consent, but due to much more subtle violations than the outright disregard in the given example. E.g. in the Vueling action (decision (Spanish, PDF), summary, listing on enforcementtracker), the Vueling airline's website had a consent banner but ultimately told the user to reject cookies via their browser settings. This violates the requirement that consent must be specific/granular, since the browser settings are all-or-nothing if they're available at all. The airline was fined EUR 30k, the maximum possible under applicable Spanish data protection law. But what kind of risks would some blog run into that just sets cookies without appropriate consent? If the service is outside of the EU, enforcement is difficult. I am not aware of cookie consent enforcement against non-EU services. National data protection authorities can investigate the violation and issue fines, subject to their respective national data protection laws. They generally only do this when there are lots of complaints. Some authorities like the UK ICO have indicated that cookie consent enforcement isn't a priority for them. Independently, individuals can generally sue the service for damages. Some lawyers might send out cease and desist letters to non-compliant websites in the hopes of collecting fees. So aside from the last point, the risk is likely somewhat low, especially for a smaller site. At this point, it is worth reminding that ePrivacy/GDPR doesn't require consent for all cookies, and is not just limited to cookies. It is more generally about access to and storage of information on a user's device, unless that access is strictly necessary to provide the service explicitly requested by the user. Thus, functional cookies can be set without consent. However, consent does become necessary when cookies or similar mechanisms are used for analytics, tracking, or ads. Even though GDPR is involved, the cookie consent requirements apply regardless of whether the cookies involve any personal data.
Not legal advice - you should consult an attorney who knows your local jurisdiction. That's a general statement, but especially true here because the GDPR does not include personal liability for directors (or others) in the event of a data breach, but domestic laws may indeed do just that. The UK is one example where certain circumstances can lead to criminal liability for directors of a firm in the event of a breach. That said, your company should care. The fines for knowingly allowing a breach or not reporting it properly in a timely manner have been made more significant than the prior Directive. There are things you could do to potentially mitigate consequences in the event of a breach and a fine being levied on the company, such as aligning with best practices and getting certifications. In sum, the actual punishments for noncompliance will vary by jurisdiction, but any business that handles data in the EU should undoubtedly be ensuring it is aware of what, if any, obligations it has and taking steps to comply before May's deadline.
It may be legal or it may not For example, if any of the users are in the European Union, then the GDPR applies and the person storing the information is a data controller and has legal obligations. These include, having a legitimate reason for storing them, storing them only for as long as necessary for that reason, notifying the individuals that the data is being stored and why, deleting it upon a users request etc.
GDPR does not require consent. It requires a legal basis. Consent is only one legal basis among many. Some other legal bases are: legitimate interest (implying an opt out solution) necessity for performance of a contract If your customers pay you to deliver email updates, that contract is the legal basis for sending email updates. The only wrinkle is that as you describe your service, the emails aren't an essential part of the service. Alternatively, you might assert that there's a legitimate interest to deliver updates via email so that updates aren't missed. In that case you must allow the users to object, e.g. via ab unsubscribe link in the email and via their account settings. Because a prior business relationship exists, there's a strong case for legitimate interest – even if this were marketing emails (!). Legitimate interest requires you to balance the legitimate interest with the data subject's rights and freedoms though. Your updates are most likely not marketing, so any advice you might read relating to marketing emailings is irrelevant. GDPR applies because you are established in the EU. The regulation applies in relation to all your users, not just EU users. If and when Brexit happens you will still be covered by the Data Protection Act, which transcribes the GDPR's requirements into UK law. However, processing data from EU users will then count as an international transfer which requires extra compliance work, at least until the EU issues an adequacy decision for the UK.
GDPR seems quite clear that if you are recording calls, video and/or audio, you must get consent. Wrong. The GDPR requires that your have a legal basis for processing personal data. Consent is a legal basis but there are others. With respect to note taking, the GDPR only applies to “personal data wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system.” So, if they notes are not about an individual (and many B2B phone calls will not be) or are neither automated nor filed, the GDPR does not apply. If they are captured by the GDPR, you need to have a legal basis for the notes. Again, consent is one but it is not the only one.
The territorial scope of the GDPR is defined in Article 3. It covers "personal data of data subjects who are in the Union", whether they are EU citizens or not. So to answer your questions: 1) are EU users, but moved to USA a few years ago, and signed-up on my website? They are not in the EU, so are not covered. You don't need to know if someone is an EU citizen, just if they are currently in the EU. 2) went for holidays in USA, signed-up on my website, and then came back to EU? (note - potentially skipped any Consent questions at sign-up, because IP was from USA) If someone moves into the EU while using your service then they fall under the GDPR for the time they are in the EU. If their home address is in the EU then that is covered, and monitoring of their behaviour while in the EU is also covered. Your other two questions are about VPNs. If a VPN is used to evade IP address geolocation and you have no other clue about where someone is then you can't be blamed for not knowing where they are (although I'm not aware of any actual case law on this topic). But if someone with a USA IP address gives a home address in the EU then you should probably treat them as being in the EU to be on the safe side. Basically, if you don’t know if they are in the EU or not, you should treat them as if they were.