Proof of Consent under GDPR, HOW TO?
<p>One of GDPR Lawful Bases for Processing Personal Data (and that means Collect; Access; Store; Process and Share) is Consent.</p>

<p>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..."</p>

<p>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?</p>

<p><strong>The identity of the data subject and not someone else.</strong></p>

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

<p>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?</p>

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

<ul>
<li><p>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.</p></li>
<li><p>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.</p></li>
<li><p>Log user access to the database so that any manual changes have an audit trail.</p></li>
<li><p>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).</p></li>
<li><p>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.</p></li>
</ul>

<p>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.</p>

<p>If you find your arguments and evidence becoming unwieldy then you might consider using a notation like <a href="https://modeling-languages.com/goal-structuring-notation-introduction/" rel="nofollow noreferrer">GSN</a> or <a href="https://en.wikipedia.org/wiki/Toulmin_method" rel="nofollow noreferrer">Toulmin</a> 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".</p>

<p>Relevant to <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&amp;from=EN" rel="nofollow noreferrer">GDPR</a> article 7 (1) is Recital 32:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Important is that consent was <em>actively</em> given and to <em>all purposes</em>. A checkbox can already be enough, although not a pre-ticked one.</p>
<p>The ICO gives examples in <a href="https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/consent/how-should-we-obtain-record-and-manage-consent/" rel="nofollow noreferrer">How should we obtain, record and manage consent?</a> on how to record consent, in accordance with GDPR article 7 (1):</p>
<blockquote>
<p>You keep a copy of the customer’s signed and dated form that shows they ticked to provide their consent to the specific processing.</p>
<p>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.</p>
<p>You keep records that include the time and date of the conversation, the name and date/version of the script used.</p>
</blockquote>
<p>These are ways to keep an audit trail in case you are getting challenged.</p>
<p>Piotr Foitzik of the IAPP writes in <a href="https://iapp.org/news/a/how-to-verify-identity-of-data-subjects-for-dsars-under-the-gdpr/" rel="nofollow noreferrer">How to verify identity of data subjects for DSARs under the GDPR</a>:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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?</p>
<p>First of all, keep in mind the principle of <strong>data minimisation</strong> (GDPR article 5 (1.c)). This is important when you collect data in the first place, but also when you want authenticate data subjects.</p>
<p>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 <strong>reasonable effort</strong> (borrowed from GDPR article 8 (1) on child's consent) to verify the data subject's identity. But what is reasonable again depends.</p>

privacy gdpr confidentiality