No - you cannot ignore it when you are a small company that's true. But you can (probably, we'll see) ignore it if you don't do shady shit with your customer data. You are allowed to process data, if it's used to fulfill the service you provide. That's reasonable, and probably applies to most of what OP is doing.

So when I get reported, I'll say I didn't worry because some guy on Hacker News said I'd be OK? That's not how it works. You can be as confident as you want without affecting the reasonable worries actual businesses have about this regulation.

I have an actual business, thank you. And I did my homework by talking to a lawyer about it. What I got from this talk is, that most of the stuff that is going around is pure panic mode.

Please, don't take my words as granted but talk to an actual lawyer. You'll probably even find a free session for startups somewhere in your city, at least in Europe.

Ask the regulators. The ICO provide comprehensive guidance documents, a wide range of tools to facilitate compliance and a dedicated helpline for small organisations. They're extremely busy at the moment, but they'll be more than happy to explain your obligations under the GDPR and the best way of achieving compliance.

https://ico.org.uk/for-organisations/guide-to-the-general-da...

https://ico.org.uk/global/contact-us/advice-service-for-smal...

Point of order, the ICU is one of many potential regulators & likely not an important one given brexit.

What hav the Danish & Belgian regulators been doing lately?

ICO is just the UK regulator. How about the regulators of the other 28 EU states?

There are specific mechanisms in place to ensure that the regulations are applied consistently, set out in Chapter 7 of the GDPR.

https://gdpr-info.eu/chapter-7/

This is already falling apart. Some countries like Austria already decided to reprove but not to fine offenders. See German article: https://www.heise.de/newsticker/meldung/Keine-Strafen-Oester...

Harmonized. So an ok from one would count pretty heavily when interacting with others.

False. If you do any sort of logging of network traffic - think server logs - or even backup your database and a single person comes asking for all their data to be removed from all your backups sitting in cold storage, you're in for a world of hurt.

The mere act of pulling all my database backups from glacier at once would cost enough to force me to just shut down my personal projects.

GDPR does not require deleting data from backups.

http://blog.quantum.com/backup-administrators-the-1-advice-t...

"The GDPR is open to interpretation, so we asked an EU Member State supervisory authority (CNIL in France) for clarification. CNIL confirmed that you’ll have one month to answer to a removal request, and that you don’t need to delete a backup set in order to remove an individual from it. Organizations will have to clearly explain to the data subject (using clear and plain language) that his or her personal data has been removed from production systems, but a backup copy may remain, but will expire after a certain amount of time (indicate the retention time in your communication with the data subject). Backups should only be used for restoring a technical environment, and data subject personal data should not be processed again after restore (and deleted again)."

CNIL is one of ~20 regulatory agencies & this isn’t their “official” stance.

Other opinions have concluded that you must keep an index of requested deletes in the face of backups, for instance.

That agrees exactly with what CNIL said. Obviously you have to keep an index of requested deletes for the same length of time you keep backups in order to re-delete the relevant data in the event of restoring the backups.

Article 63 of the GDPR specifically covers consistency of enforcement across the regulatory agencies.

I don't see the problem here (for small companies). If you have a database with user data, and a user deletes his account, you delete the data from production. At this moment, you have a live system without this users data, and some backups with the data. The moment you make a new backup, you have a dataset to restore from that does not include the user data.

You keep daily backups for 1 week, and after one week the users data is gone from all backups.

The only possible window for restoring deleted user data is the time window from deletion to backup. To "solve" this you need to make more backups, ideally live backup and replication with really frequent snapshotting. And this is something you would want even without the new law, because you don't want to lose user data in case of a server failure. Why would you restore from an old backup? (And if you really need to restore from an old backup you most likely want to merge this backup with the newest one to reduce data loss. In this case you can reapply all deletes.)

The new laws don't change anything. For me at least. Also my lawyer is totally fine with "only" minimizing the problematic time window. We both know that it will never be zero.

You have a very narrow view about what backups are used for. Which is fine for your business, but for many others, the backups are important business records. What if an employee is stealing from the company, and does it for longer than the time that your business keeps backups? You might say "oh but I keep logs", in which case you have the same problem with keeping the logs that you think you dodged by not keeping the backups.

Yes and no... the GDPR is all about purpose, and if you keep a log for the purpose of logging unauthorized access to data this is fine if you state this fact in the contract with the employee and only store and access the logs for this purpose.

You just can not keep backups of everything for the purpose of everything.

My example can not include all cases and was written in the spirit of "we are a bunch of devs with a small project". As is monal.im .

I have a radical idea: don't keep that data.

You can still log accesses and aggregate them into statistics, just don't keep the IP addresses. You can still log IP addresses to detect DOS attacks or whatever, just delete the log when you don't need it anymore, after a day or so. There's no need to get backups from glacier, because you know there is no personal data in them.

GDPR does not require you to delete PII from backups. This is a misconception.

You do need to have a documented and implemented backup retention policy and communicate this if you receive a request to delete a user's data.

There are other laws which require you to keep data for up to 10 years. This will require you to split up your backups and clean the ones for the longer storage from all unnecessary PII. That is already costly and challenging. Problem is nobody really knows what data you have to strip of and what do you have to retain for other laws.

You are talking about a very narrow set of legal reasons that need 10 years of archiving. This has nothing to do with the GDPR and these archives should really not be created from normal daily/... backups. If you fall into that category you need a lawyer even without the GDPR and this lawyer will tell you exactly what and how to archive. "Nobody really knows" does not apply here because your lawyer knows.

> very narrow set of legal reasons that need 10 years of archiving

Invoices for VAT MOSS have to be archived for ten years. And until today nobody really knows (it is another EU law disaster) which information you have to keep to prove the origin of your customer.

Why do you need to keep more information than the invoice itself? All invoices should include the invoice recipients name and address, and thus the country of origin. In many countries invoices below a certain amount can omit the recipient, but you don't need to omit it.

Do you invoice for a different country than the recipients country? Why?

From https://europa.eu/youreurope/business/vat-customs/moss-schem...:

> the information used to determine the place where the customer is established or has their permanent address or usually resides.

Sadly this regulation doesn't specify which kind of information this could be.

Your customer could try to get a better price by pretending to be from a country without VAT. Therefore the address given by the customer is more or less worthless in this regards. One more realistic information is the IP address. But as this also is pretty easy to spoof it might be reasonable to also keep information about the country were the cc card was issued, if possible.

Backups have an expiration. That should be enough to satisfy the requirement for deletion.

My only still active side project to which this applies isn't open for public registration yet, and I fully intend to completely block the EU before going live.

If you don't have any revenue or nexus in the EU, what are they going to do to you whether or not you block them?

They aren't a global superpower who will or can invade your country to enforce their laws

That's only the case if you store personally identifiable information in your logs. IPs don't count as long as you're collecting them for security purposes and don't have a way to identify a person using the IP. Plus, if you rotate out your logs and clean them up regularly, you don't really need to worry about it. (That's what the EU lawyers at my work told us.)

Database backups are only a problem if you save them forever, though it sounds like you are. GDPR generally requires that you regularly archive, rotate out, and clean up old data.

The GDPR faq disagrees: https://www.eugdpr.org/gdpr-faqs.html

It doesn't. It says:

> Any information related to a natural person or ‘Data Subject’, that can be used to directly or indirectly identify the person. It can be anything from a name, a photo, ... or a computer IP address.

Emphasis mine.

I said:

> IPs don't count as long as you're collecting them for security purposes and don't have a way to identify a person using the IP.

You are making a claim to one of 2 things:

- the ip addresses never uniquely identify someone or

- you have a legitimate interest to collecting this data.

Neither provides carte blanche for collecting IP address.

I'm actually saying that both are a requirement for logging IPs in the circumstances being discussed here, but I certainly don't mean to suggest that either would grant you "carte blanche" to collect and log IPs.

I suspect that logging IP only for security purposes is fine, but the idea that it is a bulletproof defense is just wrong, we have no idea. Current indicators are that regulators think IP is personal & that legitimate interest defenses are suspect.

I can't see any way in which this interpretation can be valid. You'll always be able to "directly or indirectly" identify people from IP addresses. Just because I don't store IP and identity together, doesn't mean there's not many other ways to identify somebody based on an IP address.

How would one identify a person using only an IP address?

If you have "other ways to identify somebody based on an IP address" then that wouldn't meet the criteria laid out by the lawyers.

I think the concern of the regulatory agencies (valid or not) is that there are db for sale that allow extremely precise locality information based on IP. Close enough to identify a household, which combined with other data can limit the data to a single person.

Hello, not a lawyer, but mine said you're wrong.

You might be thinking of this pseudonymization stuff. My advice is not to play with it. Just delete your logs after a month unless you have a demonstrable and immediate security need for them.

Wrong about what? I wasn't referring to pseudonymization; we thought that wasn't worth trying after the legal teams laid out what it involved. Log rotation is important, like I mentioned.

I spent near to $10,000 in 6 lawyers 2 in usa 4 in different european countries and all wrote detailed report for me negating what you just said. IP is one of the most PII identifiable elements of an internet user. Exception is when you can prove such IP is a merely a proxy. please get some other lawyers opinion!!

Note that I didn't say IPs aren't PII; I said they don't count as long as you are collecting them for the specific purpose of security and don't have any way to identify the person using that IP. Pretty much by definition that is not PII.

That came from the legal departments from our German, UK, and French entities.

You contradict yourself, either its PII or not. Common understanding in the industry is that it is. Purpose of security doesn't change if its PII or not. Although security/auditing might allow to hold on for longer because you need the PII as a feature (which you should be transparent about). For pure telemetry you don't need it, I'd claim.

IPs can be PII under certain circumstances, but not the ones I laid out.

> Purpose of security doesn't change if its PII or not.

Security is the legitimate interest, an important part of collection under GDPR.

PII is not the standard for GDPR compliance.

That's correct, but PII is what the person I replied to was talking about.

Here's your problem, you have 6 lawyers.

If you're too worried about this, remove the last octet from the IP or and/or it with a mask. And especially don't associate the IP with the user (by default you can't find out who's the user only by IP).