Comment by amarkov | Hacker News Reader

Comment by amarkov | Hacker News Reader

Parent Full thread

I must delete personal data "without undue delay". This opens up a few questions, which as far as I can tell the text of the regulation provides no guidance for.

* I (like most companies) have a variety of unstructured and/or immutable logs. I can't just DROP FROM table WHERE. Is it acceptable to delete this data by waiting a few days for a retention period to expire, or do I have to retrofit deletion functionality in?

* What if the retention period is a week, or a month? What if I've been advised to establish those longer retention periods for other reasons?

* If a bug is found in the data deletion workflow, is it an undue delay to say we'll tackle it next sprint? Do we need to drop everything and make it a priority now?

* Once we've resolved a personal data deletion bug, is it an undue delay to roll it out slowly over a week? Does it matter if this is our standard rollout process, or if there's a risky hotfix process we're deliberately choosing not to use?

> * I (like most companies) have a variety of unstructured and/or immutable logs. I can't just DROP FROM table WHERE. Is it acceptable to delete this data by waiting a few days for a retention period to expire, or do I have to retrofit deletion functionality in?

In order to be allowed to store PII (even if it's in logs) you need a specific purpose. Why do you put PII in logs? What benefit does the user have?

> * What if the retention period is a week, or a month? What if I've been advised to establish those longer retention periods for other reasons?

If there is a legal requirement to keep PII (for example accounting) you can/must keep it as long as the legal requirement demands. If there is no legal requirement you have to delete PII, there is nothing that trumps that.

> * If a bug is found in the data deletion workflow, is it an undue delay to say we'll tackle it next sprint? Do we need to drop everything and make it a priority now?

If your next sprint starts 1 month down the road the regulator won't be happy. If it's next week and your GDPR doesn't have other gaping holes a reasonable regulator won't bat an eye.

> * Once we've resolved a personal data deletion bug, is it an undue delay to roll it out slowly over a week? Does it matter if this is our standard rollout process, or if there's a risky hotfix process we're deliberately choosing not to use?

Are you playing for time or doing responsible software development? If a regulator thinks you are bending the rules good luck, otherwise nobody will demand of you doing dangerous stuff.

I know, there are a lot of things open to interpretation. But as my lawyer told me: "There are people getting a speeding ticket for 5 above the limit and others who don't. Try to stick to the limit and make sure you are seen as one of the second category."

Under the terms of the GDPR, user benefit is not required. I can log any PII I'd like as long as the user's given consent for it to sit in that log, or for it to be used in some process that reads from that log.

I probably would want to impose stricter rules on myself for the sake of avoiding regulators. But that's part of the problem. It doesn't seem possible to comply with GDPR as such without an army of consultants to guide you; what you have to do instead is invent a stricter regulation and follow that one instead.

> If a regulator thinks you are bending the rules good luck

That's the other part of the problem. A healthy regulatory system needs some way to say "well, you think I'm bending the rules, but I'm actually compliant in this complex way you hadn't considered". If a GDPR regulator just doesn't know much about software development, and thinks that any rollout-induced delay is undue, how do I argue against that?

> Under the terms of the GDPR, user benefit is not required. I can log any PII I'd like as long as the user's given consent for it to sit in that log, or for it to be used in some process that reads from that log.

Read my comment again, it does not say a user benefit is required. What it says is that you need a specific purpose for processing PII. A user can only give you consent for a specific purpose. What is the purpose that results in his PII ending up in an immutable log file? Asking for general consent without a specific purpose does not work with GDPR.

> That's the other part of the problem. A healthy regulatory system needs some way to say "well, you think I'm bending the rules, but I'm actually compliant in this complex way you hadn't considered". If a GDPR regulator just doesn't know much about software development, and thinks that any rollout-induced delay is undue, how do I argue against that?

If you feel you are being treated unfairly you will probably argue through your lawyer. As a technical person I would love it if the GDPR is black and white. It would allow me to know if I comply or not but real life is hardly black and white. So instead of being upset with things I can't change I will just do my best to comply.

PS: I don't understand the downvote.

I also don't understand the downvote.

I need a specific purpose for processing PII, but that doesn't mean that I need a specific purpose for each individual place that PII ends up going. If my web server or database end up incidentally capturing the data in transit, that's not a violation, any more than it's a violation if I copy the data onto more sheets of paper than are strictly necessary.

You are right and in that case you should also have a process in place to delete the PII from the additional sheets of paper. I'm inclined to keep PII out of logs in the first place but am unsure how to proceed. Either just don't log any data / parameters or implement some kind of whitelist like you would with passwords and other secrets.

For logs, I'll suggest you aim to avoid personal data in the logs, and if necessary only log an anonymous id and separately keep a mapping to a user for the bare minimum amount of time needed, and in a way that let you explicitly delete it easily.

A lot of the "problems" of the GDPR goes away if you minimize the amount of personal data you process and retain, which incidentally generally will be good for your security as well.

A lot of the problems of the GDPR do indeed go away if you're building your systems from scratch, using data privacy standards significantly beyond what GDPR mandates.

Surely you see why this doesn't weaken the claim that it's hard for existing companies to understand what must be done to comply.

No, I don't, because the point is that my applying principles that are good to follow anyway, you reduce your exposure to a point where you don't really need to worry about what needs to be done to comply. At the same time you're improving security etc. as well (including internal security; e.g. I've deployed approaches like that at clients whose original intent was to prevent employees from accessing data they shouldn't, and where simplifying following data protection regulation was simply gravy)

Reply on news.ycombinator.com