New Request Statuses?
kevinschoon opened this issue · 4 comments
It is foreseeable that processors will encounter some scenarios where because of an administrative or technical reason it is unable to fulfill a request.
There are currently only four states a request can be in:
- pending
- in-progrress
- completed
- cancelled
Would it be reasonable to add unsatisfiable and failed to this list?
@kevinschoon how would you describe those statuses and under what circumstances should they be used? Failed seems obvious, but I am unclear on unsafisfiable. We are taking care to not leak information such as an identity that does not exist.
@akatz0813 I see, is it expected that requests between a controller and processor would be masqueraded from the data subject? Is there a scenario where a data subject would interact directly with a processor?
Because requests can take a non-trivial amount of time to process (seconds to weeks) there is potential to enter a state where they cannot be processed.
failed would indicate the request entered a state (as you would imagine) when something went wrong during request fulfilment that cannot be recovered.
unsatisfiable would indicate the request entered a state when the processor was once willing to satisfy the request but now explicitly refuses. One example might be that the data was already deleted or the request was flagged by the processor for some reason (the latter seems somewhat nefarious..) Maybe this is too detailed and could just be rolled into failed.
In both scenarios as you mention it could be better to be intentionally opaque from a privacy perspective but also not being able to communicate failure seems wrong.
Because requests can take a non-trivial amount of time to process (seconds to weeks) there is potential to enter a state where they cannot be processed.
The regulation says that you must delete the data within 30 days.
Is there a scenario where a data subject would interact directly with a processor?
Nope. The regulation specifies the controller in detail. The controller tells the processor what he has to do with the data and what is allowed for him. Also when to delete or change what. So, the controller is basically the owner of the data. While the processor can only process the data in the way the controller tells him to.
https://advisera.com/eugdpracademy/knowledgebase/eu-gdpr-controller-vs-processor-what-are-the-differences/
I created a pull request for error responses. It makes also from my perspective sense to have something like this. #41
Closing this old issue without additional conversations