What counts as personal data under GDPR? As a developer of software intended for use by EU citizens, I am committed to complying with the personal data requirements of the forthcoming legislation (EU Regulation 2016/679). There is a definiton in Article 4 (1): ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person; In my opinion, the above definition is pretty wide and the directive texts are quite heavy. I would like to see a definition/list of examples of relevant personal data that software engineers and developers would find usable when developing software intended for use in the EU. I hope this question is not regarded too wide. I consider it to be a practical problem and hope for great answers.
The answer is right there in the quote: any information relating to an identified or identifiable natural person So if the data can in any way be tied to a specific individual then it is personal data. Note that you have to consider the data collection as a whole - even if there are no names in your data, if there is enough info in it that you can work out who the individual is (or probably is) its personal data. Obvious things include names, dates of birth, physical addresses, electronic addresses, social media profiles etc. Less obvious things include job or profession, memberships of organisations, friends and associates, town/suburb etc. i.e. things that in combination can reduce the set of people it could be to a small number of individuals. Basically, if you collect and store information about individuals in any way you are caught by this regulation. Even an email address used for login is personal data in that it identifies an individual and tells a hacker that they use your software. Examples of what is not personal data includes information about judicial persons (companies and other organisations that are sufficiently large that individual information cannot be inferred) or properly anonomized data where the data set is sufficiently large that identifying any particular individual is highly improbable (several dozen people at least depending on how revealing the data is).
There is nothing extraterritorial about these laws. If a company sells a good or provides a service to individuals based in the EU, then this good or service has to comply with EU laws. This concept is self-evident for physical goods that are produced anywhere in the world and then sold in the EU and the GDPR just applies this concept to services provided over the internet. The same legal concept also holds in all other major jurisdictions. The only thing that makes this more complicated for the GDPR is the actual enforcability of these laws but that is a technical issue not a legal one.
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.
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.
No, you do not need to show a privacy policy just for running a publicly accessible server, as long as any traffic data such as IP addresses is only used as strictly necessary for providing the service requested by the user. The background here is that while GDPR is a very general law, the ePrivacy directive (ePD) provides more details for telecommunication and information society services, which also includes SSH servers. Per ePD Art 6, traffic data may be used (1) for the purpose of the transmission/service or when the data has been anonymized, (2) for billing purposes, or (3) for marketing or value added services, when the user has given their consent. Information about the processing is only required under ePrivacy for cases (2) and (3), but not for processing that is strictly necessary. Now the tricky question is under what circumstances you can log (failed) log-in attempts or use tools like fail2ban. One argument is that such measures are strictly necessary to ensure the security of the communication, but these measures are evidently not necessary for performing the transmission in the sense of ePD. There are a few ways to resolve this: necessity has to be interpreted more broadly, and security measures are indeed necessary. For example, ePD Art 6(5) mentions fraud detection, without authorizing it explicitly. an IP address is effectively anonymized in the sense of the ePD since you do not realistically have means for linking the IP address to any particular person. This is a fairly weak argument, but could be supported by GDPR Recital 26 which defines anonymous data. Counterpoint: IP addresses are online identifiers which are explicitly included in the definition of personal data in GDPR Art 4(1). an IP address is not just traffic data that falls under the ePD, but also personal data that falls under the GDPR. When the IP address is merely used to make a transmission, it is not processed as personal data and only ePD concerns apply. But when we process it to ban the IP, it is processed as personal data under a legitimate interest. This processing does not fall under any of the categories from ePD Art 6, so that only GDPR concerns apply. These include a requirement to inform the data subject about the processing at the time in accordance with GDPR Art 13, which could be satisfied by displaying a link to a privacy policy in the course of the login process. For a legitimate interest argument, it also depends on the expectations of the typical data subject. Since some security measures such as security logs are normal and should be expected, a legitimate interest argument is likely to be strong. I think this is the correct conclusion, even though the “it's not traffic data, or at least doesn't fall under the ePD” argument is quite weak. It hinges on the assumption that security measures are not “value added services”. This fits the intent of the ePD, but not the actual definition of value added services. In any case, you do not need to ask for consent unless you're required to obtain consent e.g. under ePD Art 6(3) or because your processing of personal data relies on consent as the legal basis per GDPR Art 6. It also has to be noted that ePD has no immediate effect, but has to be implemented by each EU member state in national law. These laws can provide more specific guidance.
Privacy against publication of criminal convictions has been considered in the High Court in NT1 &amp; NT2 v Google LLC [2018] EWHC 799 (QB), if I may run the risk of posting a legal citation myself. But note that the claimaints there are anonymized, as often happens in criminal trials as well. In some cases, the court may give an injunction against disclosing names or details, and can hand down both a public and a private judgement, with the latter being a restricted document that does have the identifying details. So this question could only apply to mentions of criminal process where the accused is actually identified. (And I think just saying &quot;R v Smith&quot; is not enough - the posted or linked text would have to give some identifying detail about which Smith it is, the nature of the crime, etc.) I have no qualms at all about talking about NT1 and NT2. The claimants brought a case against Google for making available information about their long-spent convictions, including on GDPR grounds although it took place just before the implementation of GDPR in UK law. Dealing with that argument under the prior legislation, the judge found that of the various exemptions claimed by Google, the condition The information contained in the personal data has been made public as a result of steps deliberately taken by the data subject. (found in the Data Protection Act 1998, Schedule 3, paragraph 5, implementing the Data Protection Directive that preceded GDPR) applied, because of a longstanding principle for criminal conduct. The idea is that (paragraph 111): A person who deliberately conducts himself in a criminal fashion runs the risk of apprehension, prosecution, trial, conviction, and sentence. Publicity for what happens at a trial is the ordinary consequence of the open justice principle [...] The same must be true of the details of the offending, and other information disclosed in open court, including information about himself which a criminal reveals at a trial or in the course of an application. The core principles are the same as the carve-out from defamation law for the fair and accurate reporting of criminal proceedings (paras 44-49). That &quot;made public&quot; condition can now be found in a slightly different context in the Data Protection Act 2018, Schedule 1, Part 3, paragraph 32, which mirrors Article 9(2)(e) of the GDPR for the purpose of Article 10: This condition is met if the processing relates to personal data which is manifestly made public by the data subject. Since this is virtually the same condition of European provenance, in the same context of surrounding rules, I think the precedent is a good guide. For courts themselves, law reports, and journalism or scholarship, there are other specific grounds to rely on. Individual Stack Exchange posters are surely covered under the general exemption for posting on social media in a private capacity, GDPR 2(2)(c) as interpreted through its Recital 18. For the site itself, as in the case of NT1 and NT2, there could well be a legal claim made about the inclusion of criminal conviction information in a posted answer. (In general, such a post, being free text, could contain all sorts of defamatory statements or other objectionable content.) The court would have to look at the competing interests and the level of harm. NT1 was not successful but NT2 was. The example scenario, where we are talking about a very brief mention of a criminal case, cited because it illustrates a legal point rather than because there's anything relevant about the person mentioned, is quite far from the grounds complained of by NT2. For NT2, there was a newspaper article in which he was &quot;quite inappropriately, portrayed as one of a rogues' gallery of serious criminals&quot; (para 188), eight years after the end of his sentence, and it was this that he wanted removed from search results. In particular, the academic exemption (para 13) seems strong, in the same way that it would be for a publisher of legal academic content. The test of &quot;substantial public interest&quot; does not apply, because this exemption comes through paragraph 36 in the case of criminal convictions; it's enough to show a reasonable belief that publication would be in the public interest. Google was not able to rely on the &quot;journalism&quot; version of this exemption (again, under the prior law) because they are a totally generic search engine for all kinds of data and purposes (para 100 of the 2018 judgement). The public interest test, and the accompanying &quot;legitimate interest&quot; for the data controller, do not seem too difficult in this example.
Yes If you are in the EU, or your players are in the EU and your service is targeted at some part of (or all of) the EU, then this pretty clearly falls within the scope of the GDPR. Such a service would be collecting data associated with natural persons. At least some of it would be made public along with an online identifier, and other parts would be processed and stored, even if disclosed only in anonymized form. (By the way it is a non-trivial task to anonymize data well enough that it is no longer persona data under the GDPR. But let's suppose yoru methods are good enough.) Under GDPR Article 6 the DC must have a lawful basis for such processing. If the basis is &quot;consent&quot; then the consent must be freely given, whch means giving consent may not be a condition of using the service. Under GDPR Article 13 a notice must be sent to the Data Subject (DS) when the data is collected from the subject, including some 11 items or categories of information about the collection process, the Data Controller (DC), the purposes of processing, the legal basis of processing (which the DC must define), who will receive the data, the data retention period, and various rights of the DS. Such a service must be prepared to respond to data access and data erasure requests, under articles 15-17, and data restriction requests under article 18. It must provide a method for a DS to easily make such requests. Other GDPR provisions may well apply in addition to these, but that is enough to show that such service is very likely to be within the scope of the GDPR, unless none of the DSs are present in the EU or the related market area.
Art. 15(4) GDPR says: (4) The right to obtain a copy referred to in paragraph 3 shall not adversely affect the rights and freedoms of others. If I was the controller in this situation, and I believed that this would endanger the students that have criticised the professor, I would base my argument for not complying on this. In addition, Art. 85 GDPR requires member states to: [...] reconcile the right to the protection of personal data pursuant to this Regulation with the right to freedom of expression and information [...] So you may be able to argue that the students posting messages are engaging in "processing for journalistic purposes and the purposes of academic, artistic or literary expression", depending on the laws of the particular member state. (edit: this could be difficult since you mention it is a private database). The second case seems just like the first in terms of GDPR, but may constitute defamation. Defamation (or libel) laws differ wildly in each country; he Wikipedia article on Defamation explains the situation in each member state in more detail. In the third case: if the professor submits a request based on the rights of a data subject other than himself, they don't need to comply. These requests need to come from the data subjects themselves, not just a random person assuming authority. (although I suppose it's possible for them to give power of attorney to the department head if they wanted to) Personal data and the rights that GDPR provides to data subjects always relate to a natural person, not an institution or a company.