How do email delivery services store users&#39; email addresses in a GDPR compliant way? Mailchimp, Twilio, Hubspot and other services provide apis to save lists of email-addresses and send them emails (marketing, technical, etc.). Even if a user asked to unsubscribe, those services will keep his email address in an &quot;Unsubscribed Users&quot; list. Anonymous users can also visit all kind of marketing websites, and fill other people's email addresses. In this case the &quot;Unsubscribed Users&quot; list is important, because if the email-address had been deleted completely, entering the victim's email-address again would re-add it to the marketing lists. How are these services compliant with GDPR and other regulations? They do keep email addresses of users that requested to unsubscribe, and those lists can even belong the EU citizens and maintained in remote locations (outside the EU). What if I want to create a service that does let users enter their friends' email addresses, and send those friends an email invitation to the service? Thanks!
GDPR is not a blanket ban on the handling of personal data. It is a set of guidelines when and how data may be processed and stored. Documenting the compliance with a deletion request is one of many purposes for which some data may be retained after a deletion request. Others would be past contractual obligations, legal documentation requirements, and even a balance of 'legitimate interests' of the processors and the data subjects. The processor might be able to argue that fraud/abuse prevention is such a legitimate interest. What if I want to create a service that does let users enter their friends' email addresses, and send those friends an email invitation to the service? Get a specialist lawyer on staff who can check your exact business processes. A web site like this cannot possibly give you a full explanation of the pitfalls.
This is possibly but not necessarily fine. The data controller (the garage) is responsible for safeguarding your personal data. They must take appropriate safety measures, but this depends a lot on their own risk assessment. For example, to protect the data from being used by employees for their personal purposes, the controller might use organizational measures like a policy “you're not allowed to do that.” Many companies allow employees to use their personal devices for work purposes (BYOD). When the data controller allows this and takes appropriate safety measures, everything is perfectly fine. The company still has to make sure that the data is only processed for legal purses and deleted afterwards. Implementing a BYOD policy in a GDPR compliant manner is difficult but not impossible. A data breach has occurred when the security measures were insufficient and your data was deleted or disclosed without authorization. Your scenario would only be a breach if the company did not have a BYOD policy and the salesman used their personal phone, and arguably then only if that device is also breached. However, do not discount the alternatives: they do have a BYOD policy and the salesman is acting within their instructions the salesman was using a company-controlled device, not their personal phone If you have good reason to believe that your data was mishandled (and these alternatives do not apply), then the GDPR offers you the following remedies: You can of course complain to the data controller, especially if they have a dedicated data protection officer. You can lodge a complaint with a supervision authority, which is the ICO in the UK. They expect you to attempt to resolve your issue with the controller first. The ICO can then decide if they want to investigate the issue. You can sue them for compliance and for actual damages suffered (you have none, though). Note that all of these alternatives are more effort than they are likely worth. In particular, the garage can always correct the problem, e.g. by getting your contact info deleted from the personal device or by creating a retroactive BYOD policy.
If you can’t stand the heat, get out of the kitchen The thrust of this question, as well as many others you have posted, seems to be looking for a way of avoiding your obligations under the GDPR because they are difficult, onerous and/or expensive. Too bad! You don’t have the option of which laws you comply with and which ones you don’t. If I had my choice, I’d comply with the GDPR and not with tax law, but I don’t so I can’t. You have 3 simple choices: Do your best and insure the rest. This means learning what’s required and implementing it to the best of your ability and taking out appropriate insurance cover to deal with any mistakes you make. Ignore the law and hope you don’t get caught. Don’t release apps.
The status of any PII (Personally Identifiable Information) is the same in GDPR regardless of location, or who enters it. Its goals are (among others) to stop any actor (company / government or other) from hiding responsibility about their use and practices around people's data. GDPR does even apply to anything offline and on paper. Basically it means you have to validate any entry field is free of PII before processing it. Or make it clear in your privacy statement how you handle this use-case.
I believe in this case, your company (OrgX) is a data processor and your customer's organization (OrgY) is the data controller. OrgY is responsible for establishing a lawful basis for sending you (OrgX) the personal data for their employees. Note that consent is just one of six lawful bases outlined in article 6(1). I'm no expert, but I believe OrgY's admin can claim they have a legitimate interest in sending their employee's personal data for training sake. In either case, the data processor is not responsible for establishing the lawful basis for processing. Of course, data processors aren't completely off the hook. GDPR outlines specific requirements for data processors (see chapter 4, particularly article 28).
The GDPR does indeed require that the password be stored "securely". It does not specify the technology which must be used for that purpose. Hashing the PW is a common method, and should be sufficient if properly implemented (strong hash function, use of salt, etc). But other methods of securing the password might be sufficient. Encrypting the PW rather than hashing it, so that an authorized person could decrypt it temporarily might be OK. Or perhaps a security app can separately retrieve only the specified characters of the PW through some sort of encryption. Or perhaps the ISP is not using proper security. In the case of Knuddles in the linked news story, an actual breach occurred which led to the poor security being reported. You could send a report to the appropriate national Data Protection Authority.
The CEO wants to "fool" users You are essentially admitting that the company you are working for is about to deceit its customers and asking whether that is legal. The relevant set of laws is rather sparse and does not give direct answers in regards to oAuth tokens or other details of that level (which is probably making your CEO think he can "handle" the arising questions). Probably the most relevant bit of legislation that applies here is The Federal Trade Commission Act (15 U.S.C. §§41-58) which prohibits unfair or deceptive practices and has been applied to online privacy and data security policies. I am pretty sure that, in practice, if the users take your company to court, it will be held liable because: users are allowing us to read their CRM data and once we get the data, the data become ours, and we can do whatever we want with it. Is this true? While the users are still allowing you to read their data it is completely up to the Terms/EULA what you can do with it. However, once you have made the users think that they have withdrawn your access (e.g. they "deleted" oAuth tokens), you are no longer authorized to read the current data (although the Terms may still allow you to use the old data you obtained when you had access). Silently continuing to access their data without their knowledge/approval is definitely a deceit. The CEO wants us to download all of their emails and store them in our database There would be nothing wrong with that if it was in the Terms. But if it is not, that would be a blatant (and easily punishable) breach of privacy. Note that you may also be held personally liable for this wrongdoing (if/when proved so). "Just doing your job" claim will not work.
Yes, there would still be an obligation to comply with erasure requests – if the data subject can be identified, and if the GDPR applies. This is a case for Art 11 GDPR: processing which does not require identification. The pastebin site is not required to collect identifying info just in order to facilitate later deletion. If the site is unable to identify the data subjects, then the data subject rights (like access, rectification, erasure, restriction, or data portability) do not apply. Other rights like the right to be informed and the right to object do remain, though. But if the data subject provides sufficient additional information that makes it possible to identify their records, then the data subject rights apply again. In practice, this is likely going to mean that anyone with access to a paste will be able to request deletion, since the site would have no ability to verify the identity of the data subject beyond the information in the paste. None of this absolves the site from implementing appropriate technical and organizational measures to ensure the security of this data. Even though the pastes might not be directly identifying, they are personal data and are far from anonymous. Common practices like numbering pastes with a sequential ID or showing recent pastes on a homepage have to be viewed critically. My go-to recommendation is to assign a cryptographically random UUIDv4 ID to the post, so that it is practically impossible for anyone to find the paste unless they were given a link by the uploader. Your idea to delete pastes after a fairly short retention period is also good. This helps with security, and it is in line with the GDPR's data minimization and storage limitation principles: data may only be kept as long as necessary for its purpose. On the other hand, quick deletion might not be in line with the purpose of these pastes – it all depends on context. You mention that this is an US-based site. If so, there's a question whether GDPR would even apply. GDPR will apply per Art 3(2) if the data controller is offering its services to people who are in Europe. Here, “offering” does not mean mere availability of the website, but that the data controller intends the service to be used by such people, in particular if the service is somehow targeted or marketed to such people.