5 ms·

Does anyone know good best practices and software/DB patterns to model localized GDPR-compliance into global software systems? I know ASP.NET Core comes with s

by dtquad 2y ago

Does anyone know good best practices and software/DB patterns to model localized GDPR-compliance into global software systems? I know ASP.NET Core comes with some GDPR-related helpers but it's more interesting to know general best practices and patterns not related to a specific framework.

dacryn 2y ago
basically, make sure your data governance is on point. It should almost live outside of your software stack. Tools like collibra, purview, informatica, ... that know you database, are your best tools at enterprise level.
oneplane 2y ago
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.
AdamN 2y ago
First off, just presume GDPR applies globally. Then, know your legal 'zones' and by default keep all data in those containers. Thirdly, if you need to send data from one zone to another, ask "Do I really need to?? really???" and only if the answer is 'yes' do you do a proper design and engage legal and security from the beginning of the project through to the end and on an ongoing basis.
losvedir 2y ago
Yeah, I have to think things like DynamoDB Global Tables and other tools designed (in a bygone era) of "magic low latency from anywhere in the world" are going to be big footguns going forward.

by dtquad 2y ago

dacryn 2y ago

basically, make sure your data governance is on point. It should almost live outside of your software stack. Tools like collibra, purview, informatica, ... that know you database, are your best tools at enterprise level.

oneplane 2y ago

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.

AdamN 2y ago

First off, just presume GDPR applies globally. Then, know your legal 'zones' and by default keep all data in those containers. Thirdly, if you need to send data from one zone to another, ask "Do I really need to?? really???" and only if the answer is 'yes' do you do a proper design and engage legal and security from the beginning of the project through to the end and on an ongoing basis.

losvedir 2y ago

Yeah, I have to think things like DynamoDB Global Tables and other tools designed (in a bygone era) of "magic low latency from anywhere in the world" are going to be big footguns going forward.