Are server-logs reckoned as storing of personal data by website (GDPR)? Well, almost all website have IP logs in "/home/logs/" folder (which is stored by hosting's Apache web-server (or whatever), and not by my site CMS). Should I state that in our privacy policy?
It follows from case law from the ECJ, e.g. C‑70/10 (28 January 2010) and C-582/14 (19 October 2016), that IP-addresses are personal data. Since my interpretation of the case law differs from the interpretation offered by @Greendrake, I'll go into the relevant case law in a bit more detail than I did in my initial answer. TL;DR: Yes, IP-addresses in server logs are personal data and you need to declare IP-address logging in your privacy policy. As I said, we need to examine the case law I mentioned in the introduction to find out whether IP-addresses are personal data. The first of those are ECJ C-70/10. In this, the court concludes that all IP-addresses are "protected personal data": It is common ground, first, that the injunction requiring installation of the contested filtering system would involve a systematic analysis of all content and the collection and identification of users’ IP addresses from which unlawful content on the network is sent. Those addresses are protected personal data because they allow those users to be precisely identified. (my emphasis) Then, in 2016, the ECJ ruled in a more narrow case ECJ C‑582/14 specifically ruling on dynamic IP-addresses: The court goes through a number of deliberations, then concludes: Having regard to all the foregoing considerations, the answer to the first question is that Article 2(a) of Directive 95/46 must be interpreted as meaning that a dynamic IP address registered by an online media services provider when a person accesses a website that the provider makes accessible to the public constitutes personal data within the meaning of that provision, in relation to that provider, where the latter has the legal means which enable it to identify the data subject with additional data which the internet service provider has about that person. It is very clear from this text that the court does not challenge or invalidate ECJ C-70/10 on static IP-addresses. The court is very careful, in its ruling to point out its ruling is specifically about dynamic IP-addresses. So the ruling of ECJ C-70/10 still stands for static IP-addresses, these are always protected personal data. I believe this case law is summarized in Recital 30 of the GDPR. This recital lists the identifiers that may make natural persons identifiable: Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. (my emphasis). Since it follows from case law that static IP-addresses always makes the data subject identifiable, and dynamic IP-addresses may make the data subject identifiable, I will conclude, based on jurisprudence alone, that: Unless you are able to filter your logs to exclude static IP-addresses. I think you must consider IP-addresses protected personal data under the GDPR. However, in ECJ C‑582/14, the ruling about dynamic IP-addresses hinges on the controller having legal means to identify the data subject by connecting the IP address to some other data. The court seems to think that getting access to ISP logs is the only means of doing that. This is wrong. In 2015, the Norwegian computer scientist Einar Otto Stangvik identified 78 Norwegians who seem to have downloaded abuse material starting only with their IP-addresses. Stangvik did this while working as a consultant for Norway's larges newspaper VG. I know Stangvik and I am familiar with the methods he used. I've tried them myself, and they work. Stangvik did not have access to ISP logs, he did not do anything illagal, and the 78 natural persons identified only by means of their IP-address, combined with other data the Stangvik had legal access to. I will not go into details, I will just say this: If you know how to do this, getting to the natural person when you know the IP-address is not difficult or labour-consuming. To return to the question: It also follows from the GDPR that logging of IP-addresses falls under its definition of "processing". Your privacy policy should list all personal data personal data that is collected by yourself and third parties ("processors" in the terminology of the GDPR) that you rely on. Your hosting company is such a third party, and you need to declare the logging of IP-addresses in your privacy policy.
See Art. 17(2) GDPR: Where the controller has made the personal data public and is obliged pursuant to paragraph 1 to erase the personal data, the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure by such controllers of any links to, or copy or replication of, those personal data. So the controller must tell all other controllers (like google) to delete the data. The privacy policy must include the fact that data is made public.
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.
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.
I think that one cannot answer a question such as "Will the personal use exception in the GDPR apply to personal blogs?", because it is unclear if you refer to: personal information published on the blog pages personal information collected from the Website, by way of forms, cookies, server logs, strictly collected and processed for the purpose of operating the Website for your own personal purposes as a blogger (by yourself of through a subcontractor in the sense of GDPR) and not personal information collected from the Website's operation, transferred or provided to third parties for their own purposes (this would include cookies used to identify and track users across multiple domains) Regarding 1., a personal blog wanting to benefit from the exemption should not publish third party's personal information without their consent or another legal basis, and C-101/01 certainly applies here. About 2., if the information is strictly collected and used for the own personal purpose of the operation of the blog, I would tend to agree that it should benefit from the exemption. I feel that C-212/13 would not necessarily be an indication that because the blog is publicly accessible it is then "directed outwards from the private setting" in the sense of this ruling, and should not be considered as "purely ‘personal or household’ activity". C-212/13 case was relating to a camera installed by an individual on his family home for its own security purposes which was also monitoring a public space. The persons filmed on this public space had absolutely no direct connexion with the person collecting their images. In case of a blog, the visitors of the blog interact with the blog for fulfilling the own personal purpose of the operation of the blog of the publisher of the blog. Another argument is given by the Recital 18 which you quote: a personal blog can be viewed as a type of social networking or related online activity. Finally, about 3., there is no doubt for me that, in this case, the publisher of the blog is engaged in an activity which is not personal, since it willingly provides personal information to third parties which they use for their own purposes (and not as subcontractors in the sense of GDPR). There may be other approaches apart from these 3, but that's a start for your considerations.
Yes, phone numbers would generally qualify as Personal Data under GDPR. It would be so irrespective of whether you have also stored other information along with the phone numbers or not, since also information that indirectly could identify a natural person is Personal Data (provided that there are, somewhere else, public or not public, a register of who holds the specific phone number). See Article 4(1) GDPR. (One could possibly argue that the phone numbers would not be considered personal data if there is no actual register of who owns a specific phone number with any other party. Or if such register is in practice not available for anyone. It might be so in some cases, although I would not rely on it.) Whether you have the right to process the phone numbers must be assessed based on its lawfulness (see Article 6 GDPR). It could be based on consent, performance of contract, legitimate interest or any other ground set out therein.
If you merely provide software for your client to use, you are not processing personal data on behalf of the client. But if you have access to systems that store personal data, then you must consider the GDPR. Or more accurately: your client must consider the GDPR. Under what legal basis can they give you access to the data in these systems? The easiest way to solve this is indeed if you act as the client's processor. Processor status is never the default, but requires a binding contract with the data controller. This contract will require you to only process personal data as explicitly instructed by the client, and may require you to take certain security measures as a precaution. Without such a contract you aren't a data processor, but possibly a data controller of your own (with all the compliance obligations that implies).
I think this shows a misunderstanding of the meaning of the GDPR. A data subject has the right to demand information, correction, deletion etc. about some of their data held by some institutions, depending on the legal basis for the data processing. One John Smith does not have the right to see the data of any other data subject named John Smith, and he cannot even demand to know if there are other John Smiths in the database. The data controller has to make reasonable steps to ensure that an individual who seeks account information is in fact the individual who is the data subject. In the case of an email, that's usually easy -- if John Smith can access the mail account jsmith@sample.org, one can assume that he is the John Smith who opened the account. If not, then not. If the data controller has the birthplace and birthdate in their records, they can possibly match that against some government-issue identity document, too, but why would they have that data?