Retention, blocking and deletion of Employee data: why bother ?

A key principle within GDPR is that employee data (as personal data) should only be stored and accessible by HR to fulfil a contractual or legal obligation. If this obligation is not there anymore, the authorization to access this data should be blocked for that part of HR which does not need access anymore. Otherwise in GDPR it is considered to be “unlawful processing”. A second principle is that without a contractual or legal reason to keep the data, it should be deleted. The following picture illustrates this in the so-called Data Life Cycle.

3 Phases of Data Life Cycle

Data Life Cycle has 3 phases:

In the retention phase the employee data is active and needs to be accessible. This is the case when an HR staff member or a manager needs to be able to read and modify the employee data.

In the blocking phase there is still an obligation to keep the data for audit purposes, but the data is only read, not modified. This is the case when an employee has left the company. Data access is restricted to “read-only” and only for a few employees. Access restriction can be realized by putting the data in an archiving database, only accessible by specific persons or role. It becomes more complex when the data is still in SAP-HR Production database.

In the deletion phase the data should be deleted, if there is no contractual or legal reason to keep the data.

The legal period after which employee data should be blocked depends upon the type of data. For example, data with fiscal relevance should be kept for 10 years; long-term absence and medical data for 25 years. But as mentioned, after e.g. two to three years, access to the data can be restricted to a few persons, because there is no legal or contractual reason to give access to more persons.

Six main questions about Blocking and Deleting data in a HR GDPR project

In order to determine the periods for retention, (access) blocking and deletion the following six questions are important:

What HR-processes do we have?

What employee data do the processes deal with (in detail: infotype and field level)?

What is the contractual or legal purpose of this data?

After which period can the access be restricted / blocked?

After which period can the data be contractually or legally deleted?

What are contractual or legal exceptions to postpone the blocking or deletion of this data?

Setting constraints and defining the scope of an HR GDPR project

While embarking on an HR GDPR project, it’s important to define the scope and constraints up-front. Start working from there and expand later. In one of our projects, legal and HR staff defined the scope of the HR GDPR activities, based on discussions with all the HR-process owners. The outcome of these discussion set out the principles for the GDPR data life cycle management developments:

We only have to look at HR, in particular SAP-HR, data

At a first stage the data life cycle process will manage only internal, not external employees.

We will only restrict access to and delete an employee file when that employee has left the organization. When an employee is still active inside the organization, we will not restrict regular access to, or delete any information of that employee file.

We will only restrict access to / delete complete, inactive employee files. We will not restrict regular access to or delete a part of the employee file. And we will not restrict access to or delete a file if the employee is still active in the company. E.g. if the employee had a long-term illness, this means we have to keep the employee data for 25 years. In principle, we could delete the salary data of that employee after 10 years. However, we will not delete any data before 25 years.

We will not use an archiving system. In principle at the moment the employee data usage changes from “frequent read and change access” to “infrequent read access”, you could decide to transfer the employee data from the on-line SAP-HR database to an archiving database. The inconvenience is, that in the unlikely case you need to do a time or payroll recalculation, you need to restore the employee from the archive to the on-line SAP-HR database. It is not guaranteed, that after a restore of the time and payroll clusters from the archive into the on-line SAP-HR database you can still do a time or payroll calculation.

The period for restricting / blocking access is set to two years after departure from the company. The period for completely and irrevocably deleting the employee file is set to 12 years after departure from the company.

This is an example of where Business, HR and Legal worked out 6 principles to work from in order to satisfy the HR GDPR-requirements based on a SAP-HR system.

Should I use SAP Information Life Cycle Management or not?

SAP made a considerable effort to extend its SAP Archiving solution into SAP Information Life Cycle Management capable to handle GDPR-requirements, also for HR.

We decided not to use this tool:

It is not very clear which functionality of the tool is included in the basic license free-of-charge and which functionality necessitates an additional license. SAP states that for meeting basic GDPR-requirements an additional paid license is not needed.

We only restrict access to and delete complete files of inactive We do not touch active employees or parts of employee files. Because of these two constraints an in-house development for especially deletion is less complicated and less risky and therefore easier to decide for.

Even when using SAP ILM we would still have needed to solve questions such as:

How to fit-in two very customer specific requirement into SAP ILM?

How to include our customer defined tables in the deletion process? You have to enhance “archiving objects”.

How to include SAP-standard tables in the deletion process, when these tables are part of e.g. SAP Finance and are not part of SAP-HR? Examples are: the cross-application time sheet, the bank transfer table, … You may have to activate archiving objects in other modules and / or activate functions which allow to block the deletion of an employee if this employee is still in use outside SAP-HR.

How to communicate between SAP-HR to a non-SAP systems, that a certain employee file has been deleted in SAP-HR?

4 elements needed to define a Retention, Blocking and Deletion policy

We typically define a policy for “Retention, Blocking and Deletion” based on four dimensions:

An infotype to storing the dates and date ranges. Examples are:

blocking access to and deleting a complete employee file

storing manually entered exceptions to postpone blocking

deletion to a future date (e.g. in the case of litigation or a work process accident).

A date calculator to determine the dates and periods for data blocking and deletion. Example :

Access to employee data is blocked two years after the employee becomes inactive or two years after the last payment has been made (unless there are any exceptions)

Deletion takes place 10 years after blocking.

Functionality to restrict the authorizations / block access to the employee file. Once the employee has been blocked, the employee file can only be read, not modified. The read is only authorized for a very limited number of HR and legal employees.

Functionality to delete the employee file. We used the SAP-standard program RPUDELPN and enhanced it to cope with country and customer specific tables.

All functionalities are accessible via a menu to make it more user-friendly (see picture).

Please note that typically, a customer does not speak about “data blocking” when restricting access to an employee file, but about “archiving”. The functionalities can only be used in a specific order. The info-buttons give additional on-line explanations.

#1: Infotype to store Archiving and Deletion Dates

The customer does not speak about “data blocking” when restricting access to an employee file, but about “archiving”.

This application includes 4 important data fields:

Archiving/Blocking Date: date after which access to this employee file can be blocked

Deletion Date: date after which the employee file can be deleted

Exception 1 to 3: The end-user can manually enter reasons to postpone blocking and deletion, such as:

On-going internal or external litigation or investigation

On-going work accident process

Exception Date 1 to 3: Date after which the employee file can be blocked, taking into account this exception. Date to be entered by end-user

#2: Calculator to determine dates for blocking and deletion

The calculator determines the following two dates for inactive employees who have left the company:

Date after which access to the employee file can be restricted / blocked. To calculate the date the highest from the following three dates is chosen:

Two years after the leaving date

Two years after the date of last payment

An exception date entered manually to manually cope with litigations and work accidents

Date after which the employee file can be deleted entirely. This date is 10 years after the archiving date.

#3: Functionality to restrict authorisations / block access

This functionality restricts / blocks data access to this employee, if the calculated “Archiving Date” is in the past. The access to the employee file is restricted / blocked in the following way.

A field in infotype 1 Org.Assignment is changed. The result of this change is, that the employee file becomes “read access for a few selected” HR end-users instead of “modify and read access for regular” HR end-users. Because the customer already used infotype 1 as basis for its SAP-HR authorizations, this was easiest to implement. An alternative was to use the SAP-standard authorization object P_DURATION. However, this is a more fundamental change in the customer’s authorization concept and therefore needs more customizing in authorizations and more testing.

#4: Program to delete the employee file

This functionality performs some checks, calling the SAP-standard program RPUDELPN to delete the employee. The BADI in program RPUDELPN has been used to include deletion logic for tables with employee data, which are not deleted by RPUDELPN. If the tables are outside SAP-HR, experts from other modules were needed to evaluate the impact of deleting or wiping away the employee information in that module. And they assisted to determine whether we should delete the record from that table or whether we should keep the record but just wipe away all employee related data from that record.

Before using the program RPUDELPN, do not forget to read the notes! Quite some employee information is not deleted by this program. And … SAP is still regularly updating this program.

RPUDELPN also logs an entry in the application log (transaction SLG1) for every deleted employee. Deletion of an employee is an “event”, which is of importance also for other systems outside SAP-HR. This log can be used to pass the employee numbers of deleted employees to other systems outside SAP-HR. The question is whether this event should be reported from SAP-HR to these systems or whether these systems will calculate their own deletion date.

About author

Rudolf Von Stein

Rudolf Von Stein is Senior SAP HCM Consultant at Adessa Group, with over 20 year experience with SAP-HR. His main area of expertise is SAP-HR Dutch and Swiss Payroll. But he also has experience of Personnel Administration, Payroll Interfacing, Organisational Management and SAP Business Warehousing for HR. As of 2017 his main focus was to make the SAP-HR system of BNP Paribas Fortis Belgium GDPR-compliant.

Recent Posts

The Adessa Group was founded in 2005 as a specialized, pan-European Human Resources service provider. The company was founded with the vision of supplying sustainable computer solutions through the development of an international network of subsidiaries, close to their customers and with the aim of growing organically. This vision was translated through the values that shaped Adessa’s corporate culture.
You can follow us on LinkedIn by clicking here.