The European Union General Data Protection Regulation (GDPR) defines the principles to be met by organizations when processing personal data in order to guarantee data privacy. According to GDPR, consent is required for establishing a legal basis for processing personal data, if there are no other legal grounds for the processing. Besides any identifiable “natural” person, also known as data subject, has the right to withdraw the given consent to process his or her personal data at any time. It is the organization's responsibility to ensure consent and its revocation to demonstrate its compliance with GDPR. With respect to GDPR compliance, organizations can benefit from workflows as they might be used to ensure that consent is obtained before processing personal data. This paper addresses how to enable organizations to manage consent and revocation through their workflows.
The European Union General Data Protection Regulation (GDPR) limits the processing personal data unless it is explicitly allowed by law, or the data subject has consented to the processing [GDPR, Article 6]. In addition to this, the data subject shall have the right to withdraw his or her consent at any time [GDPR, Article 7(3)]. Organizations dealing with personal data of European Union citizens must be able to provide a proof of validity of obtained consent and revocation.
The principle of Privacy by Design (PbD) advocates that privacy should be considered as a first class citizen in the technology design and should be proactively embedded. In order to support PbD, organizations can take advantage of workflows by checking compliance of their workflow models with GDPR during design time. One of the significant benefits of using workflows is that it enables to capture how data is transmitted for what purpose at the conceptual level. We use Business Process Model and Notation (BPMN) to model workflows as it is a de-facto standard for business process modeling.
In this paper, we analyze the consent and its revocation under GDPR. Based on this analysis, we propose design patterns to integrate consent and revocation features in BPMN-based workflows.
The structure of the rest of the paper is as follows: Section 2 briefly presents our understanding of the consent and revocation under GDPR. Section 3 discusses the concept of workflows in our research. Section 4 gives an overview of our proposed approach. Section 5 gives a running example in the clinical domain to show the applicability of our approach. Section 6 reviews related works. Finally, Section 7 concludes this paper and discusses our future work and perspectives. 2
Consent and Revocation under GDPR Consent can be defined as “any freely given, specific, informed and unambiguous [...] clear affirmative action” by which a data subject agrees to the processing of his or her personal data [GDPR, Article 4]. Some data operations are lawful only if the data subject has given consent to this processing [GDPR, Article 6, §1(a)].
Organizations need to determine whether their data operations require consent
to be lawful. We use the term Consent Policy to define the statements to declare
whether a data operation requires a consent. In our article [
Definition 1 (Consent Policy) A Consent Policy CP contains policies which are represented as 2-tuples cp = (purpose, requiresConsent), where: – purpose is the reason for which data is collected, used, or disclosed; – requiresConsent ∈ {true, false} specifies whether data processing requires consent or not.
For instance, newborn hearing screening requires an explicit consent to be legitimate. However, an emergency case does not require consent as it is a subject of “vital interest” which means being necessary to protect someone’s life. Thus, CP contains policies (newborn-hearing-screening, true) and (vital-interest, false) accordingly.
For consent to be informed and valid, the data subject must be aware at least of the purposes of the processing and the identity of the data controller who determines the purposes Consent Form and means of the processing [GDPR, Recital Data Subject 42]. As an example, assume Hospital X wants Data Controller to use personal data of its patients for new- Purpose born hearing screening. Hospital X can use the following statement to inform its patients to obtain consent “We, as Hospital X, use your Fig. 1. Consent Form. personal data for the purpose of newborn hearing screening.”
We modeled Consent Form (illustrated in Figure 1) that retains the minimum required information to be valid. Consent Form can be elaborated with additional information such as the duration of the consent to give data subjects more control.
A data subject has the right to withdraw his or her consent at any time [GDPR, Article 7, §3]. Organizations are obliged to take appropriate actions to handle revocation. They have to stop any ongoing process instances which are affected by revocation. They should also delete the personal data, if the personal data is not used by any other purpose and becomes unnecessary after revocation. 3
Workflows: Platform to support GDPR Compliance
Data privacy, in general, focuses on how personal data should be handled. In
order to ensure data privacy in BPMN-based workflows, we worked on different
ways of data handling supported in BPMN [
purpose, {attribute-name} 1https://www.omg.org/spec/BPMN/2.0/ lists different means to handle data in BPMN which are via data object, data store, or message elements. We check these BPMN elements in a given workflow. We assume that data operations are all semantically annotated and semantic annotations include the purpose of the data operations.
After finding each data operation in a given workflow, we determine whether these data operations require consent according to a given Consent Policy (Definition 1). If there is a data operation requiring explicit consent and if there is no consent obtained before that data operation, there is a potential privacy violation. Our idea is adding a checking consent step beforehand to remove this potential violation. For this purpose, we designed a consent pattern which is shown in Figure 3. Data Controller asks the Data Subject for consent and the Data Operation is executed when consent is granted. Otherwise, the process terminates. Consent Form is modeled as it is shown in Figure 1, it contains the identity of Data Controller and the purpose of the Data Operation.
ask consent purpose, {data}
We address the question “when to obtain consent?” Our idea is to add consent pattern as late as possible which means adding it just before the concerned data operation. In this way, we intend to prevent the potential situations where consent is obtained yet never used. We argue that consent should be obtained only when it is needed. We raise also the question “what if there are multiple purposes within a given workflow?” When there are multiple purposes, consent should be given for all of them [GDPR, Recital 42]. Our strategy to handle multiple purposes is first checking whether the data operations with different purposes always follow each other. When they always follow each other, we create one aggregated Consent Form including all their purposes. If data operations do not always occur together, we create separate consent patterns for each of these data operations. The reason behind is again related to prevent the potential situations where consent is obtained yet never used. Creating separate consent patterns might increase the complexity of the workflows in terms of readability. However, a consent pattern can also be designed as a collapsed BPMN sub-process which provides a more compact view. Thus, we might increase the readability of the workflow.
t taa jceb D Su r e l taa ltro D on
C request consent revocation
Data Operations Sub-Process We consider Newborn Hearing Screening (NHS) procedure in Germany as a running scenario in order to illustrate our methodology. It is an optional procedure which requires the explicit consent of at least one of the parents or guardians of the newborn babies. After carrying out NHS, according to the result of the screening pediatrician either applies treatment or conducts further research. Processing personal data for the purpose of research also requires consent to be lawful. Figure 5 shows a BPMN diagram for our scenario. Take note that this BPMN diagram is not GDPR-aware which means there is neither consent nor revocation control.
ian newborn ic arrives r t a i d e P carry out
NHS NHS result bad result?
no NHS, {NHS-result} research, {NHS-result} yes require research? no
apply treatment yes conduct research
t n e r a P newborn n arrives a iiit c r a d e P
Fig. 6. Newborn Hearing Screening Diagram with Consent and Revocation.
In our scenario, there are two data operations with two different purposes which are NHS and research. We add separate consent patterns for each of these data operations because when the processing has multiple purposes, consent should be given for all of them. In our scenario, pediatrician do not always conduct research. Therefore, we do not ask consent for research and NHS at the same time. In order to manage revocation, we create the Data Operations Sub-Process including both data operations and we add handle revocation pattern for this sub-process. Handle revocation task is triggered by a revocation request by a parent. 6
Granting and revoking consent effectively has been the focus of several research
efforts over the last years. In the pre-GDPR era, one of the pioneers in this
field is Ensuring Consent and Revocation (EnCoRe) research project. Within
this project, one of the goals was to provide dynamic and granular options for
consent and revocation in system design [
We are convinced that it is fundamental to incorporate consent and revocation controls within the workflows of organizations that handle personal data to ensure their compliance with GDPR during the design time. In this paper, we presented our approach to adapt the BPMN-based workflows with the consent and revocation concepts under GDPR. As future work, we would like to work on how to automatically generate the consent forms by using the existing workflows and automatically transform the existing workflows into the ones which handle the consent and revocation efficiently. We are also interested in analyzing the optimality of our approach.