We describe how the declarative Dynamic Condition Response (DCR) Graphs proces notation can be used to digitalise the General Data Protection Regulation (GDPR) and make a rst evaluation to what extend the formalisation and associated tool for end-user modelling and simulation can be used to clarify the meaning of the GDPR and its consequences for the main business process of a Danish funding agency.
The digitalisation and use of personal data in organisations have increased and
is an integral part of almost any businesses or public organisation. The
legislation on the use of personal data, the Data Protection Directive (DPD) from
1995, has been superseded in 2016 by the General Data Protection Regulation
(GDPR) [
Below we brie y recap the de nition of Dynamic Condition Response (DCR) Graphs and the support for modelling and simulation using DCRGraphs.net.
As any other business process notation, the DCR Graphs notation allows for the modelling af business activities/events and the roles af actors who can carry out the activities. The key di erence between DCR graphs and e.g. BPMN diagrams is that one does not model the explicit sequence ow between activities. In Figure 1 is shown a DCR graph in the DCRGraphs.net tool modelling the activities and roles for an on-boarding process. The six activities are: GDPR Consent, Sign Contract, First day at work, Need for PC, Order PC, Receive PC. Each activity is assigned a role, e.g GDPR Consent is assigned the role Employee, meaning that only the employee can give the GDPR consent. The formalism allows that an activity can have any number of roles assigned, i.e. an activity without role re ects that the role is still unknown or unassigned, while an activity with more than one role denotes that di erent roles are allowed to carry out the activity.
The graph in Figure 1 has no constraints between activities, meaning that any activity can be carried out any time and any number of times. This means that any sequence of the activities is possible. If we want to constrain the ordering, we use the DCR graph relations between the activities. Figure 2 illustrates all the possible relations between activities in DCR graphs. The arrow with the bullet at the source, as the one highlighted in the gure from Need for PC to Order PC is the response relation, denoting that if Need for PC is carried out (meaning that the HR department registers that the new employee needs a PC, then the activity Order PC must eventually be carried out. As shown in the panel to the right in the gure, it is possible to add guards (making the response conditional on data), time deadlines, a level (making it possible to lter out relations when viewing a complex graph) and a description to the relation. The arrow with the bullet at the target, as the one from GDPR Consent to Sign Contract is the condition relation, denoting that GDPR Consent must be carried out before Sign Contract can be carried out. Similarly, condition relations constrain that Sign Contract must be carried out before Order PC and First day at work can be carried out. The arrow with the % sign at the target, as shown from Receive PC to Order PC and from First day at work to itself is the exclude relation. This relation denotes that if Receive PC happens, then Order PC is excluded from the graph and thus no longer relevant. The relation with the + sign at the target, as shown from Need for PC to Order PC means that Order PC is included in the graph and thus again relevant. This means that in this process, Order PC can happen any number of times until Receive PC happens, then it is required that Need for PC happens before Order PC can (and because of the response relation must) happen again. The exclude relation from First day at work to itself thus means that this activity can only happen once, since it can not be included again. Finally, the relation with the rombe at the end from Order PC to First day at work is the milestone relation, which means that as long as Order PC is required to happen (because of the response from Need for PC), First day at work can not happen.
The DCRgraphs.net tool allows for collaborative simulation of processes by hitting the green Simulate button at the top. During the simulation the state of the process is shown as a marking of the graph and a traditional swimlane diagram is dynamically showing the sequence activities that has happened during the simulation. The marking of the graph indicates with a green checkmark on an activity that it has happened at least once and a red exclamation mark that it is required to happen (e.g. required as a response) at least once more, unless it is excluded by another activity. Excluded activities is visualised with a dashed border. 3
In this section we brie y introduce the General Data Protection Regulation (GDPR) and show how key paragraphs are formalised as DCR Graphs.
Laws and policies have been implemented to protect this data and speci
cally personal data. In 1995, the European Parliament enacted into law a Data
Protection Directive with the intent of securing personal data. The directive has
been updated into what is now known as the General Data Protection
Regulation (GDPR) in 2016 with the regulation going into application on the 25th of
May 2018. [
Organisations are now expected to implement procedures that help facilitate privacy by design. Such procedures include the training of personnel in data security, reviews of policies, transparency, and internal audits, only to mention a few.
The GDPR includes provisions that promote accountability and governance. These complement the GDPR's transparency requirements. While the principles of accountability and transparency have previously been implicit requirements of data protection law, the GDPR's emphasis elevates their signi cance.
Data Protection O cer (DPO) is a new position implemented in the companies as the GDPR requires certain companies to appoint a Data Protection O cer (DPO) to ensure compliance within the company. These o cers should inform the organisation on the GDPR and maintain compliance internally. Furthermore, the o cer is the point of contact for the supervisory authority and the individuals whose data is being processed.
Data breaches can happen if the company is negligent or by a malicious outside source hacking into their database. These breaches has to be reported to a speci ed authority within 72 hours and to the individual if the breach is severe enough. The GDPR is lenient in the amount of information that has to be supplied as the breaches cannot be investigated fully within the 72 hour period. The report can therefore be supplied in stages as more information is uncovered. Handling of personal data is of course the key issue of the GDPR. The GDPR touches upon several rights of the individual as to how their data is being handled, what data is being used, what access they have to the data and what right they have over their personal data. The GDPR further strengthens the individual's rights of their personal data by allowing citizens to request deletion, anonymisation, recti cation of their data. Furthermore, the data subject (the citizen) have to be informed of how and to what end their data is being used and to give their consent to this. This consent can be withdrawn by the subject at any time, requiring the company to default on their data. The citizen also has a right to deletion which has been called The right to be forgotten. This right and other rights of the individuals are elaborated upon later.
We decided to make a distinction between the parts of GDPR which is about organisational compliance and process-oriented compliance. The deviation separates into two focus points: establishment of a process, and a process is in use. This distinction is necessary as to what exactly is to be modelled. Consent The freely given acceptance from a data subject
that an organisation use their personal data.
Data protection o cer An expert on data privacy who ensures GDPR compliance. Data subject A natural person whose personal data is used in an organisation. Natural Person A person.
Personal data Information that identify a data subject Privacy by design The concept that privacy is built-in the systems used by organisations. Regulation legislative act that must be implemented across the European Union. Data processing Any operation performed on personal data.
The process model template focus on process-orientated GDPR compliance. A process model template which contains the aspects of GDPR: Data Handling & Processing, Inquiry of Data and Data Breach, can be added as supporting process model to already existing process models. A supporting GDPR process for processes in use, must therefore be designed in such a fashion that it is compliance with the entire regulation, and model the lawful activity so that it can be implemented at organisations already using DCR. Though organisational compliance does not describe activities for a process model, it has important elements of which describes a behavior of the process. The part of GDPR which applies to when the process is in use is principles, accountability & governance, and privacy by design. It is further important to mention that according to ICO the part of GDPR used for set-up of the process should still be in state where it is always under continuous improvement (ICO.org.uk).
We chose to structure of the GDPR support process using seven broad terms: The Process Instance, Inquiry of New Personal Data, Requests from Data Subjects, Veri cation, Data Handling, Data Breach Handling, and Documentation. The process Instance is the process to which the GDPR process is a support process. Each Process Instance is a run-time process of with processing of personal data. Therefore the Process Instance is not a part of the GDPR process in itself, but included into the process model in order to understand the relation between the process and the GDPR support process. This is also the case when looking at Veri cation, as Veri cation is dependent on how the organisation works, and how the organisation is structured. Yet for Veri cation, it is requirement (explanation is given in the next section on fragments) to be able to verify if a natural person is the data subject of the process instance, and therefore also part of the GDPR support process. 3.1
Key GDPR paragraphs as DCR Graphs fragments A key point of using a declarative notation as DCR graphs is that the legal constraints, in this case the GDPR, can be formalised in the same notation as the business process, but the two formalisations can be made and veri ed independently of each other. Below in Table 2 we show the key fragments we formalised as DCR graphs.
We have used the ICO.org.uk interpretation of the articles as our basis for the formalisation. Below we give examples of some of these interpretations.
Consent have to be freely given, speci c, informed and an unambiguous indication of the individual's wishes. Individuals have a right to withdraw consent at any time. (ICO.org.uk) Reference in GDPR: Articles 4(11), 6(1)(a), 7, 8, 9(2)(a) and Recitals 32, 38, 40, 42, 43, 51, 59, 171 (GDPR, 2017) The formalisation in DCRGraphs.net is shown in Figure. 3.1.
The right to be informed encompasses your obligation to provide 'fair processing information', typically through a privacy notice. It emphasises the need for transparency over how you use personal data. (ICO.org.uk) Reference in GDPR: Articles 12(1), 12(5), 12(7), 13 and 14 and Recitals 58-62 (GDPR, 2017)
Individuals are entitled to have personal data recti ed if it is inaccurate or incomplete. If you have disclosed the personal data in question to third parties, you must inform them of the recti cation where possible. You must also inform the individuals about the third parties to whom the data has been disclosed where appropriate. (ICO.org.uk) Reference in GDPR: Articles 12, 16 and 19 (GDPR, 2017)
We only give example of one of the formalisations, namely the formalisation of the requirements regarding consents, which can be seen in Figure 3.1. The DCR graph uses a nesting activity, Request Consent, which contain ve activities Give Consent, Refuse Consent, Record Personal Data, Withdraw Consent and Purpose of Personal Data no longer valid. Give Consent is a pending response (the consent is requested from the Data Subject) and the milestone relation to Record Personal Data is disabling the recording as long as Give Consent is pending. Refuse Consent has an exclude relation to the nesting activity Request Consent, which means that the nesting activity and all activities inside are excluded. When Give Consent happens, it is no longer pending, which means that Record Personal Data becomes enabled. Also, the activity Refuse Consent is disabled, but Withdraw Consent is included, since it is now relevant for the Data Subject to withdraw consent. If Withdraw Consent happens then Give Consent and Delete/Anonymise Personal Data become required (due to the response relations) and Refuse Consent becomes included again. Note that Delete/Anonymise Personal Data is only included if some data was actually recorded. Finally, the deletion may also be required because the purpose seized to be valid, as indicated by the activity Purpose of Personal Data no longer valid which also has a response relation to Delete/Anonymise Personal Data.
We now describe the key feedback resulting from our presentations of the GDPR formalisation to a GDPR consultant and a case worker at a funding agency. The GDPR formalisation was evaluated independently of the Dreyer business case by presenting the formalisation to a consultant trained in DCR graphs, who works professionally helping companies getting compliant with the GDPR. His main comments were that the formalisation was indeed helpful to make the interpretation of GDPR precise, but also that the DCR graph notation required training to be understandable and useful. The organisation, Dreyers, is a fund that distributes grants for the furthering of architects and lawyers in danish society. They distribute grants for travel, education and projects to architects and lawyers. (Dreyersfond.dk, 2017) We received a DCR graph of Dreyers application handling process. This process is centred on the reception of an application for a grant which is then processed by a caseworker, lawyers, board members and an accountant. The use of DCR graphs as a tool for representing their process was created by Exformatics who also supplies their Electronic Case Management (ECM) system.
To present the GDPR formalisation for the case worker, we merged (by hand) the GDPR fragments with the business process of Dreyers fund. We then used the simulation feature of the DCR tool to present to the case worker how the business processes at Dreyer was in uenced by the GDPR. During the simulation, the case worker discovered the possible new activities she needed to handle during her daily work, such as the withdrawal of consent. An example swimlane from the simulation is shown in Figure 4.2. 5
The case study revealed both possible advantages and challenges using the DCR Graph notation and the DCRGraphs.net tool for digitalising the GDPR. On the positive side, the declarative DCR Graph notation supported seamless merging of the GDPR constraints with the existing business process of the Dreyer foundation. Also, the DCRGraphs.net tool allowed for easy simulation of the resulting DCR constrained business process jointly with the case worker. However, the graphical DCR notation for constraints posed challenges for consultants and case workers. Future work will be to work on a textual presentation of constraints, which would allow a representation of the GDPR constraints that resembles the representation in the regulation, which we believe would make it more accessible to lawyers and case workers. This will be tested with systematic studies of case workers and lawyers reading and modifying models. We are also working on methods for automating the merging of GDPR constraints and business processes based on data dependency diagrams.