WordPress.org

Make WordPress Core

Opened 20 months ago

Last modified 3 weeks ago

#44222 new enhancement

Add Archive state to data erasure requests

Reported by: garrett-eclipse Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Privacy Keywords: close
Focuses: administration Cc:
PR Number:

Description

Hello,

A suggestion for v2 of GDPR is to add an archive/trash state and list view to erasure requests.

Currently, the last state/phase in the erasure process is 'Completed' with the 'Next Steps' action being 'Remove request'.

This automatically prompts the admin to remove and clear the deck. In many if not most cases though the site holds backups which upon site failure will be used to restore the site/content and thus the users PII data. Under GDPR my understanding is the admin is required to re-remove the users data.

Backups are partially safe with GDPR because they are required for site security/integrity, but under retention can only be kept for a reasonable timeframe.

So I was thinking a way to safeguard admins would be to introduce a trash/archive which would have the action for Completed be 'Archive' instead of 'Remove'. This would place the request in the trash and remove from the 'All' view to reduce the clutter. On a new Trash view you're find these requests with the ability to delete permanently.

And I think I heard something about privacy settings at some point in slack which could allow a retention period setting for these archives be set and a cron to auto-remove. So admins would be able to have their database retention and erasure archive retention periods basically match. This would enable them to use the archive list, export it possible, and use it to re-remove users upon database restore.

Most of it is up to the admin to disclose their backup policy and how they'll re-remove users but would definitely help safeguard them from losing requests by running through the workflow too quickly.

Hope that mostly makes sense, mainly just wanted the idea out there.

All the best,
*Note: Most of this is to 'my understanding' so I defer to those more versed in the new regulations.

Change History (7)

This ticket was mentioned in Slack in #gdpr-compliance by desrosj. View the logs.


20 months ago

#2 @desrosj
20 months ago

Possibly related: #43912.

#3 @desrosj
19 months ago

  • Keywords needs-patch added
  • Summary changed from GDPR - Add Archive state to erasure requests to Add Archive state to data erasure requests
  • Version trunk deleted

This ticket was mentioned in Slack in #core-privacy by desrosj. View the logs.


18 months ago

#5 @desrosj
18 months ago

Related: #44707.

#6 @garrett-eclipse
18 months ago

As #44674 is being committed as just 'Delete' wanted to flag that if this moves forward then the verbiage mentioned in that ticket will need to be revisited if an Archive state is implemented.

#7 @xkon
3 weeks ago

  • Keywords close added; needs-patch removed

I'm a little confused here @garrett-eclipse.

You're mentioning that "Trash" / "Archive" would help on a case of database restoration, how would that be of help though if the database is restored? You're restoring a list that should already contain any "up to that point" requests but any newer than those would've been lost. That includes most likely a full database so everything "after that point" is lost.

The only way to be up to point in case of a backup restoration is by having an extra way of keeping all requests externally as their own backup system and this leads to a different option of being able to import/export your current requests for safekeeping if you wish to.

Am I missing anything on how a Trash action would be of help in this case? We already have all the needed statuses in my opinion for the list to keep itself "clean" as it is, an extra Trash status wouldn't make much of a difference in my opinion.

We can talk about an exporter/importer for the Requests in office hours if that's needed but that's a totally different solution. There have been previous discussions for a logging mechanism (similar to import/export solution) for this as mentioned in #43912, but that hasn't been moved forward either. I'd be more than happy to start discussions on that again though!

I'm marking this with a "close" tag for now but do tell me if I didn't understand something so we can discuss further :).

Note: See TracTickets for help on using tickets.