GDPR – Personal Data Administration process

Facebooktwittergoogle_pluspinterestlinkedinmail
Applies to version 2017.1.3.x; Author: Bartłomiej Spyrka

SDK configuration for an ‘Administration process’ used to find and manage personal data

1. Introduction

This article presents methods of utilizing features available in WEBCON BPS version 2017.1.3.x to prepare a process for GDPR-related data management. In this article you will learn:

  • How to approach the Administrative process which is used to track down a specified user’s personal data
  • Which WEBCON BPS features can be used when designing a process
  • How to configure SDK and actions related to GDPR
  • How to perform data deletion/anonymization in BPS processes
  • How to collect information about stored personal data
  • How to obtain information about all personal data usages in the system

It is important to notice, that GDPR introduces changes in personal data protection, but does not impose strict rules that must be adhered to in a specific company. The solution presented in the following article is not an A-Z guide but rather a suggestion. You can base your own configuration on it so that your company works in accordance to GDPR ruling.

 

1.1. Concept

The entire workflow is presented in the diagram below. However, this article will not cover the configuration of the entire process. The process should be modeled according to your personal needs.

In this article, we will concentrate on the features dedicated to GDPR, how to configure them, and how they work.

In the next part we will focus on the instance’s journey through the various paths of the workflow:

  • Register a request – input basic data
  • Personal data search
    • Methods of searching through the database and saving the results on the form
  • Select person – specifying which users returned by the search will be processed further
  • Remove data – the final step in which the data anonymization/removal is being conducted

 

1.2. Actions and plugins

Most recent WEBCON BPS version 2017.1.3.x  provides a dedicated SDK toolkit for GDPR. All the plugins are located in the WebCon.WorkFlow.Extensions.GDPR class.

Tools provided:

  • 4 SDK actions which are used for operating on data sets
  • 1 action – anonymization/data removal
  • 3 custom data sources which are used for providing data to Data Table (SQL Grid) reporting controls

 

1.2.1. Action searching through process-type personal databases (based on BPS process)

WebCon.WorkFlow.Extensions.GDPR.Actions.FillPersonalDataItemList

1.2.2. Action searching through external personal databases (other than BPS process)

WebCon.WorkFlow.Extensions.GDPR.Actions.FillPersonalDataItemListCustomData

1.2.3. Action deleting attachments along with their history

WebCon.WorkFlow.Extensions.GDPR.Actions.RemoveAttachmentWithHistoryAction

1.2.4. Action saving specified user IDs to a technical field

WebCon.WorkFlow.Extensions.GDPR.Actions.SaveIdsToTechnicalField

1.2.5. Custom source – collecting personal data

WebCon.WorkFlow.Extensions.GDPR.DataSources.DictionaryDataReportDataSource

1.2.6. Custom source – personal data usage

WebCon.WorkFlow.Extensions.GDPR.DataSources.ElementsGridDataSource

1.2.7. Custom source – external personal data sources usage

WebCon.WorkFlow.Extensions.GDPR.DataSources.ExternalElementsGridDataSource

1.2.8. Action– delete personal data

This is a normal BPS action, it is available in the standard way (analogous to all other actions)


 

2.Example of workflow configuration

2.1. Process in a nutshell

Illustration 1. Register step – preliminary ticked registration.

 

A form with very basic data was created on the first step. Based on this form the user in charge (GDPR administrator) of ticked handling should have enough information to correctly isolate the specified elements. Those elements will become keywords for which a search will be conducted throughout “Personal data dictionaries” (external databases and processes).

Illustration 2. Personal data search

 

In the next step, the user in charge of ticket handling should:

  • Type in search keywords which will lead to identifying the user who requested data rectification
  • Words should be typed in the “Search” field
  • Keywords should be divided by a “space” i.e. “John Locke 4815162342”
    • The space between the keywords matters because the system takes into consideration every inputted word and searches for it separately. For example, if it finds at least one of the aforementioned words it will present a result (finding all the keywords is not necessary)

 

Illustration 3. Phrase search results – two instances were found, one matching both keywords, and one matching one

As you can see on the screenshot above, all results matching at least one of the keywords “star mike” (capitalization doesn’t matter) were aggregated on the item list (“Select person”). In case of finding more than one match, more records will be presented and will be added to the table.

Illustration 4. Table with search results

The table consists of following columns:

  • Select (checkbox column) – used for selecting the search result(s) which we want to process
  • Link – leads to workflow instance (if the search result belongs to the dictionary based on a WEBCON BPS process)
  • Field name – displays the Form field names in which the searched values were found (in this case name and surname)
  • Value – displays the values which matched the searched keywords
  • Dictionary – displays the name of the personal data dictionary in which the specified record was found

Next, the process should be able to store the user IDs chosen by the administrator into a technical field. The selected data will be presented in a table one last time for the administrator to confirm, and then proceed to the anonymization/data removal step.

Illustration 5. Form view just before anonymization/removal

 

Choosing any of the predefined paths will cause the corresponding action.

Anonymization will cause personal data in the dictionary instance (and all instances which obtained data from that dictionary instance) to be obfuscated as shown below (applies only to dictionaries based on BPS process):

 

Illustration 6. Anonymization result in an instance that obtained data from a personal data dictionary

 

2.2. BPS configuration

In order to be able to save identified records you need to:

  1. Create a text field for inputting keywords (Input/search)
  2. Create an Item list with columns for data
    • The Item list has a very simple construction. When searching the data source (which is also a BPS process), it is possible to create a technical column which stores the instance ID (WFD_ID). Then in a different column, create a hyperlink which will take you to the selected workflow instance.
  3. On the transition path, configure an action searching the dictionaries and saving results to the Item list. An example is shown below:

In the advanced mode, it is possible to compare the variables found in the ‘column ID’ and ‘Searched data’ configuration fields. This is important when analyzing how the ID’s of fields in which results are saved are transferred – and how information is loaded from the form.

 

If we want to search external data sources we need to use an action dedicated to that purpose. The difference in the configurations is that when searching an external data source, you must first specify which external data source you wish to search.

  1. Name
    1. Column name in the data source
  2. Searching
    1. Defines if the system should search by a specific column (by phrase)
  3. Visibility
    1. Specifies if a selected column [name] will be visible on the search result list
    2. If the column was marked as false, but at the same time it was searched by the system – the result will be shown on the Item list

In the next step, the user should specify which records will be further processed.

This is done by selecting a record on the Item list (by ticking a checkbox). From the perspective of WEBCON BPS and for further processing, this will copy the IDs to a technical field, from where these IDs can be used for future actions. To copy IDs we will use one of the available SDK actions .

Illustration 7. Action which copies IDs of selected instances from the Item list to the technical field

 

The action works by copying the user IDs (found in _ElementID) from the specified Item list (Select person) from selected rows (Select), grouping them and copying to a technical field (_SelectedPearson) – together with a ‘;’ separator. If we select many rows, the IDs will be stored as follows: ID1;ID2;ID3; and so on.

On the form we can display reports (Item list – fueled by Custom sources) which present two groups of information:

  • Dictionary data – presents data which is connected with a specified ID (loaded from the personal data dictionary). The dictionary itself and filters are configured on the level of Item list form field

 

Configuration – it is done via creating an Item list form field and building a filter. In this filter, we will provide the user ID which is relevant to the request (here is an example with [_SelectedPearson])

Illustration 8. Configuration of Item list form field (SQL Grid) – Collected data

 

Illustration 9. Filter configuration on a Data source

 

  • Related workflow – presents all occurrences of the user’s ID (WFD_ID) with links to specific instances which also contain mention of the user’s ID

Configuration – it is carried out in the same way as in the case of data from the personal data dictionaries. The only difference is the usage of a Custom source (using personal data).

Illustration 10. Custom source configuration for Item list (SQL Grid) form field presentation

 

Illustration 11. Item list presenting occurrences of the user’s ID in various process instances

 

Illustration 12. Form view after the user ID (identifier of the user who wishes to be deleted from the system) has been locked in

 

Deleting personal data:

The final procedure involves using an action that anonymizes/removes the specified data from the current content database.

In the [Delete personal data] action configuration, point to User/Users IDs which are to be processed (multiple IDs should be divided by semicolons).

 

The action can work in two modes (switch between them by using the checkbox in the configuration) – it can affect data from WEBCON BPS processes that are marked personal data dictionaries, or data from external data sources (that have been marked as personal data dictionaries):

  • Configuration for sources based on the WEBCON BPS process
    • In the configuration, we need only to specify the technical form field which contains the user IDs (WFD_ID).  These IDs are then going to be located in all processes that have at least one dictionary form field marked as sensitive/personal data.
      Configuration examples:

Illustration 13. This form field is marked as containing personal data, which is loaded from the Employee recruitment process

 

Illustration 14. The Employee recruitment process is marked as a Personal data dictionary, thus making it a source of personal data

 

Illustration 15. Sample configuration of an action that removes personal data from all process-based ‘Personal data dictionaries’

 

  • Configuration of actions that remove personal data from external data sources – not based on WEBCON BPS process
    • Once the ‘External personal data source’ checkbox is marked, it is possible to specify the data source which serves as the ‘Personal data dictionary’ in two ways:
      • Static data source selection (choose from a list)
      • Dynamic data source selection – choose <Calculable> from the list, and then use a rule or variable that will return the ID of the desired data source {DS.:174}) – this method allows one action to be used on multiple sources and can be looped, for example by using a Flow control (branch) step.

The cleaning mode that will be used by default is the one set in the ‘personal data dictionary’ configuration (either process or data source). However, a different cleaning mode can be set for each form field individually, this will overwrite the cleaning setting in the dictionary.


 

3. Summary

As you can see, the configuration of processes, actions, and data sources that handle personal data is not much more complicated than the configuration of regular processes. The whole challenge lies in correctly identifying which processes and data sources serve as Personal data dictionaries, and then marking form fields and Item lists columns which load data from these dictionaries.

By correctly identifying form fields that carry vulnerable data in your system and creating a trail of connections that always lead to a personal data dictionary, we can create an airtight solution. No matter where the personal data is used, we can always trace its origin to an instance of a Personal data dictionary – and removing/anonymizing this instance in the dictionary will also purge its data in every place that it was used. A well-thought-out solution will allow you to quickly and accurately find and manage personal data in your WEBCON BPS system.

Leave a Reply

Your email address will not be published. Required fields are marked *