GDPR, email lists, a few email subscribers in the EU Situation: Say you are an organization that regularly sends out e-newsletter updates to an email list that has been curated over the years by people signing up at events and/or through online sign-up forms. You are based in the US and most of the members of your email list are in the US, but a significant plurality are from abroad and a substantial number of those individuals reside in the EU. The GDPR is thus triggered for you (meaning you must comply). Question: Does this situation trigger the GDPR obligations (for example, the rights afforded to data subjects, the steps taken to protect their data, etc.) for every member of your email list regardless of where they live/reside/are or just for those individuals on your email list who are in/live in/were in EU at the time they signed up?
Yes, it triggers the GDPR obligations Considerations: Can you surely identify those residing in Europe? In that case you should ask them to sign up again and confirm the consent. A lot of mailing lists are doing just that. Did they previously give consent and you can document it? If so, then you can argue that you have the required consent. Do you have business in Europe? If not then I don't think they would bother to go after you. You could just walk away from the fine. What other personal informastion are you storing? If you know who reside in Europe then you already have more info than just the email. The email address itself wouldn't be much of a documentation issue, SAR or Portability task.
This is a good question, as it raises an issue which places the controller's interest in providing a smoothly functioning customer sign up process against customers' right not to have their data leaked. Note that it is not necessary to consider &quot;enumeration&quot; here. Even just being able to check whether one person has a registered account raises the issue. The relevant provisions of the EU GDPR (or in the UK, the UK GDPR as defined in sections 3(1) and 205(4) of the Data Protection Act 2018) are (emphasis added): Article 4(2): 'processing’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction So, disclosure of the fact that a user has a registered account amounts to &quot;processing&quot;. Article 6(1): Processing shall be lawful only if and to the extent that at least one of the following applies: (a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes; (b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; (c) processing is necessary for compliance with a legal obligation to which the controller is subject; (d) processing is necessary in order to protect the vital interests of the data subject or of another natural person; (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Of these, only (a) and (f) are likely to be of any relevance: (a) is not too useful since it isn't feasible to design a sign-up system that depends on the user's consent (which they may not give). That leaves us with (f). As noted by the Information Commissioner's Office, &quot;Legitimate interests is the most flexible lawful basis for processing, but you cannot assume it will always be the most appropriate. It is likely to be most appropriate where you use people’s data in ways they would reasonably expect and which have a minimal privacy impact, or where there is a compelling justification for the processing.&quot;. The legitimate interest here would be that you need a sign up system which prevents duplicate registrations. Remember though that the processing has to be &quot;necessary&quot; for the purposes of the legitimate interest. One might argue that it is not since you could design the system to give the appearance of accepting the duplicate registration followed by sending an email to the account holder to inform them. On the other hand this will result in a less user friendly experience which could itself be a legitimate interest. Ultimately this is a balancing exercise and it is hard to say whether you have struck the right balance until someone complains to the ICO or the court and a decision is issued. The fact that the practice is widespread among well-resourced and large companies would tend to indicate that it is lawful albeit this is not conclusive in the absence of a court decision. I'm not aware of any cases involving this particular issue but would be interested to hear from others on this point. If the processing is unlawful then Article 18 is applicable: The data subject shall have the right to obtain from the controller restriction of processing where one of the following applies: [...] (b) the processing is unlawful and the data subject opposes the erasure of the personal data and requests the restriction of their use instead Where processing has been restricted under paragraph 1, such personal data shall, with the exception of storage, only be processed with the data subject’s consent or for the establishment, exercise or defence of legal claims or for the protection of the rights of another natural or legal person or for reasons of important public interest of the Union or of a Member State. In other words, the data subject could ask you not to disclose their registration status via the sign up page, and you would be obliged to comply with the request. Separately from the above points, in order to be lawful you must provide the data subject with certain prescribed information at the time when the data is collected. Of particular relevance here are the following items: Article 13(1): Where personal data relating to a data subject are collected from the data subject, the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information: [...] (c) the purposes of the processing for which the personal data are intended as well as the legal basis for the processing; (d) where the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party; So even if you conclude that the processing will be lawful you will have to give some consideration to the basis so that you can comply with the above provision.
Term 1 isn't going to hold up, but that is not a GDPR matter. It's just a matter of basic consumer protection law in the EU. You can't offload responsibility for your mistakes. Looking at 2, Dale M. already pointer out that it's now how the GDPR works. You are the Data Controller. X,Y and Z are Data Processors. Article 28(1) of the GDPR is in direct conflict with your disclaimer. You accept zero responsibility, the GDPR says you are fully responsible. That's the exact opposite.
You wrote: As far as I believe, it is permitted under GDPR to record and store non-anonymized web server access logs, as these can be useful for security reasons. True, Recital 49 GDPR: The processing of personal data to the extent strictly necessary and proportionate for the purposes of ensuring network and information security, i.e. the ability of a network or an information system to resist, at a given level of confidence, accidental events or unlawful or malicious actions that compromise the availability, authenticity, integrity and confidentiality of stored or transmitted personal data, and the security of the related services offered by, or accessible via, those networks and systems, by public authorities, by computer emergency response teams (CERTs), computer security incident response teams (CSIRTs), by providers of electronic communications networks and services and by providers of security technologies and services, constitutes a legitimate interest of the data controller concerned. This could, for example, include preventing unauthorised access to electronic communications networks and malicious code distribution and stopping ‘denial of service’ attacks and damage to computer and electronic communication systems. You asked: My question is whether this anonymization process counts as processing personally identifiable data under GDPR? IP addresses are personal data in some cases, so yes, you're processing personal data. Then, these anonymized logs will be fed into an analytics tool to provide stats on unique visitors, page hits, etc. These are purposes considered compatible with initial purposes according to Article 5.1.(b): Personal data shall be (...) collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for (...) statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’); As a matter of fact, you might be required to anonymize the data for those purposes, see Article 89.1: Processing for (...) statistical purposes, shall be subject to appropriate safeguards, in accordance with this Regulation, for the rights and freedoms of the data subject. Those safeguards shall ensure that technical and organisational measures are in place in particular in order to ensure respect for the principle of data minimisation. Those measures may include pseudonymisation provided that those purposes can be fulfilled in that manner. Where those purposes can be fulfilled by further processing which does not permit or no longer permits the identification of data subjects, those purposes shall be fulfilled in that manner. If I were to anonymize the logs and continue to use them exclusively for security reasons, would that change anything? No, you would be processing data in a manner compatible with initial purposes (ensuring network and information security). Or does it not matter what I do with them once they are anonymized? Yes, it does. If you're not using them for &quot;archiving purposes in the public interest, scientific or historical research purposes or statistical purposes&quot; then you're using them for purposes incompatible with initial purposes. You would need to find new legal basis for processing. does this extra anonymization process on top then take it over the line meaning that consent and a privacy notice would be required? It depends on what you want to do with anonymized data. In your case, for security purposes or security and statistical purposes, you don't need the consent and there is no requirement for the privacy notice (but sure, it would be nice to publish one). For other purposes it might be different.
I'm not aware of any cases on point, but as a rule legal fig-leaves don't play well in court. If the webmaster simply puts up a banner saying that EU residents are not permitted but takes no other action to exclude them, then that is going to be considered irrelevant. The webmaster is still very likely required to comply with the GDPR. On the other hand if the webmaster takes other steps to exclude EU residents, such as using a geolocation service to block connections known to be in the EU, validating email addresses and blocking those from EU domains, and ejecting anyone who mentions that their residence is in the EU, then that is more likely to be seen as a good-faith attempt to avoid being subject to the GDPR. It will also have the practical effect of greatly reducing the number of actual EU residents. All these controls can be evaded, but it would be much harder for any data subjects to claim that they acted in good faith or that the webmaster acted in bad faith. Note that validating an email address or logging an IP is itself processing of personal data, so anyone implementing such a system still can't ignore the GDPR completely, but it would greatly limit the scope and make it easy to delete any such data after a short time. (Note: the term &quot;EU resident&quot; above is an approximation of the territorial scope).
If you are not processing the personal information of EU citizens yourselves then you are unlikely to be classed as data processors under GDPR (check Article 3: Territorial Scope, p.32-33). If you were to operate a Software-as-a-Sevice (SaaS) solution then you would be a data controller/processor (or both) and GDPR would certainly apply if you have EU citizens as customers/users. While I can't see any reference to software vendors in the GDPR text, as a software vendor it would be in your interest to ensure your products meet the criteria set out in Article 25 (Data Protection by design and by default, p.48) in order to help your customers to comply, such as: Implement appropriate technical measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects. Implement appropriate technical measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons. These along with similar organisational measures are the responsibility of the data controller, but unless your software helps them to comply they may be forced to consider alternative solutions which reduce their overall risk. If your software already has a number of such controls in place it may be worth putting a white-paper or similar communication together which can inform your customers of how your software helps them to comply. There does not appear to be any direct liability to the software vendor through GDPR. If a data breach is the result of a design flaw or implementation bug in the software and your customer gets fined as a result, they may be likely to pursue you on grounds of the software not being fit-for-purpose and lacking the appropriate technical controls required to ensure data privacy. In this event, your defence will rely upon records of designing and implementing controls, records of software testing and remediation, and having in place suitable procedures to ensure security patches can be quickly deployed to your customers when required. Further clarification as requested: If your organisation doesn't process the personal data, doesn't have any third parties process it on your behalf (includes hosting companies) or have any access to it ever, then you're neither a controller or processor. However, if your customers ever send you personal data or grant you temporary access to personal data as part of troubleshooting issues with your software, then you would be a processor in this context and would need an appropriate contract in place and would need to ensure the appropriate technical and organisational controls are implemented to comply with GDPR and reduce risk of a personal data breach. Additionally, if international data transfers take place as part of this (e.g. sending/accessing files over the Internet) you would need to ensure your organisation is able to provide an equivalent level of protection for the rights of the data subjects - for example if you are in the U.S. you would likely need to voluntarily join up to the EU-U.S. Privacy Shield or use the EU's Model Contract Clauses within your contracts in order for it to be legal for EU-based businesses to use you as a data processor. For more information about international transfers read the EU's Data Transfers outside the EU page. Ref: GDPR
The obligation to notify the supervisory authority (CNIL in your case) no longer exists. It was part of the previous regulatory framework, but it is not part of GDPR (which takes affect tomorrow). If you use CCTV that may monitor employees (i.e. they sometimes enter the HQ to consult with the owner), your obligations under the GDPR is basically to inform the employees that the CCTV cameras are there. I.e. Data subjects are entitled to understand when their personal data is being processed, covering the transparency aspect of processing. The use of CCTV must be communicated via signage which indicates the areas covered and instructions for further information.
The tricky bit from a GDPR standpoint is that the US has a law that says a US-based company must hand over data to US government agencies even if the data is stored outside the US. This is US specific and a case where the US government gives itself jurisdiction outside the US but the EU can't directly do anything against it (outside of international negotiations). As you noticed this means if you store data at a US data processor there is no real difference whether the data is physically stored in the US or the EU. So to avoid transferring EU consumer data to the US several steps are needed. First the servers have to be physically located in the EU and second the company needs to be non-US based, EU based seems the obvious choice. AFAIK constructions of a US-based company creating a fully owned EU-based subsidary are currently used to achieve the second part. Whether this is sufficient may have to be decided in court.