Where is the line between transactional vs marketing emails with GDPR? If a company that offers a product where the user logs in, such as a SAAS product, and they send emails with certain intentions, where is the line drawn between a transactional and a marketing email? Some seem pretty obvious, such as Buy my product - Marketing Here is a coupon to buy stuff - Marketing Password Reset Email - Transactional Policy or Terms have been updated - Transactional You have been given administrative rights - Transactional Your coworker has invited you to this platform - Transactional But there are other reasons for sending an email that are not as clear, such as: You have not logged in for a few days, come back Check out this new feature (encouraging people to use the platform) Welcome to the system, here is how to get started Here is a report of your activity on our platform for the last month You are halfway through your goal, keep going! Where would these other kinds of emails fall under, transactional or marketing?
You have not logged in for a few days, come back Marketing in the way it is formulated. Transactional only if it is mandatory for the contract, such as a reminder that the service is due to end. Check out this new feature (encouraging people to use the platform) Marketing. Welcome to the system, here is how to get started Transactional, it is like giving the Handbook to a device. Here is a report of your activity on our platform for the last month Transactional, possibly mandatory for some services anyway (banking) You are halfway through your goal, keep going! Marketing in most cases (if goal is set by the company), but can be transactional if it is a service for tracking your own progress. The Rule of thumb is: Whenever you want the user to do something, it's most likely marketing. Whenever you inform them of something that has happened or will soon, it's most likely transactional.
The GDPR consists largely of principles instead of concrete rules. It's possible to reasonably believe that you are fully compliant, but then have a court rule against you. Thus, a company might mitigate risks by getting experienced compliance consultants, and by not toeing the line of what is and isn't allowed. But at some point, working to reduce the remaining risk is not worth the effort. This will depend very much on the business. E.g. an adtech business will likely want to tolerate more risk than a bank. As the interpretation of the GDPR evolves, compliance efforts must adapt. For example, the Schrems II judgement that invalidated the EU–US Privacy Shield shifted our understanding on the legality of international transfers. This judgement was not necessarily surprising for anyone who paid attention, so to some degree it was possible to prepare in advance. But that judgement was the kind of shift in jurisprudence where you can't fix your compliance by filling out one extra form, but rather have to rethink all international transfers of personal data – a blow to US SaaS providers and European SMEs that depend on them. Some parts of the GDPR are geared to assist with a compliance process. For example, larger data controllers must create a Records of Processing Activities (ROPA) register. This lists all processing activities and their legal basis, which helps spotting potential compliance gaps. Risky processing activities require an Impact Assessment (DPIA) where the controller has to weigh different factors against each other and determine appropriate safeguards. While the GDPR doesn't necessarily say whether something is allowed or not, it frequently provides factors that must be considered in an analysis. In addition to the GDPR itself, there's a lot of guidance available. Data protection authorities publish guidelines and can also be consulted directly. In fact, that's sometimes explicitly required. In the EDPB, the different authorities coordinate with each other and publish a series of EU-wide guidelines. Sometimes the subject is very specialized, sometimes the guidelines touch on a very general matter such as the concept of “consent”. These guidelines are an effectively–binding interpretation and thus bring welcome clarity to a compliance process.
If person A deletes their account would that mean that person B no longer can view the email sent by person A? No. Person B's inbox implies overriding legitimate grounds that limit person A's &quot;right to be forgotten&quot;. See article 17.1.(c) of the GDPR. Furthermore, item 2 of article 17 is not applicable because the email service did not make A's personal data public. The email service merely sent to B the record with which A unequivocally addressed B. This means that the email service does not even need to notify B regarding A's request for erasure. All the email service needs to do is remove A's account pursuant to A's request.
Do these warnings have any legal force? In the United States, no. They do not have any legal force. Some have tried to argue that the Electronic Communications Privacy Act (ECPA) applies; however, this law only applies to intercepting e-mails—not accidentally sending to the wrong party. There is no legal protection for "reply all" or "accidental send" human errors. If so, what are their consequences? If you're asking why some people put them in there, even if it's not legally enforceable, one reason is lawyers trying to prevent an accidental waiver of attorney-client privilege. Generally, a waiver of the attorney-client privileged must be intentional and knowing. Therefore, some argue that a disclaimer could help one argue that privilege was not waived. Although, I could not find a published case where an e-mail disclaimer actually helped this argument. Additionally, placing the e-mail disclaimer on the bottom of an e-mail (which is customary) is less effective than placing one at the top. As a note, some legal commentators and ethics committee's suggest that lawyers should use encryption "to ensure the confidentiality of such communications remain so when the circumstance calls for it, particularly if the information at issue is highly sensitive and the use of encryption is not onerous." See Legal Productivity's Post that quotes a California Ethics Opinion For more info, read this article here from the American Bar Association's Litigation Section regarding the efficacy of E-mail disclaimers: Do Email Disclaimers Really Work?
Your confusion might be caused by the fact that even with a contract, only the data necessary for that contract is covered under the GDPR. So yes, while there might be an &quot;execution of contract&quot; under the T&amp;C, this would only cover necessary data. That means you can't ask arbitrary signup data under the guise of a contract. If you need to deliver a physical product, you can store a physical address. If it's an online service, you can store an email address or similar handle. But you can't mix the two. A physical address is unnecessary for the execution of a contract that's not physical in nature. Now, you mention &quot;consent&quot;. Under GDPR, this is a distinct justification besides &quot;execution of contract&quot;. You might have consent to store a physical address in addition to an online address, e.g. if you offer a customer to physically mail a password request form. This consent is additional to the contract. Also note that the bit above only covers the lawful reasons for the processing of personal data (article 6). You also have to obey the other GDPR rules, e.g. fully inform the user, make sure that consent is freely given, etc.
If you process any personal data, you do need to provide notice to the data subjects per Art 13 or Art 14 GDPR. Personal data is any information relating to a (directly or indirectly) identifiable natural person. It seems you are processing personal data including as addresses, PayPal accounts, and IBANs. Thus you're in scope of the GDPR. The GDPR does have an exception when data is processed for “purely personal or household purposes”, but that very likely does not apply to you. The German Datenschutzkonferenz (DSK), a cooperation of the German supervisory authorities, has published a handout on information obligations, listing which information has to be provided in a privacy notice: https://datenschutzkonferenz-online.de/media/kp/dsk_kpnr_10.pdf Such a privacy notice can be fairly short if you're don't doing anything special, in particular if you only use the data as necessary to fulfil the sale contract and then as legally required (e.g. for keeping financial records). There are privacy notice generators that can help with the boilerplate, but be aware that some are significantly outdated, and that in any case you have to fill in the information about your concrete processing activities. You have guessed correctly that you will need to inform your customers about your data retention periods. Your privacy notice will get more complicated if you also want to use this data in other ways, for example for marketing purposes. That would also require you to think about appropriate legal bases (e.g. legitimate interests, or consent).
You are right that a visitor of a website does not expect to be tracked upon opening the website. But when using Google Analytics configured in the way explained in my other post, the visitor is not tracked. At least not in a way which violates the GDPR. You worry about the cookies. I also found this article which also does and suggests to either: change the _ga cookie to a session cookie, so it will be removed when the browser is closed. To do this, set the Cookie Expiration variable in your Google Analytics Settings to 0. completely disable cookies. (GA does not require cookies). To do this, set the storage field to none: ga('create', 'UA-XXXXX-Y', { 'storage': 'none' }); If you do not disable cookies, cookies can be used for tracking, which is more general defined in the GDPR as profiling. Profiling is defined in Art. 4 GDPR as: ‘profiling’ means any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects concerning that natural person’s performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location or movements; Art. 22(1) GDPR disallows profiling. Therefore in the settings menu from Google Analytics you have to disable data sharing and data collection. So data will only be used for the analytics function. But because you have configured to Anonymize your visitors IP Address, the part of the IP address used for this, is no longer considered personal data. This is because approx. 250 other users share the same part of the ip address which is stored, so data is not distinguishable between those 250 users. The anonymisation used by google is currently considered good enough. At least by the Dutch DPA. This might change if someone proves it is not good enough anonymized. Note that I am not a lawyer either, but I have read from multiple experts that analytics can be a "legitimate interest", the same way marketing can be a legitimate interest. This way configured the privacy impact is considered very low. It is also very important to note that a DPA consideres GA Google Analytics compliant. Even if a court would not agree in the future, you are acting in good faith if you follow those instructions, so you will probably not be fined. The DPA does currently not suggest to change the _ga cookie to a session cookie, or disable cookies completely. Note that the GDPR does not require doing anything to make it technical impossible to track someone. If a website has access to the data to track someone, but "promises" not to do that, that is fine. And rules regarding the usage of cookies in general, is not part of the GDPR, but (currently) part of the ePrivacy Directive. Only the way to ask for consent for storing cookies is defined in the GDPR.
Congrats, you've done well to minimize your processing of personal data. But I think you're still processing personal data, and are subject to the GDPR. Serving a website necessarily involves processing an IP address. This IP address will typically be personal data. While you are not storing the IP address, the GDPR's definition of “processing” extends beyond storage and pretty much covers doing anything with that IP address. As far as I know this is not an entirely settled matter, but it's better to err on the side of caution and to assume that you are in fact performing a processing activity. Even a static web page can easily lead to additional relevant processing of personal data, for example if the HTML embeds resources from third party domains. Since your website is clearly targeted at the public, it does not fall under the GDPR's exception for “purely personal or household” purposes. So I think you do need a (minimal) privacy notice that contains at least the items mentioned in Art 13 GDPR. The main reason why some people try to avoid posting a privacy notice is because it must disclose your identity and contact details. But in Germany, that information has to be provided anyway due to the Impressumspflicht. As part of your GDPR compliance obligations, you must protect how data is processed by others on your behalf. A hosting provider will typically act as your data processor. For this to be legal, you need a contract / data processing agreement that fulfills the conditions in Art 28 GDPR. This contract binds the data processor to only use the data as instructed by you, and not for their own purposes. European hosting providers sometimes include the necessary terms in their terms of service / AGB, but you should check to make sure. Netcup expects you to accept their data processing amendment in your account settings. In the hypothetical case that you were not processing any personal data at all, the GDPR would not apply and it wouldn't require you to post a privacy notice. Other laws might still have information obligations, notably the German TMG and TTDSG.