Examples of GDPR documentation in process4.biz models

This article describes documenting GDPR-related content in process4.biz models.

  1. process4.biz
  2.  
  3. Our Business Blog
  4.  
  5. Examples of GDPR documentation in process4.biz models

Abstract

The following article deals with the integration of GDPR-relevant documentation content into existing process4.biz models.

Instead of distributed documents and redundant content, process4.biz provides a central model database that categorizes content, provides dependencies/links and simplifies data administration.

For the use case of GDPR documentation, our flexible and highly customizable tool can offer significant benefits and added value:

  • no need for another tool
  • cross-site and department-wide collaboration in one central model database
  • fully automatic evaluation of GDPR relevance, based on the data objects used
  • use of existing documentation or parts of it (for example, process management, IT documentation)
  • one holistic solution free of redundancy for the documentation of the entire company, the GDPR is a fully integrated subarea
  • flexible reports with extensive input for the necessary GDPR documents

The examples described below intend to elaborate on these added values, communicating the concepts required and explaining the necessary changes.

Starting point

As a starting point for the integration of GDPR documentation content, an existing process4.biz model for process modeling and / or documentation of IT should be available. That means, that basic structures (= “classes”) such as process, role, application, etc., as well as links between these objects are already present in the respective model.

Our starting point for the following examples is the demo database, which is included in each of our releases in order to provide a variety of starter content and templates.

The settings, options and adjustments described below are examples that are not claiming to be 100% correct or complete - they are meant to be understood as ideas and impulses for existing p4b models. GDPR integration can be tailored to customer needs and requirements, conforming with corporate standards and notations.

Objectives

Our p4b model should be able to fulfill the following requirements in terms of GDPR documentation:

  1. Documentation of data processing
  2. Preparation of information related to the right of access by the data subjects
  3. Preparation for the records of processing activities

Data, Records and their processing

In order to be able to document data processing in greater detail, it can be useful to distinguish between Data and Record.

The structure could look like this:

HR Tool {
    Applicant {
        First Name, Last Name, Address, Photo, etc.
    }
}

The “HR Tool” used here is an Application, the “Applicant” is a Record and all attributes such as First Name, Last Name etc. are objects of the class Data. The two classes Data and Record can be created easily and their structure could look like this:

In order to be able to use these classes within the respective p4b model, the corresponding link rules are also required:

These rules control which other model content should be available as linked objects for Data or Record entities. The links created this way provide the proper foundation for all further dependencies and reports.

Object properties

In order to categorize Data and Records as personal data according to the GDPR, an extended scope of properties is required for the objects of these two classes.

Data objects contain the basic classification into personal data (yes / no) and can then be further classified as sensitive data (yes / no). Such a classification then prompts a selection of the corresponding Type of sensitive data:

In addition, the Data Protection Impact Analysis has also been implemented as a rudimentary example. This allows for further classification of the risk (according to predefined evaluation logic), which is associated with the storage or processing of the respective data.

Records can determine their attribute value Contains personal data? automatically, according to a formula (see below). It will be set to Yes if they contain data that has already been classified as personal data – this helps reduce manual maintenance and provides a clear hierarchy between Data and Records.

Based on the same kind of logic, it’s also automatically determined whether Applications are relevant for data processing and/or data storage. In this case however, objects from both classes (Data and Record) are considered.

Diagrams

In process diagrams, the Data or Records created can then be used for drag and drop modeling easily. The RACI method, used by many of our customers, can be utilized for this purpose when extended by another vertical swim lane (labeled Data):

If another notation is used, it will certainly be possible to find a suitable form of presentation for it. In that case, it could help to follow the presentation of roles, functions or documents in the respective notation.

If there is no process documentation in the respective model or the documentation of the data processing is driven by the IT, an application-based approach is also available:

Both variants can also be used in the same model, they even complement each other. The model database makes sure that the same objects are used and these objects effectively aggregate all links. The dependencies and links between data, processes and applications could then look like this, based on the two example diagrams above (example: Record Applicant):

If personal data is used in a diagram (in this example: process or application documentation), an indicator will automatically set Personal Data? (Yes / No) to its correct value, thus eliminating the need for manual user input:

A formula property provides this functionality, checking all the objects used on the diagram and their properties. This selection is then restricted to data and records. If personal data is found in the subset of objects, the chart is automatically set to the appropriate state:

Thanks to Visio, the “use of personal data” marker can be customized - in our example, it’s displayed in the header of the diagrams and looks like this:

If a visual marker is not necessary, this step can be skipped.

Reports

Solid documentation of Data, Records and their processing provides the structures and dependencies for all types of reports. Necessary GDPR documents such as the records of processing activities can then be created based on the information stored in the model database.

In order to query for Data and Records, as well as their use in Applications and Processes, we will utilize the QueryBuilder. This process4.biz extension provides custom queries based on all model content and their dependencies.

Data & Records

The first question is the processing and storage of Data and Records. In this case, our query is defined as coming from the Application and asking for the Data in the respective Records. The result could look like this for the “HR tool”:

This dimension can also be implemented without any documented processes, by means of application-based IT documentation only. It quickly provides added value when it comes to a request for information or the implementation of authorization/security concepts in regard to the applications used in a company.

Process context

If documented processes are also available in a process4.biz model, this process context offers a great source of relevant information. The purpose of data processing required by the GDPR may be derived directly from the respective process and also responsibilities, role or function-based permissions are often already available for processes.

As an example query for this case, the question of the processing of Data in individual Process Steps and their context (used application, process owner, roles and their responsibility according to RACI) are used. All the necessary data comes from the RACI flowchart for our recruiting process. The result looks like this:

Of course, it is also possible to stay at a higher level of abstraction instead of going down to the individual process steps in the query. Such a query could then ask for the process, the data processed and the respective purpose:

All queries can also be processed into documents with the Document Composer, conveniently based on customizable Microsoft Word *.dotx templates:

So, all of the examples above can be used as a starting point for further documentation required by the GDPR, like the records of processing activities. The key benefit is the model database though, providing powerful data management functionality and acting as a single source of truth. This reduces the amount of redundant documents in Microsoft Word or Excel and offers significant advantages due to individual data structures, templates, reports and visualization.

Within the context of the GDPR, a process model can offer significant advantages: all information required for compliant documentation can be stored, maintained and managed in one central database.

We hope that this article has given you some ideas regarding the possibilities of implementing GDPR documentation in process4.biz models.

We are happy to answer any questions, suggestions and feedback and we’ll gladly demonstrate the content described here live in our tool. We also offer consulting services for the implementation of GDPR documentation in your process4.biz solution. Just contact us here or via email.


In category: Use Case | Tags: dsgvo, content
Share this article: 

Related Articles

Digital Security Architecture

Published on 03.05.2019 | Read in about 15 min

The approach for a digital security architecture. Guest article written by Jimmy Heschl, Head of Digital Security at Red Bull.


  Read more

Our Customers

We'll gladly provide further information regarding the listed customers and their projects and we will also provide direct contact for professional exchange where possible.

  Show all References
ARTHUR KRÜGER GmbH
Streit Service & Solution GmbH & Co. KG
PETER-LACKE GmbH
IOI Oleo GmbH
Wüstenrot Datenservice GmbH
IT-Services der Sozialversicherung GmbH

  Stay in Touch