GDPR Compliant Consent Tracking for Health Applications

What is Consent Tracking and how Chino.io helps to implement it

Consent Tracking under the GDPR

Article
6 of the GDPR
defines the basis for the processing of personal data of European citizens.
The most common basis for application developers is to obtain a valid and informed consent
from their end-users.
The Article 4(11) of the GDPR states that a consent of a data subject must be any freely given,
specific, informed, granular, explicit indication of the data subject's agreement for the processing of her
personal data.

In addition, data controllers must provide a proof that data subjects have given
their consent lawfully. This means that developers (who either act as data controllers, or
develop applications for data controllers) need to keep record of consents, updates,
withdrawals, and be able to demonstrate their compliance if required by the supervisory
authority.

In case data controllers are unable to demonstrate that the data subject has given consent to the
processing, they can be fined up to 20M Euros, or up to 4% of the total worldwide annual
turnover
of the preceding financial year, whichever is higher (Art. 7).

In summary, to implement consent tracking correctly, developers must do the following things in
their apps and in their cloud platforms:

1. On Client side (in their apps): implement procedures to inform users about the processing
of their data and to collect their consent, and

2. On Server side (in their cloud): implement procedures to store and keep record of
collected consents in a legally valid manner.

While presenting and collecting the consent is a common procedure generally satisfied with a form
and a checkbox,
storing and having a legally valid history is not an easy and simple task.

On the server side, it is necessary to:

Keep record of:

- WHO consented - the name of the individual, or other identifier;

- WHEN they consented - a copy of a dated document, or online records that include a timestamp;

- WHAT they were told at that time about the current conditions for use. If consent was given orally, records should include a copy of the script used at that time;

- HOW they consented - a copy of the relevant document or data capture form. If consent was given orally, organizations should keep a note of it, which is made at the time of the conversation - it doesn’t need to be a full record of the conversation;

- WHETHER they have withdrawn consent - and if so, when.

Track changes: have the tracking of all edits that happen on a consent, such as updates of policies or withdraws of consents, and be able to show all the changes happened through time.

Ensure that there is no other mean of editing the consent if not through authenticated, authorized, and logged operations (check the ICO guidelines [7]).

Have valid proofs: as companion with the history tracking, you need a valid log that shows the authorized and authenticated operations performed to update the consent (check the ICO guidelines [7]).

To help developers on this task, Chino.io offers an extremely simple API that ensures
the compliance with all requirements and eliminates all risks in less than 5 minutes.

The consent that is stored contains references to the Privacy Policy, User-Id, Data Controller
Info (useful in case of multiple data Controllers using the same app),
purposes for data processing that a user has accepted, and the version of the policy.

FAQ

Prerequisite: consent already obtained with the old Directive (and national laws)

In cases where companies have already collected the consent for processing according to the older
Directive, they will need to reassess all the consents they have received,
to ensure they have been obtained lawfully and that they are able to provide proof of records.

Who needs to track Consents

In cases where companies have already collected the consent for processing according to the older
Directive, they will need to reassess all the consents they have received even before the GDPR came into
force, to ensure they have been obtained lawfully and that this can be demonstrated.

How to obtain a valid Consent

The GDPR provides also other basis for lawful processing,
however, those conditions can be typically met only by public authorities, research centers and
hospitals, since they are related to providing services of vital interests for a data subject.

To obtain a consent from a user, developers must give them a clear and full-scale
information about the processing, the choice to object to processing before developers do it,
but also a control over the further use of the personal data. Furthermore,
when it comes to processing of special categories of personal data,
the GDPR requires that the given consent is “explicit”.
For more info check Article 4(11), Article 7(1), and Article 7, 9, and in recitals 32, 33, 42,
and 43.

After May 25th 2018, it will no longer be enough only to obtain a consent in any form.
Data controllers will need to review all the consent mechanisms they already had in place,
and ensure that all the elements of the valid consent are covered in each and every case.

What "freely given" means

For a consent to be “freely given”, it is necessary that a data subject has the freedom to
make a real choice, and that there is no risk of deception, intimidation, coercion or any significant
negative
consequence (e.g. substantial extra costs) if he/she does not consent.
Request for consent must not be unbundled: it must be separated from other legal text.
Freedom reflects in the ability of the data subject to refuse or withdraw consent without detriment.
One example given to explain such case is that the controller needs to prove that
withdrawing
consent does not lead to any costs for the data subject and thus that no clear disadvantage for those
withdrawing consent exists.

Since the GDPR definitions are not enough to enable precise implementation,
these elements are further explained in the Article 29 Working Party Guidelines on Consent under
Regulation 2016/679, adopted on November 29.
(The Guidelines are currently in the form of a draft, yet to be finalized).

Therefore, the consent mechanisms should genuinely be of a voluntary and "opt-in" nature; silence,
pre-ticked boxes or inactivity do not constitute consent. Data subjects are provided with a
clear explanation of the processing to which they are consenting; this should be done in an
intelligible
and easily accessible form, using a clear and plain language and it should not contain unfair terms.

What "specific" means

In order for a consent to be “specific”, a data controller has to ensure a clear purpose
specification.
Pursuant to the Article 5(1)b, before obtaining valid consent, the processing needs to be determined
by a specific,
explicit and legitimate purpose. This requirement provides safeguards against a gradual widening
or
blurring of purposes for which data is processed after the data subject has agreed to the initial
collection of the data. Granularity in consent requests requires that a controller provides a
separate opt-in for each purpose, in order to allow users to give a specific consent for each specific purpose.
Every purpose should fulfil the conditions of consent with regards to clarity, specificity, and
other
elements of the consent, with the requirement of clear separation of information related to obtaining consent for
data processing activities from those related to other matters.

What "informed" means

According to the Article 29 Working Party, at least the following information is required in order to ensure
that the consent is “informed”:

- data subjects are provided with the identity of the controller;

- the purpose of each of the processing operations for which consent is sought;

- what (type of) data will be collected and used;

- the existence of the right to withdraw consent;

- information about the use of the data for decisions based solely on automated processing,
including profiling, in accordance with Article 22 (2)33; and

- if the consent relates to transfers, information about the possible risks of data transfers to third
countries in the absence of an adequacy decision and appropriate safeguards (Article 49 (1a)).

Explicit consent for processing sensitive data (e.g. health)

Digital health application providers have to deal with another GDPR challenge - they need to receive an
explicit consent from their users. The term “explicit” explains the way in which the data subject is
expressing their consent.

The Article 29 Working Party suggests that the best way to avoid doubts and potential lack of
evidence, is to obtain a signed statement of consent. However, having in mind the digital or online
contexts, a data subject may be able to issue the required statement by filling in an electronic
form, by sending an email, by uploading a scanned document carrying the signature of the data
subject, or by using an electronic signature. In theory, the use of oral statements can also be
sufficient to obtain valid explicit consent, however, it may be difficult for the
controller to prove that all conditions for valid explicit consent were met when the statement was recorded.

Another example from the 20 Working Party is the two-stage verification, where the data subject would
reply to a controllers email explaining the specific processing request, with the statement
‘I agree’. After the reply is sent, the data subject receives a verification link that must be
clicked, or an SMS message with a verification code, to confirm agreement.

How to keep records of consents

In each and every case, the burden of proof that the consent is obtained lawfully will be on the
controller.
The GDPR clearly outlines the explicit obligation for the controller to demonstrate that the data
subject has given his
consent, which why the data controller needs to keep such records,
and to demonstrate their compliance if required by the supervisory authority.

Recital 42 states: “Where processing is based on the data subject's consent,
the controller should be able to demonstrate that the data subject has given consent to the
processing operation.”

Consent creation and record keeping

The GDPR gives freedom to the controllers to choose the most appropriate manner to keep the required
evidence of the consent. However, the additional challenge lies in the obligation not to include
excessive amounts of additional data processing. The controllers need to have enough data to show a
link to the processing (to show that consent was obtained) but they shouldn't collect more
information than necessary.

With regard to the online context - a controller could retain information on the session in which
consent was expressed, together with documentation of the consent workflow at the time of the
session, and a copy of the information that was presented to the data subject at that time. It would
not be sufficient to merely refer to a correct configuration of the respective website.

For how long? As long as the data processing activity in question lasts, the obligation to demonstrate
consent exists. After the processing activity ends, proof of consent should be kept for no longer than
strictly necessary for compliance with a legal obligation or for the establishment, exercise or
defence of legal claims, in accordance with the Articles 17(3b) and (3e).

Consent updates

WP29 recommends, as best practice, that consent should be refreshed at appropriate intervals.
Providing all the information again helps to ensure the data subjects remain well informed about how
their data is being used and how to exercise their rights. When a new processing takes place, or
when an aspect of a current processing changes, the controller would have to seek new consent to
cover this new/updated processing. But even in the absence of any change, WP29 recommends, as a
best practice, consent to be refreshed at regular intervals.

Consent withdrawal

With the GDPR, it is all about notifying data subjects about their rights, implementing actions upon data subjects
requests, and also securing the information of such actions.
One of those rights is the right of data
subjects to withdraw their consents for processing, according to the Article 7(3) of the GDPR.

As a general rule, if consent is withdrawn, all data processing operations that were based on
consent and that took place before the withdrawal of consent - and in accordance with the GDPR - remain
lawful. If no other lawful basis to justify the processing (e.g. further storage) of the
data exists, then data should be deleted or anonymised by the controller.

For this reason, the right to withdraw the consent should not be considered identical to the right
to be forgotten. If the data subject wants all of her data to be deleted and the processing
for all of the data to be stopped, she can exercise her right to have data erased, as laid
down in Article 17(1b) and Recital 65.
WP29 recommends that controllers assess whether continued
processing of the data in question is appropriate, even in the absence of an erasure request by the
data subject. In cases where the data subject withdraws his/her consent and the controller wishes to
continue to process the personal data on another lawful basis, they cannot silently migrate from
consent (which is withdrawn) to this other lawful basis. Furthermore, any change in the lawful basis
for processing must be notified to the data subject in accordance with the information requirements in
Articles 13 and 14 and under the general principle of transparency.

How Chino.io can help on Consent tracking

To help developers on this task, Chino.io offers an extremely simple API that ensures compliance with
all requirements and eliminates all risks in less than 5 minutes.