[uuidgen]

So what are those problematic GDPR requirements?

- ask for permission

- do not collect more than you have

- store securely

- allow users to change or remove their data

- have a dedicated officer if you collect a lot

Is that really THAT hard? (If yes, then really you shouldn't be collecting any data.)

[drdeca]

Depends on what "have a dedicated officer" entails?

If it requires employing someone you wouldn't be otherwise, then, yes, I do think it is unreasonable to require that I hire someone if I am letting people give me an email address for the purpose of sending them an email in the event that <x> (assuming that I am verifying at the time they give me the email address that they have control of the email address in question), no matter how many people request to be added to the list of people to send an email in the event that <x> .

[uuidgen]

It means designating a person that understands GDPR in the scope it applies to the particular data set and handles requests/security incidents. It can be secretary after a few hours of training.

And I think that if you manage a mailing list of million of people then having someone who understand security implications of it and how much they can lose (even to a simple phishing at this scale) if you get that list accessed by scammers is necessary.

[drdeca]

Secretary? I’m not really talking about an organization, I’m talking about an individual.

A few hours of training is reasonable enough, I suppose?

Seems like it might be simpler to just have whoever is responsible be liable for any problems that could arise from not keeping the list secure? I guess maybe an issue issue with that is that it would be hard to track down all the harms that actually occurred as a result of letting the list fall into the wrong hands, and also hard to even get a good estimate.

[echelon]

Let's say you built your massive software business that relies on immutable records exchanged between services. Maybe your process involves cold storing some of the data. You have hundreds of microservices and thousands of lambdas, each one with a dedicated purpose. Your address microservice stores PII. Your session service knows about email. Your employee service has first and last names.

Now you have to coordinate ALL of it to support right to forget and data export.

You need an expert in each system to drop what they're doing for one to two quarters to figure out how not to break everything and support this new use case.

You need to synchronize the plan of action throughout all of the various orgs. Some party receives GDPR requests, and that now needs to trickle down to every service to handle and report back.

This is hugely expensive.

Millions of dollars.

You vastly underestimate the toll on existing legacy businesses.

[isbvhodnvemrwvn]

If you rely on immutable data records for sensitive information such as PII, and you don't have the full view on where the data is stored and how to delete it, the law IS SUPPOSED TO make you realize that it was a bad mistake. It was a mistake when you started, now you just have to pay for it to get fixed.