When need I to display consent and should deprecated consents be stored?
<p>When the law requires consent screen to be displayed for user? Should it be displayed only for third party applications (e.g. signing to stackoverflow by google account) or is it also necessary for first party apps?</p>
<p>And if user give consent, can we store only latest consent for a specific client or rather store all consents given, e.g. even these given before 2015 year?</p>

<p>Summary: Consent may be necessary also for first-party processing activities. Since you have a duty to prove that you received valid consent, it may be necessary to keep longer-term records.</p>
<h2>Consent is one legal basis among many</h2>
<p>When processing any personal data within the scope of the GDPR, it is necessary to have a “legal basis”.</p>
<ul>
<li>Clearly, you can process data for the purpose of fulfilling a contract with the user, such as providing a service that the user requested.</li>
<li>And using the data as legally required is also fine, for example keeping financial records for tax purposes.</li>
<li>Some processing activities are not core to providing the application's service, but might be necessary for a “legitimate interest”. This requires conducting a “balancing test” where that interest is weighed against the interests and rights for the user. For example, keeping security logs is typically covered by a legitimate interest.</li>
<li>Finally, some activities are not strictly necessary and cannot be reasonably expected by users. Then, it is necessary to ask the user for their consent. For example, you might need consent for sharing data with an ad network. Or for loading an embedded YouTube video (but I repeat myself). Many applications can work just fine without ever having to ask for consent.</li>
</ul>
<p>In some cases, consent is legally mandated in order to alert the user. Such consent is often necessary when dealing with “special categories” of data, such as health information.</p>
<p>Consent is also mandated when storing or accessing information on the user's device, unless this is strictly necessary for a service explicitly requested by the user (and thus expected by the user). This is known as the “cookie law”, but it applies to any technical means to access/store information, and also applies if the information doesn't qualify as GDPR personal data.</p>
<p>When trying to obtain valid consent, a number of criteria must be fulfilled. Consent is a freely given, specific, and informed indication of the data subject's wishes. You can't coerce the user. You can't make access to a service conditional on unrelated consent.</p>
<h2>Demonstrating that you obtained valid consent</h2>
<p>Importantly, it is <em>our</em> responsibility as a data controller to demonstrate that you obtained valid consent. I would separate this condition into two parts:</p>
<ul>
<li>existence: demonstrate that you obtained consent from that user</li>
<li>validity: demonstrate that you obtained consent in a valid manner</li>
</ul>
<p>For demonstrating validity, you might save snapshots from the consent flow of our application, showing that the user was sufficiently informed and that they could decline consent without detriment. You should be able to reproduce what the user was told at the time.</p>
<p>For demonstrating the existence of consent, it is common to keep explicit records: when did who give consent, with which version of the consent flow? When was the consent withdrawn? Sometimes, this is done by storing a history of consent-related events, and retaining them for later auditing.</p>
<p>You don't have to go overboard here. You can decide how you can demonstrate consent appropriately given the circumstances of your applications.</p>
<h2>Relation between consent and technologies like OAuth or device permissions</h2>
<p>Some technologies impose consent flows. For example, mobile OSes and web browsers will ask the user for consent before microphone or location access is granted to an app/website. OAuth authorization flows will generally ask the user for consent to authorize some third-party application to perform some actions.</p>
<p>Such technological flows may be part of a GDPR consent flow, but are not sufficient to achieve GDPR consent. For example, the user might not have sufficient information from the consent flow alone in order to make an informed decision.</p>
<p>It is also possible that the user has to go through a consent flow for technical reasons, even though you don't need consent from a GDPR perspective.</p>
<h2>Further reading</h2>
<ul>
<li><a href="https://gdpr-info.eu/art-7-gdpr/" rel="nofollow noreferrer">Art 7 GDPR “Conditions for consent”</a></li>
<li><a href="https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en" rel="nofollow noreferrer">EDPB guidelines 05/2020 on consent (PDF)</a></li>
<li><a href="https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/consent" rel="nofollow noreferrer">UK ICO guidelines on consent</a> (technically only UK GDPR, but often more actionable than EDPB advice)</li>
</ul>

gdpr