Does GDPR consent notification apply to access points intended purely for maintenance? Suppose I have a publicly available interface, intended to be used exclusively by me or my employees for the purposes of maintenance, e.g. an SSH server. Since I am processing user's IP address when they make a connection, does GDPR require me to notify the user of such an action in, say a banner shown upon accessing the server? Additionally, am I obliged to treat possible login attemps and the data entered as personal data? What if the interface processes user data, but its technology does not necesarily provide for a human-readable interaction, such as an ICMP response?
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.
The scope of the GDPR is entered when personal data is being processed in a structured manner. Personal data is any information relating to identifiable data subjects (definition in Art 4(1)). &quot;Peter attended the meeting on the 14th&quot; is personal data. &quot;That woman with the blue handbag said she wanted to return on the 25th&quot; is personal data. However, aggregate statistics do not relate to individuals, and are typically not personal data. &quot;On the 14th, we had 25 attendees&quot; is not personal data. Not all use of personal data is within the scope of the GDPR. For example, the GDPR would not apply if two organizers talk about who attended the meeting. However, Art 2(1) says the GDPR applies when personal data is processed wholly or partially with automated means (e.g. computers, smartphones), or forms a filing system or is intended for a filing system (e.g. keeping notes on attendees, keeping attendance lists) If GDPR applies, the organization would be responsible for ensuring compliance with its rules and principles, summarized in Art 5. Primarily, this means: having a clear purpose for processing selecting a suitable Art 6 legal basis for that purpose (e.g. consent or a legitimate interest) only processing the minimum data necessary for achieving that purpose determining and implementing appropriate technical and organizational measures to ensure compliance and security of the processing activities preparing for data subject rights, in particular by providing an Art 13 privacy notice when collecting data from the data subjects There are of course some complexities in the details. When the legal basis is &quot;consent&quot; (opt-in), the organization would have to ensure that this consent was freely given and sufficiently informed. Per Art 7(4), consent would not be freely given if that consent was a condition for access to the meeting. Using &quot;legitimate interest&quot; (opt-out) can be more flexible, but it requires performing a balancing test to show that the legitimate interest isn't outweighed by the data subjects' interests, rights, and freedoms. Roughly, relying on a legitimate interest is appropriate when the data subjects can reasonably expect the processing activity to occur. Regarding point 1, keeping general counts and aggregate statistics about attendees is probably OK since it wouldn't be personal data. If you are very conscientious about this, you could round all counts and use categories like &quot;0-4 attendees, 5-9 attendees&quot; for each facet, which makes it more difficult to make inferences about individuals. But the fundamental point is that all your data should relate to attendees as a whole, never to individuals. Regarding point 2 and 3, this is a question of legal basis. Since you gather names through informal conversations, I think that attendees would be weirded out if they learned that you kept detailed records on their attendance. So I think that you probably wouldn't have a legitimate interest here. However, being upfront with this and offering an opt-out could change this. On the aspect of keeping detailed notes on data from informal conversations, I'd like to point out H&amp;M's EUR 35 million fine back in 2020 (summary on GDPRHub.eu). In a callcenter, managers used to have conversations with employees. These conversations touched on anything from vacation experiences to health problems, marriage problems, and religious beliefs. All of that is fine. What was not fine is that the managers went full Stasi and kept detailed notes about all of this on a shared drive and used that information for management decisions. This went on until a configuration error made those files accessible to all employees. This violated all the points in the basic compliance process outlined above: the records had no clear purpose, no suitable legal basis, contained way more data than necessary (and even Art 9 special categories of data like information on health or religious beliefs which have extra protection), did not have appropriate measures to prevent unauthorized access, and did not fulfill data subject rights like the Art 13 right to be informed. In case this non-profit is a church or religious organization that had its own comprehensive data protection rules before the GDPR came into force in 2018, those can continue to apply per Art 91. This could probably address some issues of legal basis, but cannot circumvent the GDPR's general principles.
Your VPN scenario is why you have to show the banner to everyone. If you somehow knew beyond any doubt that someone was not in the EU, then you would not have to show a banner, but because you can't verify that, you should always show the banner. Doing so also protects against accidentally violating a similar law in another country; the GDPR is the best-known privacy law, but it is far from the only one. It's good practice to ask for people's permission before collecting their information anyway.
GDPR is not a blanket ban on the handling of personal data. It is a set of guidelines when and how data may be processed and stored. Documenting the compliance with a deletion request is one of many purposes for which some data may be retained after a deletion request. Others would be past contractual obligations, legal documentation requirements, and even a balance of 'legitimate interests' of the processors and the data subjects. The processor might be able to argue that fraud/abuse prevention is such a legitimate interest. What if I want to create a service that does let users enter their friends' email addresses, and send those friends an email invitation to the service? Get a specialist lawyer on staff who can check your exact business processes. A web site like this cannot possibly give you a full explanation of the pitfalls.
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.
There is nothing preventing the OP's &quot;subject&quot; from making a Subject Access Request in these circumstances From the British Transport Police's Privacy Notice page, under the heading &quot;How we use personal data&quot;: This privacy notice explains: ... the rights individuals have when we process their personal data. ... Right of Access: You can request access to the personal data we hold about you free of charge. You can request access to the personal data we hold about you using the contact details in this privacy notice. ... We collect personal data from a variety of sources, including: ... sound and visual images (e.g. from body worn cameras, CCTV, or facial recognition software); ... our own CCTV systems and body worn cameras. There's more detail in the link, which I have not replicated here to save space and avoid unnecessary &quot;noise&quot;, but the above should cover the relevant points raised by the OP
Nicknames, usernames, or gamer tags are definitely personal data under the GDPR. You are operating under a very narrow definition of “identifying”, which is understandable since the definition of personal data in the GDPR isn't overly enlightening at first glance: […] 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; — GDPR Art 4(1) However, this definition does show that “identifiable” should be interpreted rather broadly. For example, indirectly identifying data is still identifying data – there doesn't even have to be a strong identifier like a name, passport number, or street address. It is also not necessary that identification enables you to determine the real world identity – identification is anything that allows you to single out a person, or to combine data into a profile of that person (compare Recitals 26 and 30). In any case, an online username or user ID is clearly an identifier and will fall under one of “a name, an identification number, […] an online identifier”. If in doubt, ask your data protection authority for guidance. You've correctly understood that you will need a legal basis to process this data, and that legitimate interest could be that legal basis. This doesn't have to be your own interest, so a community interest would be OK. You need to balance the user's rights against this interest. You have performed this balancing and have found that the interest outweighs these rights. You've noted that such leaderboards are a cultural norm and are generally expected, which strongly weighs in your favour. However, legitimate interest is not a free pass but just means an opt-out solution (right to object per Art 21). You should also inform users that the leaderboard is accessible publicly when they join your server (transparency principle per Art 5(1)(a) as detailed by the information obligations in Art 13). In particular, you should use a “message of the day” or welcome message functionality to link to your privacy policy. You should also be aware that other rights such as the right to access, erasure, and data portability apply. As an alternative to legitimate interest (opt-out) you could also consider consent (opt-in), though this results in slightly different data subject rights and is more difficult to do correctly. But I'd agree that legitimate interest is more appropriate here.
Article 4(11) says: ‘consent’ of the data subject means any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her; Recital 32 says (my emphasis): Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject’s agreement to the processing of personal data relating to him or her, such as by a written statement, including by electronic means, or an oral statement.2 This could include ticking a box when visiting an internet website, choosing technical settings for information society services or another statement or conduct which clearly indicates in this context the data subject’s acceptance of the proposed processing of his or her personal data.3 Silence, pre-ticked boxes or inactivity should not therefore constitute consent. ... At the time of writing, the most recent guidance on consent from the European Data Board says: The use of pre-ticked opt-in boxes is invalid under the GDPR