3 ms·

It's pretty much part of your normal data management that you'd be doing anyway, except it now has an additional lifetime (on top of any you might have had). S

It's pretty much part of your normal data management that you'd be doing anyway, except it now has an additional lifetime (on top of any you might have had). Since when ingesting the data you knew where it came from and on what timestamp, you also know when to next check for deletion. And since you also know where it came from (the owner), deleting/sending it on request (when applicable - not all data is always required to be deleted) is pretty straightforward. In essence it's like garbage collection for managed languages (like C#) but for your data. At the end of the day, no matter what you use (existing process, create a new process if you weren't managing your data so far, or use some product), treating data like radio active waste will generally lead to good designs. You only keep what you need for the time that you need it, everything else gets removed.

ndsipa_pomu 2y ago
> You only keep what you need for the time that you need it Just to add that it's stricter than that - you can only keep the data that is required for the purpose that you detailed to the customer. e.g. If you ask for their email address for password validation, then you're not allowed to use that email for other communication unless you explicitly asked for that as well.
- oneplane 2y ago
  I completely agree, GDPR is definitely a more detailed ruleset than what I outlined, but from a data management superset perspective you would have the mechanisms and facilities to deal with the GDPR-specific rules anyway. I've found that this is mostly a problem in organisations where data isn't managed, the government doesn't protect the people, or where some vague value is assigned to the data (so it does get stored, but when it leaks it is supposed to not have value and therefore do no damage). So looking at it from an "you will be managing it anyway" angle has worked well for me when trying to activate teams/units/orgs.

ndsipa_pomu 2y ago

> You only keep what you need for the time that you need it Just to add that it's stricter than that - you can only keep the data that is required for the purpose that you detailed to the customer. e.g. If you ask for their email address for password validation, then you're not allowed to use that email for other communication unless you explicitly asked for that as well.

oneplane 2y ago
I completely agree, GDPR is definitely a more detailed ruleset than what I outlined, but from a data management superset perspective you would have the mechanisms and facilities to deal with the GDPR-specific rules anyway. I've found that this is mostly a problem in organisations where data isn't managed, the government doesn't protect the people, or where some vague value is assigned to the data (so it does get stored, but when it leaks it is supposed to not have value and therefore do no damage). So looking at it from an "you will be managing it anyway" angle has worked well for me when trying to activate teams/units/orgs.