One of GDPR Lawful Bases for Processing Personal Data (and that means Collect; Access; Store; Process and Share) is Consent.

Companies must have documented proof of Consent as per defined under GDPR Article 7 where it reads "... controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data..."

So the question is How can Companies demonstrate in a documented manner that Consent was provided by the Data Subject, meaning the natural persons to whom Personal Data pertains?

The identity of the data subject and not someone else.

  • 2
    Possible duplicate of How to Prove, Legally, That a User Actually Clicked the "I Accept" for TOS, etc
    – user4657
    Jun 15, 2019 at 4:54
  • Disagree with the duplicate. The linked question deals with matters concerning the content of the license, and the possibility of the terms not being accepted due to the organization of pages on a website. This question appears to be concerned with the identity of the data subject, i.e. not someone else.
    – MSalters
    Jul 15, 2019 at 14:50

2 Answers 2


"Shall be able to demonstrate" means what it says. It does not mean having a signed piece of paper.

Typically your database will have a boolean field with "True" indicating that the user has clicked the "I consent" button at some point. Gathering this information is trivial. The difficult bit is demonstrating that the database fields reflect reality. For instance, what if someone ran a query to modify these fields?

Part of the GDPR is a documented design process where you consider questions like this. Possible approaches to this particular problem could include:

  • Record the user IP address or other identifiers along with the date and time. Not conclusive, but much harder to do as a mass forgery and impossible to do by mistake.

  • Institute access controls on your database so that the number of people who could modify this data is kept as small as possible. Train these people in their responsibilities and ensure they have a separate reporting line in case someone puts improper pressure on them.

  • Log user access to the database so that any manual changes have an audit trail.

  • Keep your website software under version control and have processes to ensure that a known and approved version is running at all times. That lets you prove that the consents you gathered were genuine (as opposed to some rogue code in your backend setting the consent flag regardless).

  • Include consent (or lack of it) in your test scripts. Verify that your software correctly records consent (or not) before going live with a new version.

The objective is to be able to show a hypothetical inspector arguments and evidence to support your claim that all your recorded consents are genuine.

If you find your arguments and evidence becoming unwieldy then you might consider using a notation like GSN or Toulmin to organise them. A sign that you need one is when you start writing sentences like "if P then Q, except for R, but then S and T, which only leaves U".

  • Well Paul, I can relate to your remarks from a technical operational assurance perspective (meaning I agree with all of them)... now the point still remains; clicking a button on a website does not allow the univocal identification of the person who did it as the Data Subject... anyone can do it while pretending to be the Data Subject... and the IP address also does not prove who is "on the other side of the line". Jun 13, 2019 at 16:46
  • Unless the person has logged in (registered username and password) before clicking the button of consent... that is :) Jun 13, 2019 at 16:48
  • 1
    @RuiFreitasSerrano That's true of a signed piece of paper too. You don't know the signature was written by the data subject and not somebody else. Jul 16, 2019 at 10:21
  • What you have to ensure is that you have done what was within your power to univocally identify the Data Subject... and if you do not, then your documented Consent is not documented, so it becomes a problem for you since it is a non-conformity point. Jul 17, 2019 at 17:21
  • If it is impossible to use an app without giving consent does it serve as any proof?The consent is legitimate and it is impossible to prevent fraud without consent. Nov 8, 2020 at 17:11

Relevant to GDPR article 7 (1) is Recital 32:

Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject's agreement to the processing of personal data relating to him or her, such as by a written statement, including by electronic means, or an oral statement. This could include ticking a box when visiting an internet website, choosing technical settings for information society services or another statement or conduct which clearly indicates in this context the data subject's acceptance of the proposed processing of his or her personal data. Silence, pre-ticked boxes or inactivity should not therefore constitute consent. Consent should cover all processing activities carried out for the same purpose or purposes. When the processing has multiple purposes, consent should be given for all of them. If the data subject's consent is to be given following a request by electronic means, the request must be clear, concise and not unnecessarily disruptive to the use of the service for which it is provided.

Important is that consent was actively given and to all purposes. A checkbox can already be enough, although not a pre-ticked one.

The ICO gives examples in How should we obtain, record and manage consent? on how to record consent, in accordance with GDPR article 7 (1):

You keep a copy of the customer’s signed and dated form that shows they ticked to provide their consent to the specific processing.

You keep records that include an ID and the data submitted online together with a timestamp. You also keep a copy of the version of the data-capture form and any other relevant documents in use at that date.

You keep records that include the time and date of the conversation, the name and date/version of the script used.

These are ways to keep an audit trail in case you are getting challenged.

Piotr Foitzik of the IAPP writes in How to verify identity of data subjects for DSARs under the GDPR:

This means that you also should consider how sensitive the data is and what are the risks. The more sensitive the data, the more effort to authenticate is expected. This is in accordance with the risk-based approach, and you can justify asking for more information or more critical or sensitive information if you do this to protect the data subjects against possible risks to their rights and freedoms.

The whole article is worth reading, but the above quote is possibly the most relevant to your question. You are concerned about imposters. How do you know that some John Smith who consented is actually John Smith and not someone else?

First of all, keep in mind the principle of data minimisation (GDPR article 5 (1.c)). This is important when you collect data in the first place, but also when you want authenticate data subjects.

As you noticed, the GDPR is doesn't got that much into detail about how consent is to be given. The reason is that the method depends on the collected data. The more sensitive, the more you need to make sure the data subject consenting is actually the data subject they claim to be. On a site users can use basically anonymously, e. g. just a pseudonym and a throw-away email address, a check box may well be enough. If you want to collect more sensitive data, you need more. But this is rather broad and depends too much on the data etc. But you'd probably have to show that you undertook reasonable effort (borrowed from GDPR article 8 (1) on child's consent) to verify the data subject's identity. But what is reasonable again depends.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .