| > * 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." |
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?