For a simple example, let's say you use an immutable data store. What do you do if a customer wants every info about them redacted, but you did something like store their IP, name, or email. All common things. Now you must build mutability into your store and all assumptions that used to be made can be removed.
This is just a very small piece of something that even a small or medium company may be using or doing.
Doesn’t help for pre-GDPR data but that’s the way you should be building going forwards.
Leaks are punished, as they probably should be, under gdpr anyways. But now do we have to account for all of the keys over time and have it be probably gone? What if we take backups of the systems that stores the keys? Do we have to purge those backups as part of the deletion request? What if they're terabytes in size?
Just thinking through edge cases here
That makes selects & joins on the data quite a bit more complex. Per-record & per-subject keys are … tricky.
The GDPR imposes some new requirements that were not previously part of any privacy best-practices that I'm aware of, and that create some system complexity. Chief among these is the right for users to retract consent after it has previously been granted. This effectively requires processors to be able to delete individuals' data from their records, something that was not a design requirement of many systems. This becomes increasingly more difficult as user data has often been aggregated, and joined with other data sources.
Another key differentiation of the GDPR compared to previous legislation is that it applies not only to data that identifies a person (such as by containing a name or social), but to data that could in theory be linked back to the user through a common identifier. Previous best practices have considered the user's privacy protected if they were identified through a hashed email or an opaque database identifier, but the GDPR does not consider this sufficient anymore.
It's not even malicious; in the absence of regulation to the contrary, companies -- especially companies still in search of a revenue model -- have an incentive to collect as much information as possible.
This is a huge problem for an org that relies on huge amounts of such data to keep our product running and uses systems which were never built with these new rules and classifications in mind.
Furthermore, there are huge complications surrounding "data processor" scenarios (in other words, Enterprise SaaS products). For example, what takes precedence, GDPR deletion or our contractual security/auditing obligations?
Again, I'm not saying that any of this isn't worth while, just that when you get down into the weeds things look a little different.
US companies who previously had the narrow scope of PII to handle, now have to consider the much broader scope of 'personal data'. I am sure that for lots of US companies providing services to EU citizens/residents that will definitely represent a substantial burden.
Even for EU companies, the reality is that many will have previously taken a view that the size of potential fines was not high enough to warrant giving certain matters that much attention or at least spend money on areas they considered more important. For example, if I have a choice between implementing additional security measures to protect my network versus building functionality to delete on command, many companies will have gone with the former.
On retention, my view is that if you consider it necessary to retain information for purposes of auditing/security, and have made that clear in your contract with the client (who would then should make that clear in their privacy notice if they don't already have a general caveat around that), then the right to delete under Art 17 does not kick in because Art 17(1)(a) is not engaged. Also, dependent on the grounds on which you are looking to retain Art 17(3) gives a controller a clear ground to retain.
Also the right to erasure is one that will generally be directed at the controller. The controller would then flow down that request to a processor but that is where the contractual protections would come in, which in my experience, most clients are generally willing to accept.
Changing the processes may not be hard, if you're doing things close to right to begin with. Complying with the documentation requirements? That's going to be painful.
Just for starters, you will need to decide which data you have to process and which is optional. Some data will need to be kept for compliance purposes. How much anonymization will be applied. What data is in every single internal db in your org? Do you even know of all the internal dbs? Each data will have to be tagged with the collection basis, either legitimate interest or consent.
The GDPR is also -- as I've complained on here before -- less of a regulation and more of a framework for 30-odd individual country privacy regulators. Some parts of the GDPR, eg on consent, are laid out in black and white. Other parts aren't at all. And the EU wankers have declined to issue final guidance on the latter even by this date, less than 3 months from the compliance deadline.
There's also cute stuff in there like if you have more than 250 employees or engage in "widespread processing of personal data" (widespread processing left, of course, undefined) you will have to hire a Data Protection Officer. Said DPO must be in the EU and report to the ceo. This will be quite a nice cottage industry for EU lawyers.
American companies are probably unable to pick a lead regulator and hence will be subject to the individual regulators of each EU country. What happens when some french person (France has a very aggressive privacy regulator) complains to the regulator, and you are dealing with a regulator in a language you don't speak? I hope you enjoy paying legal $600/hour.
The GDPR does specify enough around consent (ie all consent-basis contacts must be default opt-out) to make it highly unlikely that any of your email or newsletter opt-ins are compliant. You will have to re-consent all of your marketing emails, and this may come with significant attrition. This will be painful for outbound sales, even outbound sales that currently is very respectful of opt-outs.
Data subjects can also do things like request a copy of all data (a so-called Subject Access Request or SAR), request deletion, and even freeze processing, which is supposed to stop processing without deletion. This must percolate through all third party systems, of which most companies will have a lot. Just start with your two mailing systems (transactional + marketing), logs, analytics, billing, salesforce, billing, etc. And as mentioned above, it is required to percolate through internal systems.
You will have to have an ugly discussion about backups. Are you going to roll backups at 30 days? That's probably not ideal. But what should happen when a data deletion request is received and that data is, of course, sitting in backups?
The short story is this is expensive and painful enough that, if I only had incidental European customers, I'd probably ignore it and close their accounts if they complain. This is very much not GDPR compliant, but as an American company, I'd do it anyway because of the expense of dealing with the above.
The companies that have to spend significant coin are the ones who are not already complying.
Best practices are funny because context and history are important. Actual regulation is not so forgiving.