GDPR - Guide

General

IS Tools is a cloud service for the creation and management of custom database applications. When the information managed within the application contains personally identifiable information (PII), the IS Tools' customer is the controller for this information, and need to cater for a lawful processing.

IS Tools is responsible for the technical and organizational measures for the software service in accordance with the General Data Protection Regulation (GDPR), which relates to accessibility, encryption and authentication. More information on security on our website. More information on GDPR on IMY and on eur-lex.

The IS Tools' customer is responsible for the information stored within the application, as well as the application access permissions for this information in regards to the application's users. The IS Tools' customer is usually the controller for their own information.

This article serves as a guide on how to configure an application containing PII.

In the text, terms are tagged using emphasized text, and configuration is tagged with code markup.

Easy to understand

The permissions setup for PII should be well documented and easy to understand. It should be possible to quickly assess which users are permitted to access PII. We therefore recommend using at least one role specifically for this purpose. No other roles should have access to PII.

Roles

Create a role with permission to access only PII with a relevant name, for instance PII-READ. Do not relate any other information than PII to this role. With this configuration all users having this role assigned to them will be permitted to access PII. It is possible to divide the PII in domains, for instance geographical areas, within the application. Such division can be accomplished by creating a role for each area, for instance BERLIN and HAMBURG. The roles for the different areas should be configured so that a user requires a combination of the PII-READ and for instance HAMBURG to get permission to access PII in the Hamburg area.

We also recommend creating a role for creating or importing PII into the application, for instance PII-CREATE.

Role Administration
1. In the adminstration interface Role Administration it is possible to assess which users are permitted to access PII.

Limiting Access

The information in an IS Tools application is organized into tables and fields, which in a table component in a form can be viewed in a 2-dimensional structure with columns and rows. The fields, which all store a particular data type, are transformed into columns. Each row with all information is referred to as a record. All records have a unique identifier, an ID.

Table 1
2. An example table where record GUSK02 and field Surname are selected.

The permissions required for accessing the information is configured both by record and by field. If the application is configured with PII in a separate table the permission configuration is simplified, since it is enough to configure permissions for accessing the records. Permission to access all fields in the table for PII will then be granted for users with relevant PII-role assigned.

Records in IS Tools are saved in record groups. It is easy to configure storing records from a particular table in a designated record group. Permissions to access record groups are managed with the administration interface Manage Record Groups.

Manage Record Groups
3. The administration interface Manage Record Groups.

In figure 3 an example permission configuration is shown for allowing access to records in the table Contact stored in the record group PII. Read-only access to the records for the role PII-READ is configured with only one attribute ’S’ (select).

The role PII-CREATE is configured with all attributes: ’S’, ’U’, ’I’ och ’D’. Permission to read records is provided by the 'S' attribute; permission for changing existing records is provided by the 'U' (update) attribute; permission to create new records is provided by the 'I' (insert) attribute and the permission to delete existing records is provided by the 'D' (delete) attribute.

Other roles, in this case only ADMIN and USER, shall not be permitted any access for the record group PII, why no attributes have been selected for these roles and this record group. The assignment of role PII-READ is required for read-only access to PII, and the assignment of PII-CREATE is required for permission to create/change and delete PII.

When PII exist in tables together with other information, the administration interface Field Rights must be used to limit access to PII.

Table 2
4. This figure shows PII in a table component together with other information.

The administration interface Field Rights is used for managing permissions for accessing fields.

Field Permissions
5. This figure shows the administration interface Field Rights.

The configuration in figure 5 shows how the role PII-READ is permitted read-only access to the fields: Address, Surname, First Name, City and Postal Code.

The role PII-CREATE is permitted to change the fields (using attributes ’S’ and ’I’). Other fields (Active Subscription and End Date) are configured with attributes 'S' and 'I' for the roles ADMIN and USER.

User with PII permission
User without PII permission
6. This figure shows two examples on how PII can be displayed in one and the same form for two different users. The users have different roles assigned. The same record is shown in both cases. On the left, the role PII-READ was assigned to the signed in user, and on the right no PII role was assigned to the signed in user.

Additional Constraints – Form Access

Access to PII should be limited to only a few forms as possible. By securing permissions to form access, one more constraint is put in place.

Form Permissions
7. The figure shows an example where permission to access the form ”Contact details” is configured for the role PII.

In figure 7 permissions for form access has been configured. This implies that any menu item for the form ”Contact Details” will not be show in the menu for users without any PII role assigned.

Reports

To manage permissions for PII used in reports, report groups can be used.

Report Groups
8. In the administration interface Report groups a report group is created, for instance PII, and a role, for example PII-READ is assigned to this report group.

Only users with the role PII-READ assigned will be able to access reports in the report group PII.

Reports are created or placed in the report group with the administration interface Report Wizard.

More information

Would you like more information or support for your application?

Please contact IS Tools for advice or assitance.

More tips