=Paper=
{{Paper
|id=Vol-2575/paper4
|storemode=property
|title=Managing Consent in Workflows under GDPR
|pdfUrl=https://ceur-ws.org/Vol-2575/paper4.pdf
|volume=Vol-2575
|authors=Saliha Irem Besik,Johann-Christoph Freytag
|dblpUrl=https://dblp.org/rec/conf/zeus/BesikF20
}}
==Managing Consent in Workflows under GDPR==
https://ceur-ws.org/Vol-2575/paper4.pdf
Managing Consent in Workflows under GDPR
Saliha Irem Besik and Johann-Christoph Freytag
Humboldt-Universität zu Berlin, Department of Computer Science,
Unter den Linden 6, 10099 Berlin, Germany
{besiksal,freytag}@informatik.hu-berlin.de
Abstract. 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.
Keywords: Data Privacy · General Data Protection Regulation (GDPR)
· Consent · BPMN · Business Process Compliance
1 Introduction
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.
J. Manner, S. Haarmann, S. Kolb, O. Kopp (Eds.): 12th ZEUS Workshop, ZEUS 2020, Potsdam,
Germany, 20-21 February 2020, published at http://ceur-ws.org/Vol-2575
Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License
Attribution 4.0 International (CC BY 4.0).
Managing Consent in Workfows under GDPR 19
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 [1], we gave a formal
definition for Consent Policy in Definition 1.
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 pur-
poses of the processing and the identity of the
Consent Form
data controller who determines the purposes
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 hear-
ing 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.
20 S.I. Besik and J.C. Freytag
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 [2]. Data is represented in BPMN
via data object, data store, or message elements1 (shown in the left-hand side
of Figure 2). In order to check the privacy compliance of a workflow, for each
of its data operations it is essential to know explicitly which personal data is
accessed for which purpose. We expect organizations to provide this information
via semantic text annotations. Right-hand side of Figure 2 illustrates how we
semantically annotate the data operations, where purpose refers to the purpose
of accessing data and attribute-name refers to a set of attribute names of data
which are accessed. For example, < marketing, {name, age} > annotation means
name and age data attributes are accessed for the purpose of marketing.
Data Handling Semantic Annotation Usage
in BPMN for Data Operation
Data Task
Data Object
Store
purpose, {attribute-name}
Message
Fig. 2. Data in BPMN.
4 Approach
Our idea how to manage consent and revocation is to propose design patterns
that are integrated into BPMN-based workflows. As we explained in Section 2,
some data operations are legitimate only with the consent of a data subject. As
a first step, we determine the data operations in a given workflow. Section 3
1
https://www.omg.org/spec/BPMN/2.0/
Managing Consent in Workfows under GDPR 21
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 (Def-
inition 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.
Subject
Data
purpose, {data}
Consent Form
Data
Operation
consent is granted
Controller
ask consent
purpose, {data}
Data
Data
consent is rejected
Fig. 3. Consent Pattern.
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
22 S.I. Besik and J.C. Freytag
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.
Subject
Data
request consent revocation
Data Operations Sub-Process
Controller
Data
revocation is requested
handle revocation
no erase the
stop all running check if withdrawn
processes withdrawn data
regarding data is
revocation necessary yes
Fig. 4. Revocation Pattern.
Figure 4 shows our design pattern to handle revocation. We create a sub-
process which includes all data operations because the consent withdrawal can
be related to any of the data operations. We also add a “handle revocation” step
for the created sub-process. Handle revocation task is triggered by withdrawal
request by a data subject. Handling revocation implies to stop any ongoing
process instances affected by the withdrawal request of the data subject and to
erase the personal data if the personal data is not necessary anymore.
We developed both consent and revocation patterns in a way that no additional
BPMN symbol is required. In this way, our approach can be easily applied to
existing BPMN-based workflows.
5 Running Example
We consider Newborn Hearing Screening (NHS) procedure in Germany as a
running scenario in order to illustrate our methodology. It is an optional procedure
Managing Consent in Workfows under GDPR 23
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.
bad result? require research?
carry out yes no apply
NHS treatment
Pediatrician
newborn no
arrives
yes
NHS, {NHS-result}
NHS conduct
result research
research, {NHS-result}
Fig. 5. Newborn Hearing Screening Diagram without Consent and Revocation.
Figure 6 illustrates the BPMN diagram for newborn hearing screening which
includes consent and revocation controls.
Parent
NHS, {NHS-result} research, {NHS-result}
Consent Form Consent Form
Data Operations Sub-Process
bad result? research?
carry out yes yes
ask consent
consent is granted NHS
ask consent consent is rejected
no no
newborn
arrives
Pediatrician
apply
consent is rejected treatment
consent is granted
NHS, {NHS-result}
NHS conduct
result research
research, {NHS-result}
revocation is requested
handle
revocation
Fig. 6. Newborn Hearing Screening Diagram with Consent and Revocation.
24 S.I. Besik and J.C. Freytag
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 Related Work
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 [3][4]. They also provided conceptual
modeling for privacy policies with consent and revocation requirements [5].
Their understanding of consent differs from ours as they do not reflect on the
requirements and obligations based on GDPR. Also, they have no work regarding
the use of workflows to handle consent and revocation. [6] proposed the idea of
the alignment of workflows with consent management. Their aim was, however,
generating the letter of consent documents based on existing workflows. In the
literature, there are also studies where BPMN is extended towards security
and privacy aspects [7][8]. However, these works do cover neither consent nor
revocation. [9] presented a set of design patterns as business process models
which enables organizations to tackle GDPR constraints. Their work can be
considered as a guide to achieve GDPR compliance for an organization. Our work
considerably differs from their work because we aim to transform the existing
non-privacy-aware business process models into privacy-aware ones.
7 Conclusion and Outlook
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.
Managing Consent in Workfows under GDPR 25
References
1. Saliha Irem Besik and Johann-Christoph Freytag. A formal approach to build
privacy-awareness into clinical workflows. SICS Software-Intensive Cyber-Physical
Systems, pages 1–12, 2019.
2. Saliha Irem Besik and Johann-Christoph Freytag. Ontology-based privacy compliance
checking for clinical workflows. In Proceedings of the Conference on ”Lernen, Wissen,
Daten, Analysen”, Berlin, Germany, September 30 - October 2, 2019, pages 218–229,
2019.
3. Marco Casassa Mont, Siani Pearson, Gina Kounga, Yun Shen, and Pete Bramhall.
On the management of consent and revocation in enterprises: setting the context.
HP Laboratories, Technical Report HPL-2009-49, 11, 2009.
4. Ioannis Agrafiotis, Sadie Creese, Michael Goldsmith, and Nick Papanikolaou. Reach-
ing for informed revocation: Shutting off the tap on personal data. In IFIP PrimeLife
International Summer School on Privacy and Identity Management for Life, pages
246–258. Springer, 2009.
5. Marco Casassa Mont, Siani Pearson, Sadie Creese, Michael Goldsmith, and Nick
Papanikolaou. A conceptual model for privacy policies with consent and revocation
requirements. In IFIP PrimeLife International Summer School on Privacy and
Identity Management for Life, pages 258–270. Springer, 2010.
6. Nils Gruschka and Meiko Jensen. Aligning user consent management and service
process modeling. In GI-Jahrestagung, pages 527–538, 2014.
7. Wadha Labda, Nikolay Mehandjiev, and Pedro Sampaio. Modeling of privacy-aware
business processes in BPMN to protect personal data. In Proc. of the 29th Annual
ACM Symposium on Applied Computing, pages 1399–1405. ACM, 2014.
8. Alfonso Rodrı́guez, Eduardo Fernández-Medina, and Mario Piattini. A BPMN
extension for the modeling of security requirements in business processes. IEICE
transactions on information and systems, 90(4):745–752, 2007.
9. Simone Agostinelli, Fabrizio Maria Maggi, Andrea Marrella, and Francesco Sapio.
Achieving gdpr compliance of bpmn process models. In International Conference on
Advanced Information Systems Engineering, pages 10–22. Springer, 2019.