The special requirements of decommissioning SAP HR data securely

In this blog:

• Why do people need to decommission HCM data?
• Privacy value of HR data (can’t leave it lying around)
• Unique challenges of HCM data
• Impacts of data privacy legislation
• Retention periods
• So what’s the solution?

In the context of decommissioning employee data, a modern, sophisticated system, built by design to house and manage historical sensitive data, is non-negotiable. Read on to find out why.

The vast majority of HCM IT systems have a much broader user base than all other solutions used by the organisation. There are some – such as pure Payroll systems – that are an exception; but for the most part, they all provide access to every salaried, and in some cases even non-salaried employees. While you might live with an ugly (or feature-poor) solution for picking in the warehouse (for as long as it is efficient enough), an aged HCM system will elicit unfavourable reviews in their masses – purely because the technology around them has moved on. Everyone has become so used to self-service in their lives via user-friendly apps, and they demand this for updating their details, checking leave or viewing payslips.

And keep in mind the HCM systems are the only one system where the entire C-suite are users. This in the end leads to upgrades, migrations and consolidations of technology to keep up with the technological advances. And with any platform migration, the more historical data you take, the harder the project is, because your new system can’t start fresh but is tied into previous design choices. But of course there are compliance reasons why the legacy data cannot simply be left behind. So if you’re intending to switch off the old system, or cancel the subscription, then you need somewhere to store that historical data.

Even if you don’t want to switch off the old system, there are reasons why removing the historical HR data might make sense. Take for example the situation of moving HR processes from an on-premise SAP® ERP system to SAP® SuccessFactors® Employee Central, or Workday, or any other solution for that matter. One could argue that the SAP ERP system is a perfectly good place to leave the historical data. But that ERP system is probably heading to SAP S/4HANA® at some point, meaning that the disk space taken up by the HR data will become more costly in the future.

However, there is a bigger concern here. While everyone is currently aware that the system includes sensitive employee records, will they still keep that in mind in three or five years’ time? When someone asks for wide-ranging permissions in a test system that was built from Production, will the authorisation team remember to block HR access? Although the data is old, the combinations of name, address, bank account, etc. might well still be valid for a large proportion of the employees in the system. It would be far safer to move that historical data – which is still needed for compliance – to a dedicated archive where it can be securely managed, and then remove it from the ERP system.

So what type of archive system do we need? Documents, structured table data? Very likely both, but there are also some more complex types of data which are found with SAP HCM.

A first example is payslips. These are not stored as documents in the SAP System. The way that changes to pay information are managed, the system can at any point provide a payslip for a particular period, regardless of what happened to the employee afterwards. Retro-calculations don’t completely replace the original ones, so the data that would have contributed to the payslip at the time can still be accessed now to derive a payslip as it would have been on the day.

Each time a user asks for a payslip, SAP dynamically creates it. So to decommission an SAP HCM system, you will need to regurgitate all payslips for all employees for the period in which you are required/willing to provide copy payslips.

In our experience though, payslips may not be enough. The teams responsible for historical queries may also want to have the actual cluster data for the payroll results. This isn’t something that can simply be extracted from the database and stored as a file or loaded into another database. The actual tables contained in each payroll result for each employee depend on the country version and configuration at the time it was created. So extracting the data for two employees from different countries could give you completely different contents in terms of table names, fields and lengths.

SAP HCM also tracks changes in the system via another cluster table. In extreme cases, the support team may not be able to trace exactly what has happened from the Infotype records, and actually needs to be able to see, beyond a shadow of doubt, who made what change and when. This is where the short-term and long-term audit trail comes in and this, just like the payroll results, is stored in a compressed format which cannot easily be extracted and stored in another system.

There is a whole raft of data privacy laws that have come into force over the last decade, the most well-known one being the European GDPR (General Data Protection Regulation). This set a baseline that other regions followed in determining their own rules; and many companies chose to take the GDPR as a minimum standard to apply globally, and then consider any additional country-specific measures required. Whilst being infamously non-prescriptive in what exact actions must be taken in a given situation, the text of the GDPR would make it very hard to justify storing HR records (both structured or unstructured) in file shares, Excel spreadsheets with weak password control, Access databases or other generic IT solutions which were not designed with data privacy in mind.

So ‘how and where’ the data is stored becomes a very important concern. But there is also then the need to be able to efficiently search and share it under the ‘Right to Access’ (Article 15 in the GDPR, and mirrored in most other recent legislation like the CCPA: California Consumer Protection Act). There is also the need to be able to justify why a particular piece of data is being retained, and if there are no legal grounds for holding it, the requirement to remove it. In some cases, this is a reactive requirement based on a data subject's request, but most organisations now have proactive policies for redacting or removing data when it is outside of its retention period.

In the past, ‘retention period’ actually meant the minimum period data must be kept for, from a compliance perspective, and keeping the data longer was the norm. But now it very much means when data must be removed. And that in itself can be more complex given the variety of information all organisations hold on their employees. The retention period for the employee’s children’s names might need to be markedly different from the retention period on their ‘time and attendance’ or pay history. So we can’t simply say ‘when X is true, delete the entire employee record’; we need to be able to remove only certain table rows at that point. In some cases there is data in the same table that requires different retention logic. So, for example, we have legal grounds to keep the date of birth, but not ‘place of birth’ or religion. So we cannot remove the whole table record, which contains all three, and we must only redact or clear the fields that we wish to remove.

The simple conclusion from this in the context of decommissioning employee data? That a modern, sophisticated system, built by design to house and manage historical sensitive data, is non-negotiable.

This is precisely what we’ve built with Archive Central. A modern ‘Software as a Service’ solution which can be used to decommission a multitude of different systems, including SAP, SuccessFactors and any legacy HR systems, as well as Finance and Logistics systems, with role-based permissions to keep the different user communities apart. Benefits include full traceability of who has viewed what, and when; and the ability to store structured and unstructured data together, grouped for each employee, or even data from multiple systems in one place per employee. And of course sensitive fields can be obfuscated for those who do not have permission to see them, and a full range of retention logic capability. All at an affordable price with scalable options for the future.