Does the IP logging + user data apply to GDPR?
<p>I read a lot about logging IP addresses, and it applies to GDPR:</p>
<ul>
<li><a href="https://law.stackexchange.com/questions/42438/do-default-apache-logs-violate-the-gdpr">Do default Apache logs violate the GDPR?</a></li>
<li><a href="https://law.stackexchange.com/questions/28603/how-to-satisfy-gdprs-consent-requirement-for-ip-logging">How to satisfy GDPR&#39;s consent requirement for IP logging?</a></li>
</ul>
<p>My question is slightly different. If I log a line like the following:</p>
<pre><code>TIMESTAMP | IP 123.123.123.123 | USER 42 | Serivice /country/list
</code></pre>
<p>In this case, I would be able to relate the IP address to a single user by ID, so do I need to ask for an agreement before doing it?</p>

<p>IP addresses are personal data. That means you need a <em>legal basis</em> to process them, but not necessarily consent from the user.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<hr />
<p>Discussion on why IP addresses are personal data.</p>
<p>You see many answers and opinions that IP addresses might not be personal data. Some of these are <em>technically correct</em>, but most are misinformed or outdated. I know only a single well-informed person that still disagrees. For everyone else <a href="https://ec.europa.eu/info/law/law-topic/data-protection/reform/what-personal-data_en" rel="noreferrer">such as the EU Commission</a>, IP addresses are clearly personal data.</p>
<p>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.</p>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p>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 <em>Breyer</em> case, C‑582/14, judgement from 2016-10-19). It said yes.</p>
<p>“It did not say yes”, some people will object. And they are <em>technically correct</em>. 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 <em>if</em> 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.</p>
<p>To summarize typical objections:</p>
<ul>
<li><p>The IP address doesn't <em>relate</em> to a person:</p>
<p>Can be a valid objection, but is not typically the case for user-facing web services.</p>
</li>
<li><p>The Recital 30 argument is not valid because it's about profiling, not identification, and it only says that IP addresses <em>may</em> be used for profiling, not that they are always identifying:</p>
<p>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.</p>
</li>
<li><p>“Singling out” does not apply because SOME_REASON:</p>
<p>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.</p>
</li>
<li><p>The <em>Breyer</em> 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:</p>
<p>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.</p>
</li>
<li><p>The CJEU didn't say “yes” in <em>Breyer</em>, it said “if”. So I'll take that as a “no”:</p>
<p>The CJEU concerns itself with the interpretation of EU law, not with national laws. Specifically in the <em>Breyer</em> 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.</p>
</li>
<li><p>If the ISP doesn't have the data, then the IP addresses are anonymous:</p>
<p>Indeed, the CJEU scenario collapses if there is no additional data to be linked with the IP address. However:</p>
<ul>
<li>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.</li>
<li>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 <em>Breyer</em> case is moot. It is still useful as an explanation of how broad “reasonably likely means” must be interpreted.</li>
</ul>
</li>
</ul>

gdpr