[ryandrake]

I would (maybe naively) think that the cost of GDPR compliance would be small if your company is already safeguarding user data and respecting user privacy. If a company’s cost is “staggering“ doesn’t that say a lot about its existing privacy practices?

[sb8244]

I'm not sure. I think this is a very absolutist and probably naive way to look at it, frankly.

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.

[robin_reala]

You encrypt the data before it’s stored with a unique key, then destroy the key when the user requests it.

Doesn’t help for pre-GDPR data but that’s the way you should be building going forwards.

[reynoldsbd]

"We could have done it this way." doesn't pay the bills (or in this case, doesn't prevent steep fines).

[robin_reala]

Sure, it’s always painful to fix existing systems. In the future it should be no more expensive than business as usual though.

[sb8244]

Will this satisfy GDPR requirements fully? What if that key had somehow been involved in an unknown leak in the past (of just the keys) and then the data is exposed somehow in the future?

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

[eadmund]

> You encrypt the data before it’s stored with a unique key, then destroy the key when the user requests it.

That makes selects & joins on the data quite a bit more complex. Per-record & per-subject keys are … tricky.

[s73v3r_]

Right, but you had assumptions built into your data store before, namely that you could keep all info about someone for eternity, and that you'd never have to correct it.

[lmkg]

I presume you're talking about things like informing users how their data might be used, storing user data securely, and not selling it to third parties. That sort of stuff is relatively easy.

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.

[ryandrake]

Thanks for the details! I can see how this could get costly for complex systems. As a user though I would think all those things you listed would be existing privacy best practices but I guess that’s being way too optimistic. Scary what companies are currently getting away with, too but not surprising.

[kelnos]

I think you're right in that those things would be (or should be) considered "privacy best practices", but, unfortunately, most companies don't have "following privacy best practices" all that high on their list of priorities.

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.

[reynoldsbd]

Definitely not true. GDPR significantly broadens the types of data subject to legal requirements. Whereas yesterday I only had to protect PII and content, now even telemetry and performance data becomes subject to new rules.

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.

[grabeh]

I think the main issue that I see is that whilst GDPR doesn't massively expand the scope of what is personal data beyond that under existing data protection law, it does expand the territorial reach of data protection law.

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.

[AnimalMuppet]

From the article, the thing that jumped out at me was documenting it all. Sure, your processes may be perfectly pristine. Where's your document that shows that you considered everything? Don't forget to include development processes. And don't forget to update your documentation when your processes change.

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.

[x0x0]

You're completely wrong.

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.

[s73v3r_]

All of those things that you listed are things that you should have done a long time ago, before you started collecting and storing the data.

[lostcolony]

It says a lot about the cost of privacy, period. The cost would be staggering whether they're modifying existing things, or creating new things, just in terms of ensuring "Yes, we're doing this correctly".

[ryandrake]

I just find it hard to believe that the law is a significant cost to companies already doing the right thing. Sure, there is a non zero cost to ensuring your existing practices are lawful, which everyone must pay. But companies already in compliance shouldnt have to modify or create anything.

The companies that have to spend significant coin are the ones who are not already complying.

[lostcolony]

Part of the cost is -documenting- what you're doing. Ensuring the right stakeholders are involved and signed off on it. Etc. When there's a regulation to do it, suddenly you have to involve legal, and the business stakeholders want to better understand it, whereas before it may have just been the developers.

[reynoldsbd]

This is incredibly false. When you change the law, you can't assume that people who are currently in compliance will continue to be.

[ryandrake]

To use a silly extreme: if a new law came out that said I couldn’t yell profanities at my customers, I’m already compliant.

[reynoldsbd]

Counterexample: comedy central now has to work to redact all noncompliant programming.

Best practices are funny because context and history are important. Actual regulation is not so forgiving.

[ryandrake]

Good point—guess this is not as black and white as I first thought!