Add note to Consent-27560 guide for #243

- adds note to consent guide providing rationale for why past consent
  records must be maintained
- see meeting FEB-20

Co-authored-by: Georg P. Krog <[email protected]>

code/jinja2_resources/template_guides_consent_27560.jinja2

@@ -121,11 +121,17 @@
 
     <p>In order to assess whether an instance of given consent is valid thus requires keeping records of information regarding how the consent was obtained i.e. using the notice, and how the consent is being utilised i.e. the processing enabled through that consent. This same information is also required for the organisation to determine whether its processing activities should continue, e.g. depending on whether a particular user has given consent and whether it is still valid (e.g. hasn't expired or wasn't withdrawn). Such information that is documented and maintained regarding consent is called a <i>Consent Record</i>.</p>
 
+    <aside class="note" title="Necessity of maintaining records of past consent states">
+      <p>Consent records should also be maintained regarding past states of consent. For example, consider the situation where an individual gives their consent, then later withdraws it or the consent expires. After some time, the organisation  obtains consent from the individual again.</p>
+      <p>Here, the second collected consent is the latest state of consent, and if only that is maintained then the organisation cannot validly demonstrate that activities conducted before the consent was given are justified based on given consent. Further, the period between the applicability of the two consent instances is where the organisation should not have processed any personal data based on consent - which again cannot be ascertained or demonstrated without a record of consent for both initial and subsequent consent.</p>
+      <p>Therefore, going ahead, this document uses '<i>Consent Record(s)</i>' to refer to record(s) that represent information about all -- current and past -- consent states and not just the current state of consent.</p>
+    </aside>
+
     <p>Where the information is to be communicated to another entity, it can be provided in the form of a <i>Consent Receipt</i>, which is an authoritative copy of the consent record - similar to how a shopping transaction involves a merchant's copy and a <i>receipt</i> provided to the customer. Such receipts may provide only an acknowledgement of the transaction or also involve specifics of the contents of that transaction. Consent records have been a common practice within organisations for a while now, especially given their requirement in laws such as GDPR Article 7 - however the issuing of consent receipts is a relatively new and under explored activity.</p>
 
     <p>[[[ISO-27560]]] is a <a href="https://www.iso.org/deliverables-all.html#TS"><i>Technical Specification</i> (TS)</a> that "specifies an interoperable, open and extensible information structure" for recording the data subject's consent to processing of their personal data i.e. as consent records, and to provide this information i.e. as consent receipts. The specification lists <i>information fields</i> that represent specific information associated with consent, and requirements over the form this information can take e.g. format, number of values, and whether it is mandatory or optional to be present. A <i>[[ISO-27560]] conformant</i> implementation is one that fulfils all requirements by either storing information in the form prescribed by [[ISO-27560]], or by storing information in a form that can be converted or transformed to fulfil its requirements.</p>
 
-    <p>[[ISO-27560]] allows for changes to made to the fields, for example to suit and match domain-specific labels or descriptions, or to introduce additional fields or information types that are needed. Such changes, expressed as <i>schemas</i> or <i>profiles</i>, are still required to be compatible with the requirements of [[ISO-27560]], such as by requiring the same fields to be mandatory. This document, referred to as [[DPV-27560]], is a schema or profile of [[ISO-27560]], and is intended to enable the use of [[DPV]] to represent information for the implementation of consent records and receipts.</p>
+    <p>[[ISO-27560]] allows for changes to be made to the fields, for example to suit and match domain-specific labels or descriptions, or to introduce additional fields or information types that are needed. Such changes, expressed as <i>schemas</i> or <i>profiles</i>, are still required to be compatible with the requirements of [[ISO-27560]], such as by requiring the same fields to be mandatory. This document, referred to as [[DPV-27560]], is a schema or profile of [[ISO-27560]], and is intended to enable the use of [[DPV]] to represent information for the implementation of consent records and receipts.</p>
 
     </section>
 

guides/consent-27560.html

@@ -571,11 +571,17 @@ <h3>Consent Records and Receipts</h3>
 
     <p>In order to assess whether an instance of given consent is valid thus requires keeping records of information regarding how the consent was obtained i.e. using the notice, and how the consent is being utilised i.e. the processing enabled through that consent. This same information is also required for the organisation to determine whether its processing activities should continue, e.g. depending on whether a particular user has given consent and whether it is still valid (e.g. hasn't expired or wasn't withdrawn). Such information that is documented and maintained regarding consent is called a <i>Consent Record</i>.</p>
 
+    <aside class="note" title="Necessity of maintaining records of past consent states">
+      <p>Consent records should also be maintained regarding past states of consent. For example, consider the situation where an individual gives their consent, then later withdraws it or the consent expires. After some time, the organisation  obtains consent from the individual again.</p>
+      <p>Here, the second collected consent is the latest state of consent, and if only that is maintained then the organisation cannot validly demonstrate that activities conducted before the consent was given are justified based on given consent. Further, the period between the applicability of the two consent instances is where the organisation should not have processed any personal data based on consent - which again cannot be ascertained or demonstrated without a record of consent for both initial and subsequent consent.</p>
+      <p>Therefore, going ahead, this document uses '<i>Consent Record(s)</i>' to refer to record(s) that represent information about all -- current and past -- consent states and not just the current state of consent.</p>
+    </aside>
+
     <p>Where the information is to be communicated to another entity, it can be provided in the form of a <i>Consent Receipt</i>, which is an authoritative copy of the consent record - similar to how a shopping transaction involves a merchant's copy and a <i>receipt</i> provided to the customer. Such receipts may provide only an acknowledgement of the transaction or also involve specifics of the contents of that transaction. Consent records have been a common practice within organisations for a while now, especially given their requirement in laws such as GDPR Article 7 - however the issuing of consent receipts is a relatively new and under explored activity.</p>
 
     <p>[[[ISO-27560]]] is a <a href="https://www.iso.org/deliverables-all.html#TS"><i>Technical Specification</i> (TS)</a> that "specifies an interoperable, open and extensible information structure" for recording the data subject's consent to processing of their personal data i.e. as consent records, and to provide this information i.e. as consent receipts. The specification lists <i>information fields</i> that represent specific information associated with consent, and requirements over the form this information can take e.g. format, number of values, and whether it is mandatory or optional to be present. A <i>[[ISO-27560]] conformant</i> implementation is one that fulfils all requirements by either storing information in the form prescribed by [[ISO-27560]], or by storing information in a form that can be converted or transformed to fulfil its requirements.</p>
 
-    <p>[[ISO-27560]] allows for changes to made to the fields, for example to suit and match domain-specific labels or descriptions, or to introduce additional fields or information types that are needed. Such changes, expressed as <i>schemas</i> or <i>profiles</i>, are still required to be compatible with the requirements of [[ISO-27560]], such as by requiring the same fields to be mandatory. This document, referred to as [[DPV-27560]], is a schema or profile of [[ISO-27560]], and is intended to enable the use of [[DPV]] to represent information for the implementation of consent records and receipts.</p>
+    <p>[[ISO-27560]] allows for changes to be made to the fields, for example to suit and match domain-specific labels or descriptions, or to introduce additional fields or information types that are needed. Such changes, expressed as <i>schemas</i> or <i>profiles</i>, are still required to be compatible with the requirements of [[ISO-27560]], such as by requiring the same fields to be mandatory. This document, referred to as [[DPV-27560]], is a schema or profile of [[ISO-27560]], and is intended to enable the use of [[DPV]] to represent information for the implementation of consent records and receipts.</p>
 
     </section>