9

I have been reading alot about user consent management according to the GDPR and one problem I can't see solved anywhere is managing withdrawn consent.

The user gives his consent to use his data and save personal information like his E-Mail address, IP address, ...

If the user withdraws his consent I would have to somehow store this decission in my database to make sure I always have proof of a prior consent and at which date the user has withdrawn his consent. But how do I keep track of a withdrawn consent if I can't save any personal information to identify this person anymore. Isn't this a contradiction? Always having the ability to prove everything but being forced to delete all saved data records?

Is there any part of the GDPR I am missing, that solves this specific problem?

  • 4
    But if a user withdraws consent, and you delete all his data, then you no long have any reason to be storing any data about him. Why do you think you would need to store the fact (and date) that this user has withdrawn consent? You'd need to prove that you do have consent to store data, not that you don't have consent (and presumably therefore don't have any data stored). Or am I missing something? – brhans May 7 '18 at 21:10
  • 4
    @brhans perhaps the data processor wishes to protect against a later claim that the user never gave consent, which could be based on some evidence that the data processor had previously stored the user's data. – phoog May 7 '18 at 21:37
  • 3
    @brhans like phoog said - if data was used when consent was given and there is a later claim that we did this without a given user consent we need some kind of proof that it was given at a specific date. – jvecsei May 7 '18 at 21:51
  • 1
    I don't know anything about the law, but from a technical standpoint, this seems pretty easy to solve. If a user sues you, they would presumably have to identify themselves. So just concatenate their full name and other identification info (username? user ID? national ID number? whatever works) and store the SHA256 checksum in your database, along with the date on which consent was given or withdrawn. Maybe include the timestamp in the hash too (but include it outside as well). And, in your agreement, require the user to agree to provide these pieces of identification in potential litigation. – Mehrdad May 8 '18 at 4:01
  • 1
    The problem ist that it is somehow reproducable by brute forcing you can reproduce data and it is still "linked" to an individual. I have read different opinions on this. Of course it's not a realistic scenario but there is no official statement to hashed data specifically. – jvecsei May 9 '18 at 14:51
7

This could be covered by point 1(c) of Article 6:

  1. Processing shall be lawful only if and to the extent that at least one of the following applies:

...

(c) processing is necessary for compliance with a legal obligation to which the controller is subject;

...

It might also fall under point 1(f):

...

(f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.

It is difficult to know whether any particular processing of data falls under either of these points because of the lack of relevant court decisions.

The latter is particularly slippery, since whether any interest is "legitimate" is at least partly subjective, and whether any interest of the data processor overrides the data subject's interests, rights, or freedoms, is even more so.

I should also note that point 1(a) is the point that requires user consent, so the other points explicitly take the place of consent rather than being somehow required alongside consent:

(a) the data subject has given explicit consent to the processing of those personal data for one or more specified purposes, except where Union or Member State law provide that the prohibition referred to in paragraph 1 may not be lifted by the data subject;

2

We've been struggling with a similar issue. For us, we will need to store the ID of the user, so we can delete them from backups if we need to restore them.

So delete the user's data (everywhere), keep a reference of the ID of the deleted user (or deleted data if you're not referencing via foreign keys in a database) for when any future restores happen so you can re-run those deletes.

That is, of course, specifically around the "Forget Me" feature (article 17), and not around restriction of processing, etc.

  • 2
    If you're keeping the data in backups that require a re-deletion, you haven't actually deleted it, the data is still stored and available. – Nij May 8 '18 at 7:43
  • 1
    Agreed, but a lot of the "best practices" and advice advise that where it is impractical to delete from backups storing an audit log to prevent them being created again is the next best option. Not perfect but on the advise we've received it makes us compliant – BenFreke Jun 7 '18 at 22:33
0

You don’t have to delete the records - just anonymize them.

Users are stored with an ID number. When user 45632 revokes consent simply delete all personal information (name, email, IP address etc) associated with them. You can keep user 45632 in the system because there is no personal data associated with them.

  • 1
    How would that help if someone alleges that the data processor processed their data without consent? Wouldn't the data processor have to be able to show that user 45632 is the person making the allegation? – phoog May 8 '18 at 1:33
  • yes, I also don't see how this solves my problem. If i can't prove that user 45632 is person XYZ then this information has no value... – jvecsei May 8 '18 at 14:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.