Add Archive state to privacy requests

[garrett-eclipse]

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.

[desrosj]

Possibly related: #43912.

[desrosj]

Related: #44707.

[garrett-eclipse]

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.

[xkon]

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 :).

[garrett-eclipse]

Hi @xkon

The concept of introducing an archive state to the requests workflow was one that went around quite a bit on Slack and some Trac ticket mentions. Primarily @desrosj and @allendav were contributors who I've discussed the concept with.

With the current workflow one issue flagged early one was the fact users were trigger happy and would click the remove request button as soon as it became available deleting the request. In many cases these requests should be kept for some period of time for auditing and logging purposes.

The idea of database restoration here was mostly to integrate the archived requests with a plugin such as the one you built here;
​https://github.com/mrxkon/personal-data-request-backups
This way users could retain in archive their complete requests, export externally and in the case of database restoration they could pull in their exported requests to re-erase needed requests.

Even if users don't opt for the security of an external export the archive state is beneficial in that it cleans up the requests table of completed requests without fully removing them from the system which in some legislations will assist with audits and proving requests have been completed.

Trac references to mentions of this functionality;
https://core.trac.wordpress.org/ticket/44674
https://core.trac.wordpress.org/ticket/44707
https://core.trac.wordpress.org/ticket/44500#comment:3
https://core.trac.wordpress.org/ticket/44266#comment:2
https://core.trac.wordpress.org/ticket/44068#comment:7
https://core.trac.wordpress.org/ticket/43912#comment:4

Slack references;
​https://wordpress.slack.com/archives/C9695RJBW/p1527615516000016
​https://wordpress.slack.com/archives/C9695RJBW/p1527615406000355

Happy to discuss further here or on Slack but do believe this would be beneficial to users so am removing the close tag.

[garrett-eclipse]

Updated title as this should be implemented for both exports and erasures.

[davidbaumwald]

@garrett-eclipse Is this still on your list to work in in 5.5? Beta 1 is in less than a week, and that is the deadline for Feature Request and Enhancement type tickets.

[davidbaumwald]

With Beta 1 landing tomorrow, this ticket is being moved to Future Release. If any maintainer or committer feels the remainder of this ticket can be resolved in time, or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.