Personal data and GDPR

Introduction

Managing personal data in the context of GDPR allows the low-code platform to recognize personal data stored in a business application and automatically apply the appropriate processing rules.

In low-code applications, the data structure evolves dynamically. Therefore, it is crucial to clearly mark personal data at the data model level. Knowing which data is personal, the platform can handle it securely regardless of changes in the application's structure.

Store personal data in the data model in objects of type Person. This makes automatic identification and application of GDPR rules easier.

Minimizing data stored in the application

A very important principle is minimizing the amount of data stored in the application. The data model should store the minimum set of data. Any data that can be retrieved from source systems should be fetched dynamically using the providers.

Minimizing the data stored in the business application directly reduces the number of operations related to processing personal data carried out by the Eximee Platform.

Architecture

The Eximee Platform stores the data needed to run applications in many components. Data distribution supports system performance optimization: instead of relying on one central database for everything, Eximee builds smaller, dedicated databases optimized for specific tasks, e.g. projection databases feeding the task list. Each of these places must support personal data management. They do so in different ways, shown in the table below.

Place	Purpose	How does it support GDPR?
Data model	Handling low-code applications according to their definition.	For known customers: Automatic depersonalization of data carried out as part of integration with the organization's systems. For prospects: Fixed, limited data retention period.
Eximee BPMS	Controlling the flow of cases defined in BPMN notation.	Fixed, limited retention period for process data.
Formstore	Storing documents created during form completion together with attachments.	Fixed, limited retention period for business application data.
Task list	Optimal powering of task list views and functions (display, search, filtering, sorting...).	Automatic depersonalization of data carried out as part of integration with the organization's systems.
Case list	Optimal powering of case list views and functions (display, search, filtering, sorting...).	Automatic depersonalization of data carried out as part of integration with the organization's systems.
Registry	Optimal storage of data outside the context of a single low-code application.	Variable but centrally limited retention period for data saved by business applications.
Audit Trail	Exporting data for any consumers inside and outside the Eximee Platform.	Fixed, limited data retention period.
System logs	Enabling diagnostics and error handling.	A sensitive log stream containing explicitly marked personal data, handled by mechanisms available in the organization's infrastructure.

The key place in the platform architecture is the data model. This is where the low-coder defines the application data structure and marks objects containing personal data. The other platform components read these markings and apply the appropriate processing rules. The data model is also the central place for broadcasting data value changes, especially changes that depersonalize personal data. In this way, the platform ensures consistent application of GDPR principles throughout the entire lifecycle of personal data.

How components work together

1. The low-coder defines the data model and adds to it an object of type Person with fields marked as personal data.
2. The platform imposes the appropriate interpretation of personal data and takes it into account in dedicated personal data processing flows.
3. Execution modules apply the appropriate personal data protection mechanisms tailored to their purpose and processing context.

The low-coder does not have to implement data masking or auditing mechanisms. The Eximee Platform does it automatically.

GDPR principles supported by the platform

The platform supports key GDPR principles thanks to proper data model configuration and automatic execution mechanisms.

Data minimization

• Store only the personal data necessary to achieve the purpose.
• Use dynamic data sources where data can be read in real time.
• Limit the storage of personal data to the fields that must be saved in the model.

Right to erasure and portability

• The system enables personal data to be deleted upon request, in accordance with the retention policy.
• Personal data can be exported in a readable and portable format.
• Integrations with external systems help ensure compliance with GDPR processes.

Availability and control

• The platform logs access to personal data, making it possible to check who accessed it and when.
• Access control depends on the source of the data value:

  • data retrieved from external services — access control is handled by the external service;
  • data entered by users — access control is handled by the platform.

Data retrieved from external services should not be stored in the data model unless there are strong reasons to do so.

Example

Below is an example visualization of the data model with the object Person and marked personal fields.

[[screenshot: configuration-model-gdpr.png]]

Related documentation items

• Data Model - GDPR — detailed configuration instructions in the data model.
• Platform architecture — general information about the platform's structure and the distinction between the platform and the application.
• Business application — definition of a business application built on the platform.