Pseudonymization and personal data export (GDPR)

Webdesk provides two data protection (GDPR) tools: the pseudonymization of all persons in the system (e.g. before a database copy is handed over for troubleshooting) and the export of all personal data of a single person (right of access, Art. 15 GDPR). This page is aimed at administrators and consultants. Pseudonymization is run from the administration menu or under Extended Tasks; the data export is a report in HR-Expert (prerequisite: HR module, see General Information on HR-Expert).

Warning: Pseudonymization affects all persons in the system and irrevocably deletes the audit trail data (see section "Warnings and risks"). It is intended for test and copy systems, not for the live system.

Overview and delimitation

Pseudonymization is not deletion: persons are kept with their structure (group assignments, bookings, workflows); only the fields named in the scheme are changed. Deleting persons after a retention period is done by separate jobs (see Job PoDeletePersonsAfterYears; terminations are handled by the job ProcessTerminatedEmployees). In the code there is no coupling between these jobs, the trash bin and pseudonymization.

Pseudonymization

Purpose and use

According to the description of the mask, pseudonymization is used to pseudonymize person data in a GDPR-compliant way before a copy is handed over for the purpose of bug fixing. Typical procedure: copy the live database to a test system, pseudonymize it there, and only then hand over the copy.

What pseudonymization does:

• According to the scheme, names, user name, contact data, date of birth, bank accounts, images and further HR master data are replaced or removed.
• The action can be repeated: persons that are already pseudonymized are skipped, provided the scheme has not changed.
• The original values are stored encrypted in the system (pseudonymization log, per person and entity). This makes a restore possible.

What it does not do:

• Only the fields listed in the scheme are handled. All other data remain unchanged, e.g. passwords (not part of the default scheme), workflow data and form contents, logs, files and documents. Additional handling exists only for notes and the time system (see below).
• It is not anonymization: the original data are still stored in the database in encrypted form.

Default scheme: which fields are changed and how

The schemes are delivered as the Spring beans PoPersonDefaultPseudonymizationConfig (PO) and HrPersonDefaultPseudonymizationConfig (HR). A scheme saved in the mask takes precedence over the default bean.

Person (PoPerson)

HR person (HrPerson, only with HR module)

The following fields are all cleared with DELETE, or their entries are deleted: birthName, ethnicCode, privatePhoneNumber, privateCellPhoneNumber, comment, privateEmail, socialSecurityNumber, contactAddresses, contactInstantMessagings, contactWebProfiles, relatives, internalRelatives, secondaryJobs, priorEmployments, personMaritalStatuses.

The PoPerson belonging to the HrPerson (same ID) is processed along with it using its own scheme (table above).

Additional tasks

Obfuscation strategies

In the mask, one of the following strategies can be chosen per field.

Running it

There are two entry points. Both process all persons; with the HR module the processing starts at the HrPerson entities, without the HR module at the PoPerson entities. Processing is done in batches of 100 records.

Option A: Mask "Pseudonymization (GDPR)"

Menu Administration > System > Security > "Pseudonymization (GDPR)" (in the menu template full-admin directly under "System"). At the top the mask shows the status "System is pseudonymized" or "System is not pseudonymized".

Buttons: Save, Save and close, "Save and Apply Pseudonymization" (warning icon) and Back.

1. Make sure this is a test or copy system and that a database backup exists.
2. Open the mask, select the entity type and adjust the field policies if necessary.
3. Click "Save and Apply Pseudonymization". The scheme of the currently selected entity is saved; afterwards the pseudonymization of all persons runs in the background with a progress display.
4. When finished, reopen the mask and check that the status reads "System is pseudonymized". The status only applies if a log exists for every person. If it still reads "not pseudonymized", individual batches have failed (see warnings).
5. Re-enable the audit trail if it is needed (see warnings).

Note: The scheme saved in the mask replaces the delivered default bean for this entity. If nothing has been saved, the default bean is used.

Option B: Action under "Extended Tasks"

Menu Administration > System > "Extended Tasks", section "Module specific actions". In the selection field the actions appear in the group "Human Resources":

• "Apply default pseudonymization to HrPerson entities" (class HrApplyDefaultPseudonymizationOnHrPerson)
• "Restore pseudonymized HrPerson entities" (class HrApplyRestoreOnPseudonymizedHrPerson)

Select the action, click "Execute Action" and confirm in the dialog "Run module-specific action". The dialog shows the description of the action. For these two actions no separate warning for destructive actions is shown. Despite the name "default", the action uses the currently effective scheme (a scheme saved in the mask, otherwise the default bean). Here too, all persons are processed; there is no progress display.

Restoring

Restoring is only possible with the action "Restore pseudonymized HrPerson entities" (the mask has no restore button). It reads the encrypted original values from the log, writes them back into the fields of the scheme and then deletes the log of the person. Nothing happens for persons without a log.

Without the HR module or without the TA module

• Without the HR module only the PoPerson entity is processed (default scheme above). The HR-specific fields do not exist then. The mask offers only the entity PoPerson. Opening the mask on systems without an HR license was fixed in version 4.59.27 (see Release Notes 4.59.27).
• Without the TA module the synchronization with the time system does not take place.

Export of all personal data of one person (Art. 15 GDPR)

Authorization and location in the menu

• Report "GDPR Personal Data" in HR-Expert, menu "Reports".
• By default the report (configuration exportAllPersonalGDPRData) is assigned to the default role HR_ADMIN, i.e. to HR-Expert users (e.g. the role $HRX_User). On existing installations the default role was added by an update script.

Procedure

1. In HR-Expert open the menu "Reports" > "GDPR Personal Data".
2. Select the person concerned as parameter (PersonUID) (selection from the persons; the full name is displayed).
3. Choose the output format. HTML view, PDF, Excel and print are configured. In the Excel export every table is on its own sheet.
4. Run the report and check the result. The result should be passed on to the data subject via a secure channel.

Contents of the report

The report starts with the name of the person and, if available, the person image.

Note: The scope of the sections "Personal Data" and the tables of the HR person depends on the form definition of the HR person for the client of the person. Fields not provided in this mask do not appear in the report.

Data for which the report has no section (e.g. document management, groupware/calendar, notes, audit trail entries) must be collected separately if required.

Warnings and risks

• Warning: Do not run it on the live system unless that is explicitly intended. The action always affects all persons; individual persons cannot be selected. Create a database backup beforehand.
• Warning: At the start of pseudonymization the audit trail is deactivated (system parameter HibernateAuditTrailInterceptor, property active is set to false) and its tables are dropped and recreated because they may contain personal data. The existing audit trail entries are irrevocably lost. The restore does not bring them back and does not re-enable the audit trail. If needed, set the property back to true afterwards.
• Warning: Errors in individual processing batches (100 records each) are only noted in the log at debug level; processing continues and a success message may still appear. Always check the status in the mask afterwards and spot-check persons.
• Warning: Do not change the scheme between pseudonymization and restore. The restore works with the currently effective scheme. Fields that were added to the scheme later have no saved original value and may therefore be cleared; fields that were removed from the scheme are not written back. If the scheme is changed while persons are already pseudonymized, pseudonymization first restores these persons and then applies the new scheme.
• Warning: Pseudonymized names are real names of other employees (RANDOMIZE). This is intended for tests but can cause confusion in the test system. User names are replaced randomly; passwords remain unchanged. For copy systems "Reset all passwords" is a useful addition (see Erweiterte Funktionen).
• Note: A database copy that is handed over still contains the encrypted original values (pseudonymization log). It is therefore pseudonymized, not anonymized.
• Note: List entries re-created by a restore have new internal IDs. References to the old IDs (e.g. from imports) point to nothing.