Authors:
(1) Harshvardhan J. Pandit, ADAPT Centre, Dublin City University, Dublin, Ireland, and Cybersecurity and Data Protection Group, National Standards Institute, Ireland ([email protected])
(2) Jan Lindquist, Privacy and Security Group, Institute for Standards, Sweden ([email protected]);
(3) Georg P. Krog, Signatu AS, Oslo, Norway ([email protected]).
Table of Links
Abstract and 1 Introduction
2 Overview of ISO/IEC TS 27560:2023
3 Comparing ISO-27560, ISO-29184, and GDPR
4 Consent Records and Receipts using DPV
5 Supporting GDPR and DGA
6 Implementation Considerations and Future Work
6.1 Trust and Security
6.2 Using Records and Receipts with eIDAS and EUDI Wallet
6.3 Standard for PII Processing Record Information and 6.4 Technical Considerations in Managing Records and Receipts
6.5 IEEE P7012 Machine-Readable Privacy Terms
7 Conclusion and References
A Example of Consent Record with both required and optional fields
B Example of Consent Receipt with required fields from consent record
2 Overview of ISO/IEC TS 27560:2023
Goals & Scope ISO-27560 has two broad goals: to guide the recording of information about consent for processing of personal data in a form that is interoperable, open, and extendable, and to provide information to individuals. To implement this, it defines several requirements (as controls in ISO terminology) for ensuring the required information is maintained and is supported by appropriate processes within the organisation. ISO-27560 is stated as a supplement to the earlier ISO-29184, where ISO-29184 defines how information is provided via notices in order to request consent, and ISO-27560 defines how information is recorded for given consent and provided back to the individual (as receipts).
The objective of ISO-27560 is to define an information structure for consent record which contains: (1) Information about the processing of personal data; (2) Privacy notices where this information was provided; (3) How data was obtained; and (4) Events related to consent (giving, withdrawing, etc.). It also defines an information structure providing all or some of this information to the data subject in the form of a consent receipt. To support implementations, Annex A provides examples of consent records and receipts using DPV, and Annex B provides an overview of the different states or stages in ‘consent lifecycle’ – which is based on DPV’s consent states [14,12] and analysis of existing approaches [8,2].
Specific guidance on implementation such as the choice of technologies is not in the scope of ISO-27560, though its Annexes provide informative guidance on related topics. Annex C describes performance and efficiency considerations, Annex D describes format and encoding structures, Annex E describes security of records and receipts, and Annex G describes application in Privacy Information Management Systems (PIMS). Further uses of consent records or receipts, such as how data subjects can obtain consent receipts or maintain their own consent records is not described in ISO-27560.
Consent Records ISO-27560 defines Consent Record as the documentation of information about a data subject’s consent for the processing of their personal data in terms of the details about the processing as well as the interactions related to consent (e.g. giving or withdrawing it). Consent Records are an essential part of keeping records regarding whether consent has been obtained and is valid for processing, and to keep this information for correctly conducting processing relying on it. ISO-27560 as well as regulatory requirements such as GDPR Article 7-1 require maintaining consent records where consent is used as the legal basis. While GDPR Article 7-1 only states that consent should be demonstrable, ISO-27560 provides an information structure for how this information should be maintained and what processes should exist within an organisation in for this.
It is important to distinguish between a Consent Record with several relevant but distinct concepts. A consent record only refers to the information recorded regarding consent, whereas a Consent Notice refers to the notice and information provided to the data subject in order to inform them about the processing – such as while requesting consent. While there is a significant overlap between a consent record and a consent notice, there are key differences such as notices orienting information for human consumption (e.g. layering of dialogues to provide summaries and detailed descriptions) and dictating the manner in which consent is expressed (e.g. checkboxes for options and confirmation by clicking a button). In contrast, a consent record is not required to accurately reflect the manner in which this information was presented to the user, but to only record it in a manner that enables assessing whether the consent is given and if so for which processing activities.
This distinction is evident in ISO-29184 being the standard for consent notices – which specifies what information should be present in a notice and the manner in which it is presented. In turn, ISO-27560 only refers to notices to limit its scope to representing information necessary within a consent record. Therefore a consent record, despite containing a link to the notice, is not by itself sufficient to determine the validity of consent, and instead acts as the primary record containing information or links to information for conducting such assessments. Its primary purpose is therefore limited to supporting claims for who is the subject, who is the controller, what is the consent about (e.g. which purpose, what recipients), what is the state of consent (e.g. request, given, terminated), and where/when/how it occurred (e.g. accepted on specific timestamp).
A ISO-27560 conformant consent record typically has the following sections representing relevant information:
-
metadata about the consent record such as its identifier
-
the individual associated with the consent i.e. data subject
-
the subject of consent i.e. specifics of the processing of personal data such
as purposes, services, data categories, and storage conditions
-
entities involved e.g. data controller and third parties
-
relevant contextual information e.g. notice, rights, restrictions
-
provenance of events associated with the consent e.g. given, withdrawn
Under GDPR, the obligation to maintain records of consent is explicitly stated in Article 7-1 and Recital 42. This information includes, at a minimum, the identity of the Controller and the purposes of processing (Recital 42). Further, Articles 13 and 14 dictate the information that must be provided to the data subject which includes recipients, transfers to third countries, data storage periods and conditions, existence of rights (including consent withdrawal), and specific information regarding processing such as the use of automated decision making or profiling.
Consent Receipts ISO-27560 defines a consent receipt as an authoritative document that is used to communicate the existence of a consent record or to provide information contained within it. It is effectively an ‘authoritative copy’ of a consent record provided by one entity to another, where it may contain all or only some information from the consent record regarding the consent and its relevance to processing activities. Such receipts are useful to communicate the existence of consent decisions, and enable entities to exercise of rights or raise issues and complaint regarding processing activities.
Consent receipts are a relatively newer and under-utilised practice, with no legal requirements existing that refer to the concept (of receipts) or state how they should be used. In addition, the usefulness of receipts as information provided to another entity requires consideration of specific terms and norms particular to the domain or sector. ISO-27560 follows this by providing the flexibility for organisations to choose a suitable schema for their particular domain or use-case. It defines a minimal structure consisting of some fields representing the receipt metadata, but does not have any requirements on the information structuring within the receipt or its correspondence to fields within the record.
A ISO-27560 conformant consent receipt only requires a metadata section providing information about the consent receipt such as its identifier. Deciding on which additional information is to be provided and in what forms and using which structures is left up to implementing entities. In this guide, we presume that the consent receipt is intended for providing a copy of all information within the consent record.
According to ISO-27560, records are generated and maintained by organisations (Controller, Third Party), and are utilised to provide receipts to a Data Subject. In contrast, the Kantara Consent Receipts specification [ref], upon which ISO-27560 is based, defines Consent Receipts as being provided by a Data Subject to a Controller.
For practical considerations of this work, we make no presumptions or enact restrictions on the use of records and receipts. Any entity, be it a Controller or a Data Subject, can maintain their own consent record or issue receipts. Though the phrasing of some sections may imply the Controller as the implementing entity, it does not preclude another entity from also implementing ISO-27560.
Structure A Consent Record contains four sections as described below and depicted visually in Figure 2 (the terms used are based on the implementation of ISO-27560 for GDPR using DPV as described later in the article):
-
Header Fields: these provide metadata about the record e.g. its unique identifier and timestamp of creation. These fields also include information on the schema which dictates how the information in the record is structured and which fields are necessary/optional. ISO-27560 permits creation of different schemas to support varying use-cases and information requirements.
-
Processing Fields: these provide information about the processing activities e.g. purposes, personal data, storage durations, geographic locations and restrictions, link to privacy notice, rights, and others.
-
Parties Fields: these provide information about entities involved in the processing e.g. controllers, third parties, authorities. The party has an identifier which is used to link or associate it with fields in the processing section e.g. to indicate which party is the controller.
-
Events Fields: these provide information about consent events e.g. consent given, consent withdrawn. Information includes the type of event, time, duration, associated entity, and how it was expressed.
Each section contains fields which describe the information that must be represented along with the form (e.g. timestamp format) and its necessity (e.g. required or optional). Certain fields are expressed as references to other fields (e.g. ‘Controller’ in ‘Processing’ section is a reference to an instance or record in ‘Parties’ section).
The Consent Receipt in ISO-27560 contains only two required fields representing a unique identifier for the receipt and the schema version used for the
structuring of information. The information and contents are undefined and left to each implementor to specify. A receipt can optionally contain the entirety of the information within a consent record or can also contain multiple consent records or other information not within a particular consent record. Similarly, a receipt can be made to contain only references to information within a record without containing the information itself e.g. providing only the consent record identifier without the contents of the record itself.
Considering the practical application of consent receipts require them to provide information to data subjects, for the implementation described in this document, it is assumed that the consent receipt provides all information contained within a consent record i.e. a receipt is a copy of the record provided to another entity. This is in line with ISO-27560 guidance which states that the receipt may contain the same fields as that of a consent record, and that the mandatory fields in a consent record are also mandatory in a consent receipt. Further, ISO-27560 allows creating different ‘schemas’ (which we call ‘profiles’) to indicate changes in requirements and their interpretations, through which we provide profiles for our defined implementations.
