GDPR Compliant Consent Tracking for Health Applications|

GDPR Compliant Consent Tracking for Health Applications

What is Consent Tracking and how 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, offers an extremely simple API that ensures the compliance with all requirements and eliminates all risks in less than 5 minutes.

Check how the Consent Tracking API works

With the Consent API developers can:

  • Store a consent via 1 API call;
  • Update the consent;
  • Delete the consent;
  • Search by User-Id (can be an also external User-Id e.g. e-mail);
  • Get the full history of operations on consents of users;
  • Get the legally valid audit log in case of legal issues.

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.

Check how Consent Tracking API works


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 can help on Consent tracking

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

Check how Consent Tracking API works

Still have questions?

Check our FAQ