[nrjames]

Standard server logs with IP addresses must be disclosed in a privacy policy but you do not have to seek consent for them because you collect them as part of a business critical need to prevent fraud. See Recital 47, which includes the language: "The processing of personal data strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller concerned." https://www.privacy-regulation.eu/en/r47.htm

[njl]

The user can request I delete all of the data related to them without “undue delay”. Are you ready to purge all references to certain IP addresses in your logs? Don’t forget backups.

GDPR blows up a lot of assumptions we make about writing software and managing servers.

https://www.privacy-regulation.eu/en/article-17-right-to-era...

[nrjames]

Again, you do not have to if is business critical and used for fraud prevention. You must routinely delete logs before they get too old (60-90 days maybe), but you do not need to take special action beyond that. I’m not saying the GDPR isn’t troublesome, but having spent the better part of the last 6 months combing through the law and interpretations of it, I think the concern over IP addresses in log files that can be used for security and fraud-prevention is unfounded. Data portability requests are likely where it will get onerous and expensive. Even with those, there is flexibility build in to prevent users from repeatedly requesting their data at short intervals.

[rorykoehler]

Other countries mandate that we keep logs for 7 years. This is unworkable.

[mrweasel]

I believe that you're okay in that case. Some countries in the EU require that you have financial records stored for five years, and they will always contain personal identifiable information. The GDPR states, if I recall correctly, that because some other law requires you to store the information for X number of years, the customer can't force you to delete it.

Similarly credit agencies aren't required to comply with deletion requests either. You can't simply GDPR your way out of a bad credit score.

But it's a total mess, when you read the GDPR it's clear that it's written by people with limited understanding of IT. Of cause it has to be extremely strict, otherwise you'll end up with a Cookie-law 2.0. The cookie law from the EU was read by the industry in a way that clearly wasn't intended. It made zero different to user tracking, we just got a bunch of pop-ups stating that the site uses Cookie. If you read that law as I believe it was intended, the idea would be that you could say yes to cookies or no. If you choose no, the site would disable the use of tracking cookies. But was to much work, so people just slapped a cookie pop-up on their sites.

[peoplewindow]

The cookie law was never well thought out, that's why nobody read it in the way it was "intended" (what was the intent anyway). The distinction between a regular cookie and a tracking cookie doesn't exist except in the minds of the EU regulators, so no surprise that all they achieved with this was making the EU web experience horrible by default instead of opt-in horrible - browsers have let you request notification of cookies being set since forever, after all, and you can create extensions to notify you in whatever way you like.

[rorykoehler]

Thanks for the clarification. This is definitely going to make lawyers rich and make it much harder to startup. The legal cost overhead benefits the establishment at the cost of startups and SMEs

[x0x0]

Data portability is no more work than a SAR. Nothing says you have to give them the data in a convenient format; you can perfectly well hand a pg or mysql dump to them that is nothing more than the unformatted output of your SAR process and call it a day. In particular, it doesn't have to be convenient at all to do data interchange; it just has to be "structured, commonly-used and machine-readable format."

[adrianN]

You'd also have to argue why you need to store the IP and not just a hash of the IP if it's just for fraud prevention.

[poooogles]

If you're using an IPv4 address as a seed then that's pretty useless due to the small address space.

[octavn]

I wouldn’t worry about individuals requesting access or deletion of the Apache logs concerning a certain IP as I see no possible solution for the “reasonable measure to verify the identity of a data subject” against an IPv4 IP and, as per the GDPR, providing data to the wrong person could “affect the rights and freedoms of others” in which case you shouldn’t provide the data.

[PeterisP]

Look at the paragraph you're quoting - you have to comply with the request if "one of the following applies", which means:

1) if you have a legitimate reason that allows you to process the data without consent (which would be the expected scenario; if not, then any sane organization would likely just choose to don't have that data in their logs at all), then none of the following applies, and you can refuse the request;

2) if you had a legitimate reason but "the personal data are no longer necessary", then you must comply.... but that's just duplication, you should not have had that data anymore since if you're compliant, you should have cleared the data out already. E.g. if you believe that you need (and are allowed) to store data for 6 months for purpose X; then you'd ignore the request for 5 month old data as you need it, and ignore the request for 7 month old data as you already purged it as a routine operation.

3) if you didn't have a legitimate reason and actually needed consent, then you follow the same process as you do for scrubbing references to all IP addresses which didn't give you consent. If you're compliant with the other requirements (which is tricky in this case), then the deletion request doesn't add anything meaningfully different.

[x0x0]

The user can request whatever. If you are processing the data via consent, you have to obey. If you processing the data under a different basis, then you may well not; you have to figure out. I hope you like paying lawyers!