Description
We have not implemented any management commands for cleansing expired consent.
This could be invoked daily as:
python manage.py consent_cleanup
After running the command, we should not find any unnecessary data stored about a user who has withdrawn all their consent. For instance their name and email.
Depending on interpretation, it may be important to avoid deleting all opt-out data, as users may have given their strict NEGATIVE consent for being contact, i.e. setting the is_everything=True flag. In this case, we may retain a unique hash of the user's email. This design may be overturned if we find a better pattern for it.
The design and implementation of a consent_cleanup command remains open: Exactly what does it do, and how do we know which data to anonymize.
- Should there be a basic consent object for "handle my user account", which will automatically expire when there are no other active consents?
- How often should the command run (perhaps this is regulated by GDPR)
- Should this command be configurable, for instance in case a consent is related to storing of other data?
Description
We have not implemented any management commands for cleansing expired consent.
This could be invoked daily as:
After running the command, we should not find any unnecessary data stored about a user who has withdrawn all their consent. For instance their name and email.
Depending on interpretation, it may be important to avoid deleting all opt-out data, as users may have given their strict NEGATIVE consent for being contact, i.e. setting the
is_everything=Trueflag. In this case, we may retain a unique hash of the user's email. This design may be overturned if we find a better pattern for it.The design and implementation of a
consent_cleanupcommand remains open: Exactly what does it do, and how do we know which data to anonymize.