How could a nonprofit obtain consent to message relevant individuals at a company on LinkedIn under the ePrivacy Directive? Suppose a nonprofit wishes to contact some EU-based employees of an EU-based company in an effort to get that company to use a free service it is offering, and is considering doing so via LinkedIn. Per Article 13 of the ePrivacy Directive - i.e. Directive 2002/58/EC: The use of automated calling systems without human intervention (automatic calling machines), facsimile machines (fax) or electronic mail for the purposes of direct marketing may only be allowed in respect of subscribers who have given their prior consent. And, per Article 2(h), 'electronic mail' would include social media messages such as LinkedIn messages: &quot;electronic mail&quot; means any text, voice, sound or image message sent over a public communications network which can be stored in the network or in the recipient's terminal equipment until it is collected by the recipient 'Direct marketing' is not defined in the ePrivacy Directive, but the UK Information Commissioner's Office gives the following guidance (my emphasis): Direct marketing is defined in section 122(5) of the Data Protection Act 2018 as: “the communication (by whatever means) of advertising or marketing material which is directed to particular individuals”. This covers all advertising or promotional material, including that promoting the aims or ideals of not-for-profit organisations – for example, it covers a charity or political party campaigning for support or funds. The marketing must be directed to particular individuals. In practice, all relevant electronic messages (eg calls, faxes, texts and emails) are directed to someone, so they fall within this definition. Genuine market research does not count as direct marketing. However, if a survey includes any promotional material or collects details to use in future marketing campaigns, the survey is for direct marketing purposes and the rules apply. From this, it seems that: (a) Prior consent would be required to send messages to specific individuals to promote the nonprofit's offering, including via LinkedIn. (b) A simple message asking if a person would be interested in learning more, or otherwise trying to obtain their consent, would itself be considered direct marketing, so itself require prior consent... If this is correct, how could the nonprofit legally contact the relevant stakeholders? I am confused about what should be done in this case. It seems very strange that a person at a company who might be interested in using the nonprofit's services cannot even be sent a one-line opt-in request to receive more details on LinkedIn. Any thoughts gratefully appreciated. Some solutions I have considered: Take advantage of the difference between 'corporate subscribers' and 'individual subscribers' in the UK's implementation of the ePrivacy Directive (PECR), which allows direct marketing to employees' corporate email addresses. Only applies to the UK and probably does not apply to LinkedIn. Phone the individual concerned to obtain consent prior to sending a message. Requires knowing the phone number and is time-consuming. Contact the company's official email address (e.g. info@company.com) instead. Impractical as reply rate is very low from such addresses.
You seem to have a solid understanding of the ePrivacy implications, but lack a fundamental insight: your organization does not have a right to achieve its mission or a right to disseminate unwanted marketing. But other people do have a right to not be subject to excessive marketing. Of course, reality is more complex, so it's probably not entirely impossible to do marketing. In your point 1, you note that some EU/EEA/UK countries distinguish ePrivacy protections between consumer and business subscribers. You can research the exact rules in the potential customer's country. This may allow you to email corporate/business accounts. I would strongly advise against messaging via Linkedin if there is a chance that the person is using that account for personal purposes like networking or hunting jobs, not just for conducting official company business. ePrivacy has markedly different rules for email marketing vs phone marketing. Whereas there are pretty strict rules for electronic messages and robocalls, manual cold calling can be OK from an ePrivacy perspective. However, many EU/EEA/UK countries have rules that go beyond ePrivacy, and may have a kind of do-not-call registry that you must respect. Of course manual calls take more effort than spamming emails, but recall the above point that you don't have a right to spam other people. Phone calls are probably the most appropriate approach when the company lists individuals' phone numbers on its website. This will at least give you a few seconds of attention with a real human, more than you can expect from an email that is likely to be caught by spam filters. Marketing via physical mail tends to have very lax rules. Note that every company/business that has a website will have to disclose its contact details including an address there, so this information is easy to acquire. However, chances are low that anyone would seriously engage with that marketing. You can consider alternatives to direct marketing, so that interested companies eventually come to you. Things like press releases, writing guest articles in industry publications, speaking at relevant conferences, working on search engine optimization, buying ads. On the GPDR aspects: GDPR and ePrivacy overlap, and it is necessary to comply with both sets of rules (GDPR likely applies here via Art 3(2)(a)). But where they potentially contradict each other, ePrivacy as the more specific law has precedence. For example, ePrivacy overrides the default GDPR legal basis rules when it comes to email marketing to existing customers (opt-out basis, no consent needed) or to using cookies (needs consent unless strictly necessary). Information that relates to corporations is not personal data, but information that relates to individual employees or to sole proprietors would typically be personal data. Since you are unlikely to obtain consent for using this data, you would need an alternative GDPR legal basis such as a &quot;legitimate interest&quot;. Relying on a legitimate interest requires that you conduct a balancing test, weighing your interests like marketing against the recipient's interests, rights, and freedoms. Core question in this context is whether the data subject can reasonably expect their personal data to be used like this, taking into account the nature of their relationship with you. Since there is no pre-existing relationship, claims of a legitimate interest are weak to start with. However, it may be possible to argue that when a company makes employee contact details available via its website (not LinkedIn!) then relevant marketing can be reasonably expected. I would rather not rely on such arguments, though.
Obtaining consent for cookies is not required by the GDPR at all. Instead it is covered by the e-privacy directive, which as a directive rather than a regulation, must be implements by specific legislation in each individual country. The exact requirements vary with the law of each country. An e-privacy regulation has been proposed, which would have scope similar to the GDPR, would replace the Directive, and would not require national implementing legislation. However it has not yet been adopted. Proposed versions have significantly different requirements than the current Directive. Nor does the GDPR require consent for advertising that does not involve the processing of personal information, unlike some other privacy laws such as the California CCPA. However, if the Google package sets cookies without consent that are not strictly necessary for operation of the web site, it might well fail compliance with some of those national laws implementing e-privacy. Also, even necessary cookies must be disclosed to the user, as I understand it, possibly only in general terms. Several national Data Protection agencies have said that cookie compliance is not a major priority, at least not until an e-privacy regulation is in place. But that does not mean that lack of compliance is legal. Unfortunately I see no way for a developer using the Google package to correct this issue within the package. One would either have to implement a different solution, or trust that Google will fix this before enforcement becomes a serious issue. However, the app developer could add a separate general cookie consent banner, and turn off all adds if consent is not given, I believe.
There are multiple issues with what you are trying to do, including issues with copyright, personality rights, and data protection. You are trying to use other people's content and likeness for your advertisement. Unless you are certain that you can do this in your relevant jurisdictions, without their consent, this sounds like a very bad idea. At least under GDPR, “but they made it public” is not an excuse. Personal data is personal data regardless of how you acquire it. The GDPR also has a very broad concept of identifiability that goes beyond direct identifiers or PII. If you want to use other people's personal data, you need a legal basis, and must provide them notice about your processing. Consent (informed opt-in) is one legal basis, legitimate interest (opt-out) another. You are suggesting to avoid this by blurring PII, but you may also have to blur other content that is indirectly identifiable. Real anonymization that meets the GDPR's definition is a really hard problem. In some cases, a legitimate interest is able to avoid such problems. E.g. if I make a video with commentary about a Tweet, it would likely be OK to show surrounding personal data like the responses including the identities of the various accounts, to the degree that this is relevant to the commentary and/or necessary for proper attribution. However, that commentary likely has strong protections under freedom of expression. At least from an European viewpoint, a tutorial, demo, or advertisement would not have a freedom of expression argument that would shift a GDPR legitimate interest balancing test in your favour. Instead of blurring almost everything in your video or working on GDPR compliance, content licenses, and release forms, you should consider a different solution: create dummy content just for your videos. You can use your own content, and maybe add a dummy profile.
If you have an agreement with a company that specifies &quot;you agree to give me something of value, in case I give you something of value&quot;, you have a contract. In order for there to be a contract, there has to be actual acceptance of the offer. You can put out on a web page some contract stating those terms, and if you get positive acceptance of the contract (hence the standard click-through technology), then as long as you have done the thing promised, you can bill them for doing the thing promised. It's not clear what thing of value you are offering on the web page, since it's not &quot;doing actual work&quot;. Them sending you an email isn't you doing something. One thing you could do is block all incoming emails, and for money you agree to unblock emails from registered subscribers. Just announcing that you will bill anyone for emailing you does not create a contract, because the emailer need not have even seen your announcement. This is why e-contracts need a click-through button. It's legal to request money, but there is no legal obligation for them to comply. That will be $10, please.
Legal framework Per Articles 4(1) and 4(2) of the UK GDPR, your email address is most likely personal data (and certainly is once you notify the data controller that it belongs to you), and the storage and use of that data constitutes processing. In order to process your personal data, the data controller must establish at least one of the six lawful bases set out in Articles 6(1)(a) to 6(1)(f). It's quite clear that none of those lawful bases apply in this situation. Hence, the processing is unlawful. Next steps Start by making a request to the data controller under Articles 14(1) and 15(1) for the following: A copy of all personal data (including the email address) which they hold in relation to you. The purpose of them holding the data. The legal basis on which they hold the data. That they erase all personal data which they hold in relation to you, pursuant to Article 17(1)(d) (unlawful processing of data). Per Article 12(3), the data controller is required to respond &quot;without undue delay&quot;, with an upper time limit of 1 month (or 2 months if they notify you of the time extension within 1 month). Sadly, most data controllers in my experience seem to interpret this to mean that 1 month is the standard time limit, even though technically this is incorrect and the standard limit is &quot;without undue delay&quot;. Pursuant to Article 12(6) the data controller can pause the clock by asking you for additional information if they have &quot;reasonable doubts concerning [your] identity&quot;. If you send your request from the email address in question then they can't really have &quot;reasonable&quot; doubts, but be aware of this possibility in any case and respond promptly to any requests to confirm your identity so that the clock resumes. Most likely they will be unable to (correctly) provide an answer to points 2 and 3 above, since they do not have a genuine purpose or legal basis. If, after the maximum deadline has expired, they have still not responded and/or erased the data, you have two options: Complain to the ICO under Article 77(1). The ICO has the power under Article 83(5) to fine the data controller up to the higher of 4% of their turnover or £17,500,000. Complaining to the ICO is free and easy and is usually recommended over option 2. Issue a claim in the County Court for a compliance order pursuant to Article 79(1) and Section 167 of the Data Protection Act 2018. You also have the right to claim compensation for &quot;material and non-material damage&quot; (including distress) pursuant to Article 82(1) and Section 168, but this may be unrealistic in the case of a few unwanted emails. Option 2 is not free: you will need to pay a court fee and, unless you represent yourself, legal fees. There may also be additional cost risks if you lose the case. Mentioning the above two points in your request could be an effective way to persuade them to comply in the first place.
Art 13 GDPR is about information to be provided when data is collected directly from the data subject. This information can be provided directly during/before collection. It is not generally necessary or useful to send the data subject an email with this information. Usually, a SaaS website will provide the information under Art 13 as part of their privacy policy, and link it in easy to find places. Also consider the EDPB guidelines on transparency, which suggests a layered approach: in addition to a detailed privacy policy, summarize key information directly when the data is collected, e.g. next to an input form.
As always, it depends. However, it is by no means certain that any public facing hobby project, such as a web app, is exempt from having to comply with the GDPR. Since the GDPR is only a few days old, we have of course no case law based upon the GDPR itself yet. However, when considering this, one should take the following two facts into consideration. 1. The "personal use exeption" in the GDPR is not new. The personal use exemption is unchanged from the article 3(2) of Directive 95/46/EC. (There as a lot of lobbying for removing "purely" from the sentence – but drafters wanted to keep it.) 2. Case-law under the previous regulation restricts the scope of the exception The ECJ has ruled on the scope of the personal use exception in two cases: C-101/01 C-212/13 In both these cases, the ECJ took an extremely restrictive view, and concluded that the personal use exemption did not apply to the processing done by these individuals. In C-101/01 it can be argued that the hobby project as a blogger was connected to the controllers professional activity (she was a catechist in a local church, and blogged about her work. including her colleagues). But in C-212/13, there no such connection to professional or commercial activity. Here, the controller operated a CCTV to protect his home, but set it up to also capture public space, and that was enough for the ECJ to decide that the personal use exception did not apply. Discussion Case-law based upon Directive 95/46/EC is in no way binding for a future court that need to rule based upon the GDPR. We need to wait for case-law decided under the GDPR to be able to have some degree of certainty about the scope of the "private use exception" under GDPR. However, given what we know about how the ECJ has ruled in these cases in the past, I think it is hazardous to think that just because what you are doing on the web is just a "hobby project" not connected to professional or commercial activity, you are exempt from complying with the GDPR. Conclusion IMHO, you may be exempt, or you may not be exempt. I think it really depends on your activity in your hobby project, and to what extent this project processes the personal data of other people than yourself.
I think you could count decline-events, but not track users who declined tracking. But I also think such information isn't useful for demonstrating compliance. Therefore, you should avoid storing extra data about people who do not give consent. When consent is required for analytics. The GDPR provides a general framework for processing personal data. The ePrivacy Directive (ePD) overrides this general framework when it comes to cookies and similar technologies related to accessing information on the end user's device. Per ePD, such access is only allowed when it is strictly necessary to provide the service explicitly requested by a user, otherwise consent is required. Thus, analytics cookies require consent and setting an analytics-declined cookie is strictly necessary. But this consent requirement relates specifically to storage cookies, not to collecting analytics data. Thus, you might have a legitimate interest in collecting data with cookie-less analytics, which could involve counting cookie-consent decline events. Unfortunately, most analytics systems collect very broad categories of data and cannot be limited to a necessary subset. Even such limited analytics (unless they are truly strictly necessary for operating the site) should support an opt-out. I don't think you could legitimately gather analytics about such opt-out events. GDPR audits. Your motivation for collecting statistics about consent-decline events is to be prepared for a GDPR audit. This is probably not necessary, but it depends. It might be useful to distinguish between internal/voluntary audits and data protection audits by the supervisory authority. You might voluntarily review your compliance to convince stakeholders that you're compliant, and such voluntary audits might be part of the appropriate technical and organizational measures a data controller has implemented in accordance with Art 24, Art 25, and Art 32 GDPR. You should collect any statistics you need for this purpose, e.g. to ensure that the opt-in rate looks realistic. But since you can set the parameters of this audit, it makes no sense to collect data “just in case”. Under Art 58(1), your supervisory authority can audit your data processing and can compel you to provide any information it requires. This is similar to how a tax authority can compel you to produce business records for auditing purposes. This is closely related with your general obligation to be able to demonstrate compliance with the GDPR (Art 5(2)). More specifically, the controller is required per Art 7(1) to be able to demonstrate that the data subjects have given valid consent, but does not prescribe how to demonstrate this. How to demonstrate that valid consent was given. For demonstrating that consent was given, there are no clear best practices. However, this topic is briefly discussed in EDPB guidelines 05/2020 on consent. They recommend that you retain records about the following: that a data subject in a given case has consented how consent was obtained when consent was obtained information provided to data subject at the time that the controller's workflow meets all relevant criteria for valid consent Some of these are process-level concerns about how you ask for consent. For example, you might record video walkthroughs of your consent management solution to demonstrate how consent can be declined, given, and revoked. You should definitely keep a version history of the text and information that was displayed to users when they were asked for consent. I think you should also be able to explain in your front-end code how the result from your consent management solution is used to load relevant features (and that they aren't loaded before consent is given). If a feature or service is made conditional on consent, it might be good to have a short written analysis that consent is still freely given under the requirements of Art 7(4). But other aspects relate to the individual data subject and the individual consent-giving event. Some consent management solutions send a small record about the consent to a backend server where it is stored with a timestamp, so that it can be later traced that and when consent was given. I've also seen consent management tools that show a timeline of events to the user (when consent was requested, and when consent for which purpose was given and revoked). I think such detailed insight into an pseudonymous individual's consent status is a very powerful way to demonstrate compliance. What is not relevant here is information about data subjects who declined consent in the first place. Consent means opt-in. The default is that no consent is given. To demonstrate that consent was obtained in a valid manner, information about data subjects who didn't consent isn't necessary or useful. So I expect that you would be fine in an audit without collecting such data. In fact, the lack of a clear purpose and necessity for collecting this data could be argued to be without legal basis and violate the GDPR's data minimization principle. And even when recording information about those data subjects who did consent, the EDPB guidelines remind us that this “should not in itself lead to excessive amounts of additional data processing”.