Mastering GDPR compliance for your HR data in SAP

Wednesday, June 22nd, 2022

Chris Burfitt

In this blog we will concentrate on Human Capital Management (HCM) data in the ‘traditional’ SAP Enterprise Resource Planning (ERP) systems – either ‘ECC R/3’ or the newer ‘S4HANA’ databases. The cloud HCM solutions are not covered in this blog – SuccessFactors has its own data purge functionality, and that is a subject for the future.

With new Data Protection regulations being introduced across the globe, such as the European General Data Protection Regulation (GDPR), there is an increased focus on protection and removal of data for data subjects and, an increased focus on compliance for employee data.

Data Protection Officers and Data Governance specialists are increasingly turning their attention to the employee and applicant data that they store in their IT systems and that, of course, includes any SAP systems they operate.

Taking GDPR as an example, there are three principles that are fundamental when considering employee data:

Purpose limitation principle

  • An Organisation must be clear about what the purpose for processing
  • Organisations need to record the purpose as part of your documentation obligations and specify them in privacy information
  • Organisations can only use the personal data for a new purpose if either this is compatible with the original purpose, or they obtain new consent, or they have a clear obligation or function set out in law

Data minimisation principle

  • Organisations must ensure the personal data they are processing is:
  • Relevant – has a rational link to that purpose; and
  • Limited to what is necessary – Organisations should not hold more than they need for the stated purpose

Storage limitation principle

  • Organisations must not keep personal data for longer than they need it
  • Organisations must justify how long they keep personal data. This will depend on the purposes for holding the data
  • Organisations need a policy setting standard retention periods
  • Organisations should periodically review the data they hold, and erase or anonymise it when they no longer need it
  • Individuals usually have a right to erasure if the Organisation no longer needs the data
  • Organisations can sometimes keep personal data for longer for public interest archiving, research, or statistical purposes

The right of a data subject to request a report on where their data is held in systems must also be considered – the more data an Organisation holds for an employee or applicant the harder it will be to produce an accurate response to a subject access request (SAR). Destroying redundant data reduces the burden when producing these SARs.

SAP over-arching approach

From an early-stage SAP made the decision to use the Information Lifecycle Management’s (ILM) archiving framework to safely remove data from the database. For everything apart from the employee destruction, the process does the following:

  • It prepares data for destruction by checking eligibility, including a configured retention rule that prevents data destruction before a specified period has elapsed
  • It writes an archive file for eligible data
  • It deletes data from the database for records successfully written to the archive file
  • It writes a destruction record to the archiving and destruction infotype (infotype 0283)

For the core HCM data item – the ‘infotype’ – the process automatically destroys the data without any option to store it. Why can’t you archive the data? SAP respond by telling us that Personnel Administration (PA) infotype data is very space efficient, and for this reason no archiving solution was ever developed for this data. This remains the case – no archiving options are provided by SAP for PA infotypes.

SAP have released over 800 ILM objects for HCM data.

  • 8 HCM archiving enabled objects
  • 48 General HCM infotype ILM objects
  • 59 HCM Application objects
  • 700 Country Specific HCM ILM objects

SAP have also released what we at Proceed refer to as the ‘Big Bang’ object – HRPA_PERNR. This object can be used to completely remove the personnel record. Unlike most ILM functionality from SAP this object includes approval and segregation of duties functionality.

  • It prepares data for destruction by checking eligibility
  • It sets the data into a ‘to be approved’ status (this is optional)
  • Once approved it deletes (almost) all the HCM data from the database
  • The destroyed personnel number is written to the dedicated destruction log

Process related data

Why only ‘almost all’? Some HCM data is process related. For example, it exists in workflows, print spool lists and the SAP internal communication system – SAPOffice. These tables have their own ILM objects or data management programs, and SAP have assumed that customers will have tidied up these tables long before the employee destruction object is utilised. This isn’t always the case, however, so it is important to consider the whole picture and, if required, adopt data management and archiving strategies for this type of process data alongside the specific HCM data response.

Unstructured data

HCM data also commonly exists in unstructured data – attachments, for example. Different solutions are required for such data, such as moving to a content server and applying retention there – this is a complex subject and is therefore not covered in this blog.

What other tools are available?

Data destruction isn’t the only tool in the box. SAP have also released solutions for data masking in the user interface (outside of the ILM functionality), and data blocking using authorisations. Most people are familiar with data masking from when they enter their passwords and see ‘*****’ instead of the characters being entered. Masking involves the installation of additional packages and isn’t covered in this blog, but let’s take a closer look at data blocking for HCM data.

Why block for HCM data?

Many Organisations find that they are not able to delete data from their SAP HCM system as the data is still required for reporting and enquiries long after the primary business purpose has been completed.

In such cases most users no longer need this HR data to perform tasks – for data protection compliance data therefore needs to be restricted according to the status of a data subject i.e., whether it’s an active employee or someone who has left the organisation, and things like data ‘type’, data ‘age’.

Restricting access to data for this purposes is referred to as ‘Data Blocking’.

Example:

  • Administrators Personnel data processors: Access limited to the last three years for active employees and last 6 months for ‘withdrawn’ (leavers)
  • Time data administrator: Access to the last 10 years for active employees and last 6 months for ‘withdrawn’ (leavers)
  • Payroll administrator: Full access.

How does it work in SAP?

OK, so this is where we get a bit technical. There are two solutions from SAP.

  • Block access to data for ‘leavers’:
    • A structural Authorisation can be used to block access to data for employees who have left the Organisation (employee status ‘withdrawn’).
  • Data can be blocked according to the ‘age’ of the data

Technically this all hinges on a customer implementation of BAdI HRPADOOAUTH _TIME using method CONSIDER_SV_DATUM_EXIT. The solution has several options including:

  • Maximum access can be granted to specific users
  • The ‘time after leaving’ can be specified for the access to ‘leavers’
  • Default authorisation periods
  • Restriction by user group and infotype with authorisation object P_DURATION

Time dependent authorisation example:

  • Records 1 and 2 are blocked for all users
  • Record 3 can be viewed by specific roles (using authorisation object P_DURATION)
  • Records 4 and 5 can be viewed by all users

FAQs

Can custom data tables and infotypes be included in ILM destruction?

Yes, but coding is required. There are two options:

  1. Custom destruction object
  2. HRPA_PERNR BAdI HRPAYXX _ DELETE_PERNR (BAdl for Personnel Number Deletion Reports) with method DELETE_DATA

What will happen to linked systems when data is destroyed?

It will all depend on how the ‘link’ operates i.e., how the interface is coded, or how the extract is taken or received. The answer is very customer specific and something that is analysed during a project, with mitigations implemented where required.

What will happen to my reports when data is destroyed?

In the SAP system where data has been destroyed the data will no longer be available for reporting. For reporting systems to which data has been extracted from SAP it’s another ‘it depends’ answer. Where regular full loads or re-loads are carried out these won’t include the destroyed data, so that will remove the data from the reporting data set. If the data is passed using change documents it’s very likely that the destruction won’t be transmitted and some other mechanism will need to be implemented if it should have been. ILM notifications and the Data Protection Workbench can be used for BW if the customer is on the necessary version.

Is there an extra license cost for using ILM for HCM data protection compliance?

No, using ILM for data protection compliance is part of the Netweaver licence.

Are extra SAP packages required?

Not usually, however there are specific packages required for masking data in the SAP GUI and in the web interfaces. More information can be found in master note

Is ILM Integrated with SuccessFactors?

No. SuccessFactors has its own data purge functionality.

Is ILM available as Webdynpro Applications?

Yes, both transactional and reporting applications are available for ILM activities with the ILM Work Center.

Is ILM available as Fiori Applications?

Yes, a suite of Fiori applications are provided as standard by SAP

Share this page