Never said that the information needed to be likely to cause harm, but simply can. The exact phrase that GDPR use is "Any information that relates to an identified or identifiable living individual".
An example where any information that related to an identified or identifiable living individual would be harmful would be in a court. Any information about juries, judges, accused or defendant is potentially harmful if abused. All legal systems depend on the presumption of privacy in this regard, and all legal system that I know have processes in places to replace individuals when that harm can be actualized.
A similar situation is possible when it comes to information being distributed to a very large audience. Unimportant "harmless" information can be perfectly safe in a small group, but if millions of people see it in a harmful context then such harmless information can turn harmful. Any person operating a forum, a voice chat group, or a place where any two people meet should treat any logs with the threat model of it being leaked and the information harming real people.
I should have clarified in the above comment that information that related to an identified or identifiable living individual should always be assumed as potentially harmful, and thus involving a risk to the identified person. This is the problem GDPR is mostly attempting to solve, and thus the situation for which the operator need to act on. Similar, if the information is of such nature that it can't be harmful, it is also very unlikely to be information that relate to an identified or identifiable living individual.
When GDPR came it a lot of people asked similar questions as the parent post. What about Apache logs? What about login credentials and sessions. What about CRM and customer registers? The collective answer from that conversation, as I remember (and much of those discussion can be found archived), was that the question depend on the context. If its purely for security then the operator can likely continue on as before per the above quoted section, with some caveats to proportionality. For most everything else, look to the purpose of the GDPR.
Never said that the information needed to be likely to cause harm, but simply can. The exact phrase that GDPR use is "Any information that relates to an identified or identifiable living individual".
An example where any information that related to an identified or identifiable living individual would be harmful would be in a court. Any information about juries, judges, accused or defendant is potentially harmful if abused. All legal systems depend on the presumption of privacy in this regard, and all legal system that I know have processes in places to replace individuals when that harm can be actualized.
A similar situation is possible when it comes to information being distributed to a very large audience. Unimportant "harmless" information can be perfectly safe in a small group, but if millions of people see it in a harmful context then such harmless information can turn harmful. Any person operating a forum, a voice chat group, or a place where any two people meet should treat any logs with the threat model of it being leaked and the information harming real people.
I should have clarified in the above comment that information that related to an identified or identifiable living individual should always be assumed as potentially harmful, and thus involving a risk to the identified person. This is the problem GDPR is mostly attempting to solve, and thus the situation for which the operator need to act on. Similar, if the information is of such nature that it can't be harmful, it is also very unlikely to be information that relate to an identified or identifiable living individual.
When GDPR came it a lot of people asked similar questions as the parent post. What about Apache logs? What about login credentials and sessions. What about CRM and customer registers? The collective answer from that conversation, as I remember (and much of those discussion can be found archived), was that the question depend on the context. If its purely for security then the operator can likely continue on as before per the above quoted section, with some caveats to proportionality. For most everything else, look to the purpose of the GDPR.