How do we find a balance between keeping the simplicity of a consent, i.e. making sure that the data subject reads and understands to what they they are giving consent, while at the same time, having a consent that is complete, specific and detailed enough to be legally valid and to cover everything that is needed to delineate the consent.
A few suggestions were made:
separate the metadata and the categorisation of the consent;
create a concise and an expanded representation of the consent;
create trees/hierarchies for personal data categories.
During the 2nd thematic workshop the group concluded that a (i) concise and (ii) detailed version of the consent needs to be provided. The user should be able to choose which version he reads.
The concise version should not be more than 2 paragraphs and has everything in it (purpose, time, frequency, data, type of request…). It would be ideal to work with some clear guidelines on what should be in it and how it should be formulated. This should help for the end-user to get used to the form of the request and understand the consent more easily. It is important to standardise the obliged fields (e.g., always put a date as DD/MM/YYYY).
In the detailed version, a breakdown should be given of the origin, the content of the data, the metadata... This detailed versions target audience are experts and the objective is mainly compliance.
How do we find a balance between keeping the simplicity of a consent, i.e. making sure that the data subject reads and understands to what they they are giving consent, while at the same time, having a consent that is complete, specific and detailed enough to be legally valid and to cover everything that is needed to delineate the consent.
A few suggestions were made: