>There are so many ambiguities and confusing situations. Eg: legitimate business use and free accounts. What do you define as the free account user to still be a customer? What if you nuke their account after some inactivity and then they come back? They're going to be pissed.
Processing of data is legitimate so long as you still have a reason to process that data, as well as if you have a contractual obligation with the subject to process that data. If that contract involves keeping an account registered indefinitely, until deletion is requested, then so be it. State it clearly and plainly when the user registers an account, and if you're that concerned about the ambiguity of the situation then the solution seems a simple one, no? Allow the user to choose to have their account deleted after a certain period of inactivity, or email users that their accounts will be deleted after lengthy periods of inactivity. It should be noted that 'inactivity' is industry specific, for something like free services online it could be industry standard to keep accounts for years, it's hard to imagine that a user would be upset about having an account they haven't used in 4 years be deleted, and really, do you need to keep that account after 1 year of inactivity? 3 Years? 5 Years?
I realise the law is purposely ambiguous here especially when applied to things like user accounts, but it helps to understand that storage limitations and retention plans apply less to things like accounts and more to things like metadata that you may be collecting. It's perfectly reasonable to keep user accounts registered for years even after inactivity for example, it's less reasonable to collect data for marketing campaigns and keep that data for years. Retention limits are also far more relevant to processors of data rather than for controllers of data, if you're a third party service you shouldn't need to keep data for longer than your contract with the controller specifies, however controllers have far more of a legitimate need to process data for longer. The push to have retention limits may as well be seen as a push to anonymise data that no longer needs to be tied to an identified person rather than a need to delete everything that hasn't been touched in 90 days.
>Server log retention, message queues, etc and ip addresses (which may or may not be problematic depending on how they're stored and with what). Not fun.
IP addresses become problematic when you can tie them to an identified person, i.e., you're linking user accounts and IP addresses. As far as generic logs go, if the only personal information you're collecting is IP addresses then you shouldn't need to worry too much, treat the logs with some care as they still do contain personal information but don't sweat it too much. Make sure that if your logs are leaked that you inform users (i.e., through a blog post) that logs were leaked and the only personal information contained is IP addresses. IP addresses are one of the easiest things to justify needing to keep as a legitimate interest as well as needing keeping indefinitely, and if only IP addresses are leaked it's not really a big deal. If you have other personal information in your logs, especially if it's linked with more information, i.e., 'ip address 1.2.3.4 who has username asdf searched for jkl; [etc]', you should take steps to justify why you need to keep that extra information and maybe look at implementing a retention limit, or better yet, anonymise some of the extra data after you are finished processing it. If the metadata you're collecting is kept to a minimum and/or anonymised as much as possible, the need for a retention limit drops almost entirely, not that retention limits are entirely needed.
>Third party vendors. Omg third party vendors. Many of them have no idea wtf they're doing. Ive seen some vendors swear up and down they didn't store any PII, just to realize eventually that they did and they didn't even know. Hope those DPAs are signed and in order! Hope you have good lawyers!
In every other industry you are responsible for when you choose a shoddy third party vendor who makes a mistake, I fail to see why the tech industry should be any different. I realise there is going to be a lot of teething issues on this particular issue, but part of the reason GDPR has as much scope as it does is because of these clueless third party vendors who misuse and abuse data. Maybe look into using European third party vendors in the future, as they would be just as culpable for their mistakes as you would be and they would be liable for fines too. :-)
>It's insanely hard for any non-trivial systems. It gets even worse when american laws and GDPR conflict (eg: finance data retention laws. The definition of legitimate business need gets REAAAAALY fuzzy...)
For what it's worth, the GDPR makes explicit exemptions allowing for processing data where you have a legal obligation to do so. There is absolutely no conflict between financial laws and the GDPR in this respect.