Storing IP&#39;s and GDPR Compliance Suppose a web designer plans to store hashed IP's in a database for analytical purposes of tracking unique clicks, and for security purposes to prevent botting unique clicks. Suppose the site only stores one-way hashes of the IP addresses, and only for as long as the data is needed. The plan is to allow Users can also contact the site to remove their data entirely. Would such a design be GDPR compliant? I've read a lot of mixed commentary on whether this type of use case would be allowed, and any sources to support your reasoning would be appreciated.
GDPR Article 4 paragraph 1 says: ‘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; Recital 26 says Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person. ... The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. Recital 30 says: 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. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them. An IP address hashed through a cryptographically secure one-way hash cannot reasonably be used to establish the original IP address, nor to geolocate, nor to directly identify the data subject. However if such addresses are stored in a database with a link to the subject's individual record, or to other data which identify the data subject, then they would clearly be personal information. The ICO's page on &quot;What is personal data&quot; says: ‘Online identifiers’ includes IP addresses and cookie identifiers which may be personal data. The page from GDPR.EU on &quot;Personal Data&quot; says: Any information that can lead to either the direct or indirect identification of an individual will likely be considered personal data under the GDPR. ... Any data that relate to an identifiable individual is personal data. The page on &quot;Personal Data&quot; from gdpr-info.eu says: Personal data are any information which are related to an identified or identifiable natural person. The data subjects are identifiable if they can be directly or indirectly identified, especially by reference to an identifier such as a name, an identification number, location data, an online identifier or one of several special characteristics, which expresses the physical, physiological, genetic, mental, commercial, cultural or social identity of these natural persons. In practice, these also include all data which are or can be assigned to a person in any kind of way. For example, the telephone, credit card or personnel number of a person, account data, number plate, appearance, customer number or address are all personal data. Since the definition includes “any information,” one must assume that the term “personal data” should be as broadly interpreted as possible. This is also suggested in case law of the European Court of Justice ... See also &quot;Can a dynamic IP address constitute personal data?&quot; If a hashed IP address is stored so that it can be related to a specific individual, it is personal data. as such, it would be subject to the GDPR. To store it one would need to identify a lawful basis under GDPR Article 6 This could be the Data subject's consent, or the Controller's legitimate interest. In either case the information should be included in the list of personal information collected (often in a privacy policy document), disclosed to the subject on request, adn deleted on request if possible. If that is done, such a use of a hashed IP, although personal information, would seem to be compliant. If a hashed IP is stored in such a way that it cannot be related to any particular user, then it would not constitute personal information, and no compliance issue would seem to exist. Limiting the retention time of a hashed IP is a good practice which would reduce any possible impact it might have.
IANAL. (1) GDPR is certainly relevant. (2) This is certainly "personal data" under the definition in GDPR article 4. (3) Maintaining this data is probably lawful under article 6 sections 1(a) (consent) - provided that the Terms and Conditions of the site make clear that the user by signing up is consenting to this information being held (3) There is certainly an obligation under article 14 to disclose that the information exists, and to say how it used. (4) Article 15 says that data subjects are entitled to see the information and know what recipients or categories of recipient have access to the information (I don't know whether it's enough to just say "moderators", or whether the moderators need to be identified). (5) I can't see any reasons why the obligations under articles 16, 17, and 18 regarding rectification, erasure, and restriction of processing aren't relevant. This is exactly the kind of situation that GDPR is designed to address. If you're restricting the service available to particular users based on a record of their behaviour or on judgements made by moderators, then they absolutely have a right to know, and a right of redress.
IP addresses are personal data. That means you need a legal basis to process them, but not necessarily consent from the user. That IP addresses should be treated as personal data in most contexts is clear, regardless of whether you can associate the IP address with a user ID. That you make such an association affirms that both the IP address and user ID are personal data in your context though. As the answers in the questions you linked indicate, there are alternative legal bases to consent. The GDPR offers a choice of six legal bases (Art 6(1) lit a–f). In most cases, you would instead rely on a “legitimate interest” for logging. But it's not enough to claim that you have a legitimate interest. You must have a clear purpose for which such logs would be necessary, and you would then have to weigh this legitimate interest against the interests, rights, and freedoms of the affected data subjects. If such logs are necessary for security and anti-abuse purposes, your legitimate interest test is likely to prevail. However, you must limit retention of the logged data and the included information to what is actually necessary. For example, keeping user IDs in there might not be necessary. If the association of IP addresses and user IDs is not necessary for a legitimate interest, then you would indeed need consent. Discussion on why IP addresses are personal data. You see many answers and opinions that IP addresses might not be personal data. Some of these are technically correct, but most are misinformed or outdated. I know only a single well-informed person that still disagrees. For everyone else such as the EU Commission, IP addresses are clearly personal data. Under the GDPR, personal data is any information that relates to an (indirectly) identifiable natural person. In the context of log files we can assume that the entries usually “relate” to a person, namely the person making the request. The exception would be requests triggered by automated systems. The more interesting question is whether the person to which the log entry relates is identifiable. While the GDPR does provide further guidance on the concept of identification in Recital 26, it does not provide clear unambiguous criteria. Thus, there is lots of debate about what that precisely means. One approach is to sidestep that debate and and notice that the GDPR's definition of personal data explicitly notes that a person might be identified “in particular by reference to an identifier such as a name, an identification number, location data, an online identifier” (Art 4(1)). Another but otherwise unrelated part of the GDPR mentions “internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags” as examples of online identifiers (Recital 30). We can also look more deeply into Recital 26 and see that “singling out” already counts as identification. We can use the IP address to single out one person's log entries from the set of log entries, so this could be interpreted as meaning that any stable user ID renders the data personal data – and an IP address is sufficiently stable in this context. Another part of Recital 26 says that we must consider “all the means reasonably likely to be used” for identification, even if this involves additional information from third parties. This phrasing is virtually identical to the GDPR's predecessor, the EU Data Protection Directive. On the basis of that DPD, the EU's top court (ECJ/CJEU) was asked to rule on the question whether dynamic IP addresses are personal data (the Breyer case, C‑582/14, judgement from 2016-10-19). It said yes. “It did not say yes”, some people will object. And they are technically correct. When someone rents an internet connection from an ISP, the ISP will have logs that connect the user's real-world identity to the IP address they were assigned at a time. You don't have access to the ISP's logs. But, if that user violated your rights (e.g. a cyberattack or copyright infringement), then you could (depending on civil vs criminal matters) report this to the appropriate authorities or to petition the court and they would have the right to order the ISP to disclose this information. The CJEU said that if this chain (you → authorities → ISP → user identity) is grounded in law, then the IP address would be identifiable. But whether there are suitable laws to compel the ISP to disclose this data would be up to national laws, and the CJEU doesn't concern itself with that. Spoiler: such laws are pretty common. To summarize typical objections: The IP address doesn't relate to a person: Can be a valid objection, but is not typically the case for user-facing web services. The Recital 30 argument is not valid because it's about profiling, not identification, and it only says that IP addresses may be used for profiling, not that they are always identifying: Technically correct, but I think that Recital 30 merely expresses the implied understanding that of course an IP address is an online identifier and permits identification by itself. “Singling out” does not apply because SOME_REASON: Indeed, this is an ill-defined term with no case law to guide us. However, regulators such as the EDPB and their predecessor WP29 routinely use “singling out” to mean being able to distinguish one person's data from other people's data. An IP address lets us do that. The Breyer judgement is not applicable because the defendant in that case was the German state, and the state has other legal means than ordinary website operators: Nothing in that case was specific to the website operator being a state or other authority. If the website operator can contact the appropriate authority and if they have the right to order the ISP to disclose the relevant data, then the IP address is identifiable. The CJEU didn't say “yes” in Breyer, it said “if”. So I'll take that as a “no”: The CJEU concerns itself with the interpretation of EU law, not with national laws. Specifically in the Breyer case, lower courts confirmed that German law has the necessary means. In other EU member states, further checks would be necessary but it would surprise me if there wouldn't be equivalent subpoena powers. If the ISP doesn't have the data, then the IP addresses are anonymous: Indeed, the CJEU scenario collapses if there is no additional data to be linked with the IP address. However: The CJEU used this scenario as an example to show that IP addresses can be identifiable. If that particular scenario fails, there could be other scenarios that still allow identification. The question of whether IP addresses are identifiable had of course been the subject of wider debate at the time. That the GDPR explicitly mentions IP addresses can be seen as a reaction to this debate. Thus, in a sense, the Breyer case is moot. It is still useful as an explanation of how broad “reasonably likely means” must be interpreted.
Obtaining consent for cookies is not required by the GDPR at all. Instead it is covered by the e-privacy directive, which as a directive rather than a regulation, must be implements by specific legislation in each individual country. The exact requirements vary with the law of each country. An e-privacy regulation has been proposed, which would have scope similar to the GDPR, would replace the Directive, and would not require national implementing legislation. However it has not yet been adopted. Proposed versions have significantly different requirements than the current Directive. Nor does the GDPR require consent for advertising that does not involve the processing of personal information, unlike some other privacy laws such as the California CCPA. However, if the Google package sets cookies without consent that are not strictly necessary for operation of the web site, it might well fail compliance with some of those national laws implementing e-privacy. Also, even necessary cookies must be disclosed to the user, as I understand it, possibly only in general terms. Several national Data Protection agencies have said that cookie compliance is not a major priority, at least not until an e-privacy regulation is in place. But that does not mean that lack of compliance is legal. Unfortunately I see no way for a developer using the Google package to correct this issue within the package. One would either have to implement a different solution, or trust that Google will fix this before enforcement becomes a serious issue. However, the app developer could add a separate general cookie consent banner, and turn off all adds if consent is not given, I believe.
In my opinion, this should be enough. The GDPR regulation is general - it does not attempt to address these issues directly, precisely for the reasons we see here: You can never predict how the technology will develop. When interpreting the GDPR, we must keep the intended goal in mind. What is the purpose of the "right to erasure"? To prevent anyone from further processing the personal data. If you "crypto-shred" it, it can't be processed anymore, not even theoretically. The encryptec file cannot be used to identify the subject, therefore it is not even personal data anymore. In case it can be decrypted in the future... Well, that is just a speculation. The courts can go to great lengths in interpreting what personal data is (dynamic IP address is considered personal data, since it can be linked to a person by the police with a court order), but i am pretty sure that "it can be theoretically possible in some distant future" is beyond the limit. As for the second question, I am not aware of any applicable case-law, but I guess that current security and technological standards will be used to assess the delay. You have a right to protect your data, the subject has a right to erase them. Those rights must be balanced, neither fully overrules the other. The delay should be short enough so the right to erasure is effective, and it should not extremely long compared to other (economically viable) backup solutions available, in line with current industrial standards.
I spent a few years working in and around the Energy industry - including a stint working at a supplier, I'm no longer there so unfortunately I no longer have access to the email chains I had discussing this with legal. The consensus at the time was that a "traditional" i.e. non-half-hourly (NHH), non-smart meter reading itself was not considered personal data - they are conceptually tied to a metering point (which may or may not be a physical meter), not to an individual and don't represent an individual's energy consumption (the granularity of the reading is insufficient to tell anything about the usage profile) But this information, while all around the implementation of GDPR it was a couple of years back and to be honest it was bugging me that I might be out-of-date on the current practices so I reached out to a former colleague who was the Data Protection Officer at the supplier I worked at to try and get a more up-to-date take. He's since moved on but was there until recently so has more experience with the topic since GDPR actually went into effect. I asked him whether a) estimated opening reads were considered "personal data" and b) what would happen with a request to change one under article 16 and he had this to say, I've translated industry-speak in square brackets: a) for NHH ["Non Half Hourly" - meters that are read ad-hoc, essentially all non-smart domestic meters will be this] an estimated reading wasn't personal data automatically until the billing flag was set in CRM and those would be the only ones we'd include on an SAR [Subject Access Request], any others are internal data not personal. HH ["Half Hourly" - meters for higher consumption users, typically larger business premises are billed on increments for each half hour so have readings for each] and remote [smart meter] readings are always personal for domestic and microb [micro-businesses are a certain class of non-domestic energy customer see condition 7A] b) erm no! we'd only change it if the value in CRM didn't match the value in the D10 [industry Data Flow used to transmit meter reads] for some reason. if they match it's an accurate representation of what we estimate the reading to be so it's just a vanilla billing dispute not a data protection issue so i'd have punted it to [name of person who was head of metering] From that it would sound as though the estimated read would count as personal data - so long as it's being used for billing purposes, but that doesn't mean they have to accept your read in it's stead. It all comes down to accuracy - GDPR requires that personal data be "accurate" but provides no definition as to what "accurate" means (which makes sense since you can't give a one-size-fits-all answer that isn't an encyclopedia) and while The Electricity Directive 2019 confirms the need for accuracy in billing again it doesn't tell us what that means. The implementation is left to member state regulators. In the UK this is OFGEM and all opening meter readings are validated through third parties (so you don't end up with the foxes guarding the hen house!) and are calculated using the following formula: Last validated reading for the meter point &lt;= supplied reading &lt;= (expected daily usage x number of days since last validated reading x 2.5) where "expected daily usage" is obtained from a database maintained by the regulator - it's calculated off meter type, property type, property use, previous validated reads etc. So if the customer provides a reading that falls outside the above the supplier can (and in practice invariably will) reject it as being inaccurate. Now this is why the when a meter reading is provided matters - reads you provide are always assumed to be the read on the day you give them. With opening reads there's some leeway, I can't remember the official rule on how much but usually they give you up to the next estimated read is generated but more on that later. Now if the reading you're trying to submit is a "now" reading and it's failed the validation criteria and you aren't happy with the rejection you can force the issue by demanding the supplier come read the meter. You don't say how long has passed since the opening read - more than the week from what you've said so presumably at least a month (guessing you've had at least your first bill). Now if they are saying the opening read was X (based on the estimated usage) and you're it should have been X + Y and the current reading is X + Y + Z you want to pay your actual usage Z not Y + Z. What you need to do is dispute the opening read, which you're entitled to do, arguably GDPR of Article 16 gives you this right, but on it's own it's a weak argument. There's established means by which an estimated read's "accuracy" is determined and assuming they followed that they're going to just tell you that as far as they are concerned it is accurate. Any challenge to that accuracy is going to have to be done within the legal/regulatory frameworks for assessing accuracy, that's what they're there for, if they won't accept your reading escalate that to the regulator - and as soon as you can. OFGEM for example allow disputing of opening reads for 12 months - it doesn't have to be resolved within that 12 months it just has to be lodged with them within that time. If you try and use the GDPR angle to pursue this IMHO it's going to muddy the waters and not help you get what you need - pursue this on billing accuracy.
Can a city request deletion of all personal data that uses a certain domain for logins? Well, they can, but they have no legal backing to make it happen. Their chances of succeeding are about as good as me requesting a Ferrari, a Yacht and a Mansion. I can make that request. People will laugh. I will not get it. I'm a little worried that I shouldn't allow certain domains to be used as logins in the first place, especially ones that might be school related You have no way to know who owns what email address. And it's none of your business. Your only interest should be in whether the address is owned by the person that is creating the account. You probably already do that by sending a confirmation link to the email address when people sign up. I'd like to have some idea for future reference if there's any case where the GDPR would require me to comply with such a request The only way you have to comply with such a request is if the owner can prove their identity. As far as I understood, the &quot;Finnish city&quot; was three degrees away from that. They could not provide any proof they are who they said they are, they could not provide a finite list of accounts they claimed to own and they could not even provide proof they own those accounts. They literally just wrote an email with zero legal meaning. I want to figure out the right way to reply to emails like this one The correct way to handle this is have a feature on your website where the account owner can delete their own account. GDPR compliant. Then you make a text template explaining how to use that feature and reply with that template to every request, no matter how stupid (like this case) they are. If they cannot identify themselves to you by proving they have access to their &quot;own&quot; email, they have no business wasting your time. Legally, they could provide you with a different method of identification. In case of a Finnish school, that would probably need to be power of attorney from all children's legal guardians and a specific way to identify the accounts that is consistent with the data given (for example if they entered their full name and address on your website). You would probably in your rights to demand a certified translation if it's all in Finnish. Apart from the fact that you as a private US citizen have no real means to check the validity of all that paperwork, personally, if I saw hundreds of pages of certified translated paperwork, I would probably just comply. Not sure it it were actually enough, but it certainly gets an A+ for effort to delete data from a private website. But a real lawyer might give better advice with a real case on their hands. Is deleting the data actually more of a legal liability than not deleting it in some cases? (People shouldn't be able to delete other people's accounts.) Indeed. You should not delete people's data because a random punk on the internet sent you an email. You need to identify who the request is from and if they are allowed to make such a request. Whether you have a legal duty to actually keep data, is up to you or your lawyer to find out. It depends on your data and laws. It is perfectly legal to make a website with a textfield that deletes any data you enter after a second. Destruction of data you own is only a problem if you break other laws with it. For example the IRS might not be amused if you destroyed invoices and other proof of taxable income. &quot;Some dude claimed I must in an email&quot; is not going to fly with them. That said, again, please, identify who you deal with, find out if their claim is valid. Don't do stuff because random internet punks write you an email. Because the next mail you get, will be from a Nigerian Prince. Please wisen up before opening that one. People on the internet, through stupidity or malice, might not have your best interests at heart. Don't believe random emails.
If GDPR applies, then no one can opt out. If it doesn't apply, then an IP block is superfluous. Whether GDPR applies is determined by Art 3 GDPR. For this, we must distinguish where the data controller is operating from. It is irrelevant where the site is hosted, but primarily relevant where the data controller (your colleague) has an “establishment”, e.g. where he resides or typically works from. Per Art 3(1), GDPR applies to all processing activities in the context of an European establishment, regardless of where the users are. So if your colleague were running this site from Europe, they wouldn't be able to circumvent GDPR by blocking European users. However, if your colleague is running this site from outside of Europe, then Art 3(1) doesn't trigger. Per Art 3(2), GDPR can apply to processing activities where there is no European establishment. There is the Art 3(2)(a) “targeting criterion”: if your colleague “offers” goods or services to people who are in Europe, regardless whether paid or gratis, then GDPR applies to all processing activities related to this offer. I'll discuss this more below. There is also the Art 3(2)(b) criterion: if your colleague monitors the behaviour of people that occurs in Europe, then GDPR applies. For example, an app collecting geolocation information or a website creating interest profiles for ad targeting might trigger this criterion. An IP block can help to establish that no offering/monitoring related to people who are in Europe is happening, but it might not be necessary. It may be worth talking a bit more about the targeting criterion. The GDPR explicitly says that mere availability of a website in Europe doesn't imply that GDPR would apply. Instead, it is necessary to establish the data controller's intention – are they soliciting users from Europe, or otherwise expecting that people from Europe might use those services? Recital 23 gives a couple of non-exhaustive factors that can be considered here, for example: the site uses a language or currency used in the EU but not used in the controller's own country the site mentions users or customers from Europe, e.g. in testimonials This means that a lot of US websites, written in English or Spanish, only mentioning payment in USD (if any), not mentioning any European countries, will not be subject to GDPR. Then, occasional European visitors are irrelevant. It wouldn't be necessary to IP-block potential European users. However, such an IP-based block would help establish that the data controller really doesn't intend for those services to be offered to people who are in Europe. My personal opinion is that it's wasted effort to block users from foreign countries in case their foreign laws claim to apply, but if such a block brings peace of mind that might be worth it. While geoblocking might not be necessary, is it sufficient? There is no clear guidance on this subject, but it seems to be generally accepted that IP-based geoblocking is fine, even though it is trivially circumvented using VPN services. Of course, if a website were to block European IP addresses but were to also advertise that people in Europe can use their services via VPNs, that would probably still be an “offer” and might defeat the point of doing any geoblocking. The Art 3(1)(a) targeting criterion is most easily applied to things like ecommerce where physical goods are shipped to the customer in return for payment – so essentially whenever the data controller participates in the EU Single Market. This is roughly similar to the concept of a Nexus in US tax law. But in principle the targeting criterion can also apply to other kinds of websites or apps such as blogs, even if they are gratis. GDPR does not just apply to for-profit commercial activity, and doesn't distinguish between controllers that are entities/LLCs and controllers who are natural persons. Things are slightly more complicated due to the Art 3(2)(b) monitoring criterion and the pervasive use of online trackers on websites, but this aspect of the GDPR is difficult to enforce and frequently ignored. In this answer, “Europe” means the European Union (EU), the European Economic Area (EEA), and the United Kingdom (UK). Note that countries like Norway are covered by GDPR, whereas Switzerland is not. Of course, the GDPR is not the only privacy law relevant internationally.