Responsibilities and GDPR reporting in case of hacked email marketing platforms Company A allows subscription to its newlsletter via email, and their email list and newsletter is taken care of by company X. So A is hosting the page where one can subscribe, X handles list and list building, subscription (double opt-in) and unsubscription and sending out emails, while A creates the content of these emails. A and X are both based in the EU. A has the following statement in their privacy declaration: (3) The personal data collected when registering for the newsletter will only be used to send our newsletter. Furthermore, subscribers to the newsletter could be informed by e-mail if this is necessary for the operation of the newsletter service or a relevant registration, as this could be the case in the case of changes to the newsletter offer or changes in the technical conditions. The personal data collected as part of the newsletter service will not be passed on to third parties, with the exception of the e-mail service provider (company X - address, France). An order processing contract has been concluded with the provider. Now my question: In case X would be hacked (or some other undesirable event occurs) and the email lists related to A show up in the Internet, then to my understanding X has to report to the data protection authority and has to deal with the issue. Is A also involved in this reporting? Or not at all?
It seems that A is the data controller and X is a data processor who processes personal data on behalf of A, and will only use the data as instructed by A. This will be formalized by a contract/data processing agreement per Art 28 GDPR, which is probably meant here by a “order processing contract”. The Art 33 GDPR responsibility to notify the supervisory authority in the event of a data breach lies solely with the data controller A, not the processor X. However, the processor X is required to notify the controller A “without undue delay”.
Well actually... I think you'll just need to wait a little more. I monitor the situation quite closely and I can tell you that it's just a matter of time. Microsoft was one of the first (if not the first) to communicate openly about the GDPR and the changes that follow. From the blog post: If your organization collects, hosts or analyzes personal data of EU residents, GDPR provisions require you to use third-party data processors who guarantee their ability to implement the technical and organizational requirements of the GDPR. To further earn your trust, we are making contractual commitments available to you that provide key GDPR-related assurances about our services. Our contractual commitments guarantee that you can: Respond to requests to correct, amend or delete personal data. Detect and report personal data breaches. Demonstrate your compliance with the GDPR. Microsoft is the first global cloud services provider to publicly offer you these contractual commitments. We believe privacy is a fundamental right. The GDPR is an important step forward to further clarify and enable individual privacy rights and look forward to sharing additional updates how we can help you comply with this new regulation and, in the process, advance personal privacy protections. Microsoft has set up an informational site on GDPR here. If your eyes are on any other provider, I think the only way to learn more is getting in touch and inquiring about their progress and process. Hope this helps.
If the website containing the GDPR-wall processes any personal data of users who hit the GDPR-wall, the GDPR applies to that website. This can be as simple as writing a logfile of all visits to the website. In this case it will be illegal if the website owner does not comply with the GDPR. However a supervisory authority would probably not spent any time on such a minor violation. As long as the the website with the GDPR-wall does not process any personal data, the GDPR does not apply, so nothing in the GDPR can forbid the GDPR-wall. Some related remarks: The GDPR does not require a "privacy policy" on the website if the website does not process any personal data. If personal data is processed based on consent, that consent must be freely given. Also it may not be disruptive. So a cookie wall asking for consent would be illegal. But the GDPR does not care about any other disruptive popups, as long as they are not related to asking for consent. Using GeoIP is a perfect way to implement such a GDPR-Wall, because it would block everyone from within the EU, but nobody else. So it blocks exactly those for who the GDPR would apply. In such a case it would not be reasonable to expect anything more from a website owner. A user which uses a proxy, can not expect to be protected by the GDPR, because it bypasses a restriction set by the owner of the website. A webserver does use the IP-address of all incoming requests, to send the reply back. That could be considered a processing of personal data, but everybody seems to agree it is not. I am not sure why. But I do agree that it would be very impractical if that is considered processing of personal data. I added an example from the Washington Post So you have to pay $9/month for a GDPR compliant subscription. Because the price you have to pay is not unacceptable high, I think it would be valid to offer the premium version this way. This does not force you to choose one of the other subscriptions. In december 2018, the Austrian DPA (DSB) has confirmed that a similar offer is lawful. On derstandard.at you get a choice between free access with tracking and advertising, or pay 6 Euro/Month for tracking free access. Because 6 Euro/Month is cheaper than subscribing to the printed edition, the DSB accepted that as a valid choice. More information can be found on noyb.eu or, (with more details but in German), on wbs-law.de.
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.
You could certainly allow twitter to delete the exchange, unless it is part of some record that the law in the relevant country require to be retained, which would be quite unusual. That would depend on the nature of the exchange, and the particular law requiring that records be retained. However, if the request is to be able to demand that Twitter delete the exchange, that would be much harder. In general a person or business is entitled to retain copies of communications, such as emails, sent to that person or entity. There is the &quot;right to be forgotten&quot; which applies under EU law, but that would not apply to records which a business needed to retain for its own legitimate purposes, and was not posting publicly, as I understand it. In any case Twitter is not an EU business, so I am not sure if the right would apply at all. (Twitter has an office in Amsterdam, so teh GDPR and other EU law clearly applies to it.) There might be some other basis on which such a demand could be made, depending on the detailed circumstances and the specific jurisdiction, but I cannot think of one offhand.
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.
Yes, this violates the GDPR if the user is in Europe. Data which is tied to a personal device can be tied to the person who owns it. From "What Is Personal Data" by the UK Information Commissioner's Office (ICO) (emphasis added): Personal data is information that relates to an identified or identifiable individual. What identifies an individual could be as simple as a name or a number or could include other identifiers such as an IP address or a cookie identifier, or other factors. If it is possible to identify an individual directly from the information you are processing, then that information may be personal data. If you cannot directly identify an individual from that information, then you need to consider whether the individual is still identifiable. You should take into account the information you are processing together with all the means reasonably likely to be used by either you or any other person to identify that individual. The bit about "all means reasonably likely" in the last bullet includes the kind of de-anonymisation tactics described in the NYT article. There are 6 lawful bases for data processing in the GDPR, and all processing must fall under at least one of them. (a) Consent: the individual has given clear consent for you to process their personal data for a specific purpose. (b) Contract: the processing is necessary for a contract you have with the individual, or because they have asked you to take specific steps before entering into a contract. (c) Legal obligation: the processing is necessary for you to comply with the law (not including contractual obligations). (d) Vital interests: the processing is necessary to protect someone’s life. (e) Public task: the processing is necessary for you to perform a task in the public interest or for your official functions, and the task or function has a clear basis in law. (f) Legitimate interests: the processing is necessary for your legitimate interests or the legitimate interests of a third party, unless there is a good reason to protect the individual’s personal data which overrides those legitimate interests. (This cannot apply if you are a public authority processing data to perform your official tasks.) Selling data isn't covered by any of the others, so consent must be obtained. Permission must be clear and positive, and you cannot predicate delivery of a service on the processing of data that isn't necessary for that service. So for instance you cannot say "You can use this service as long as we are allowed to collect and sell your data" because selling the data isn't necessary to the provision of the service. From "Consent" by the ICO: Consent requires a positive opt-in. Don’t use pre-ticked boxes or any other method of default consent. Explicit consent requires a very clear and specific statement of consent. Keep your consent requests separate from other terms and conditions. Be specific and ‘granular’ so that you get separate consent for separate things. Vague or blanket consent is not enough. [...] Avoid making consent to processing a precondition of a service. This applies to any processing of data about individuals within the EU, so just being an American company doesn't get you a free pass to ignore the GDPR if your app gets used by Europeans. The "Legitimate interests" basis is more problematic, in that the company collecting the data has to conduct a vague "balancing test" to determine if this basis applies. For direct marketing the ICO has written this, which says that direct marketing may be a legitimate interest, especially if you can show that the user has expressed interest in such adverts. For instance a location service which promises to tell you about nearby special offers would fall into this category. Against this, the impact on the user's privacy has to be considered, and location data is "special category data" because it can reveal medical information (e.g. hospital attendance) or religious affiliation (e.g. which church you go to). So unless the relationship between the recorded location data and the service is very direct its not going to pass the balancing test. The company would also need to distinguish between knowing the current location and keeping a record of historical locations; the two need separate justification. And of course nothing about this covers the sale of the data; this is considering a company which sells advertising space in it's app, not one that sells the data itself.
The GDPR actually does require you to follow DNT in Article 21: In the context of the use of information society services, and notwithstanding Directive 2002/58/EC, the data subject may exercise his or her right to object by automated means using technical specifications. I think this is quite explicit.