GDPR Prinicpal 5 - How to delete data after storage period expires

1 month 4 weeks ago - 1 month 4 weeks ago #304644 by cliffvt
Kyle, thank you, that is encourging to hear and indeed appreciated. I agree that automation is not what is asked for to the fullest extent, but only tools that make it easy to comply.

So for example an Auto action that makes it possible to select for example all disabled subscribers, older than a certain date, for example T-xxx days (where xxx is entered as a variable) and then what should be deleted as a multiselect list. My biggest concern is that if we do delete a comprofiler record, but because it is manual, forget to delete all the associated data (such as CB Subs, past subscription records, comprofiler logs, baskets, payment records etc for that person) and the data is ever compromised or we are audited, then we are potentially in breach for not deleting ALL CB data wherever it may be hiding. A tool to do this for whatever reason, not only GDPR, would be very useful, and used with caution.

Thanks ever soi much for being pragmatic about this!
The following user(s) said Thank You: krileon
1 month 4 weeks ago - 1 month 4 weeks ago #304646 by beat
First of all, Thanks cliffvt, Kyle, and others in other GDPR threads, for taking the time and effort to dig into this complex subject and share your thoughts and insights here, it is highly appreciated and helps us all move forward. :)

Please keep in mind that inal (I am not a lawyer) and that this is not legal or business advice, just a background of my little and still evolving understanding about this:

About deleting CBSubs and user records: Keep in mind that some records might need to be conserved in some shape or form for very long time. And actually a variable time:

E.g. invoice records usually have a 5 to 12 years or more minimum retention time, and in some cases even longer, e.g. if you have an open procedure that pauses the maximum useful time of an invoice or of a record.

E.g. Possible monetary demands or fiscal inspections have a foreclosure time of X years depending on country (5 years or more is not uncommon and is country-dependant). And if any demand is opened within that time frame the need for the data extends indefinitely until the case is closed and last recourse delay is passed, and the delay for a follow-up case is also expired. Again, even automatable, the decision to delete the data should be at very least overridable for specific users.

So automating any deletion in users data needs to be looked carefully at.

GDPR's spirit is excellent for users privacy awareness and protection. But it is also sometimes contradictory. E.g. On one side you shouldn't track the user more than needed, especially if you track in a way that the user is identifiable, but on the other side for the once-maybe-needed proof of complying with GDPR one might be tempted to keep track of what the user has done on your site to prove that he was aware of the purpose of your site and thus agreed on the data retention. And that would be in contradiction of the GDPR. A privacy statement saying "For the purpose of proof of our compliance to GDPR, each of your mouse movement and click on our site will be recorded forever with your personal identifiable information" would probably defy the purpose of the GDPR. So we should be always keeping in mind the purpose and the spirit of the GDPR and have a balanced approach. Also GDPR is part of the EU laws framework and practice, which is fundamentally different of the anglo-saxon "idiot-proof" approach if I may paraphrase it in this oversimplified way. E.g. If the intent of the site is very clear and the amount of data collected is obviously needed for the intent of that site, there is no additional consent needed. So we should be careful to not overdo it with GDPR.

This is a much more general subject than just CB. E.g. GDPR also includes off-line governance processes.

it is also important as Kyle wrote it, that we use Joomla's 3.9 privacy framework in our implementation. E.g. Separate solutions and plugins for each component would not be following GDPR's simplicity requirement.

GDPR is about protecting the best interest of the user for his private data while allowing him to use sites for their intended use. We always need to keep the best interest of the user in mind in implementing your site and the GDPR requirements.

But isn't keeping in mind the best interest of the customers also one of the most important keys to a successful business ? :)

Beat - Community Builder Team Member

Before posting on forums: Read FAQ thoroughly -- Help us spend more time coding by helping others in this forum, many thanks :)
CB links: Our membership - CBSubs - Templates - Hosting - Forge - Send me a Private Message (PM) only for private/confidential info
The following user(s) said Thank You: nant, krileon, schrammelmann
1 month 4 weeks ago #304647 by krileon

So for example an Auto action that makes it possible to select for example all disabled subscribers, older than a certain date, for example T-xxx days (where xxx is entered as a variable) and then what should be deleted as a multiselect list.

You should be able to just filter CB > User Management then delete as needed. I really don't suggest using an auto action to automate it as it's extremely risky. I'm extremely worried that a simple bug or something of the sort in CB Auto Actions could result in mass deletion of users by mistake so I'm very hesitate to suggest anything like that. It does seam like it would be doable in CB Auto Actions, but I don't have any suggests for that at this time. Most likely you'd need to use Internal Users to loop an action through every user, but that's extremely heavy at this time since it has no batching functionality for now.

My biggest concern is that if we do delete a comprofiler record, but because it is manual, forget to delete all the associated data (such as CB Subs, past subscription records, comprofiler logs, baskets, payment records etc for that person) and the data is ever compromised or we are audited, then we are potentially in breach for not deleting ALL CB data wherever it may be hiding. A tool to do this for whatever reason, not only GDPR, would be very useful, and used with caution.

When deleting a user it does fire a trigger that various plugins can act on to extend the delete behavior. CB Activity, CB Gallery, etc.. all do this. CBSubs does to an extent, but having tested this it does appear we need to improve this behavior in CBSubs. Data clean up should be a straight forward and simple process for everyone as deleting a user in CB ideally should clean everything up elegantly.

For now additional data deletion can be done by acting on the onAfterDeleteUser trigger to extend the delete functionality to purge any other remaining data that you'd like. Please also let us know specifically what plugins (other than CBSubs) are not deleting their data to your satisfaction and will certainly take a look at improving their deletion processes.


Kyle (Krileon)
Community Builder Team Member
Before posting on forums: Read FAQ thoroughly + Read our Documentation + Search the forums
CB links: Documentation - Templates - CBSubs - Hosting - Forge - Incubator - GroupJive
--
If you are a Professional, Developer, or CB Paid Subscriptions subscriber and have a support issue please always post in your respective support forums for best results!
--
If I've missed your support post with a delay of 3 days or greater and are a Professional, Developer, or CBSubs subscriber please send me a private message with your thread and will reply when possible!
--
Please note I am available Monday - Friday from 8:00 AM EST to 4:00 PM EST. I am away on weekends (Saturday and Sunday) and if I've missed your post on or before a weekend after business hours please wait for the next following business day (Monday) and will get to your issue as soon as possible, thank you.
--
My role here is to provide guidance and assistance. I cannot provide custom code for each custom requirement. Please do not inquire me about custom development.
The following user(s) said Thank You: nant, schrammelmann
Moderators: beatnantkrileon
Time to create page: 0.203 seconds
Facebook Twitter Google LinkedIn