SuccessFactors Data Purge – Considerations
The SAP SuccessFactors HXM Suite stores an extensive range of employee information and when we talk about employee data, some questions come to mind: Can I keep employee data offline? For how long? Should I anonymize them?
Practically, historical data should not be stored any longer than is required. Once the required retention time has passed, data should be purged (permanently removed from system storage).
To answer the above questions, let’s start from the beginning, defining a data purge Strategy.
1. Data Purge Strategy
Firstly, we have to take into account that to keep employee data we have to have a purpose, otherwise we end up carrying too much data and this leads the company to a situation of vulnerability in terms of security and makes decision processes time-consuming. From this understanding, it is clear that we need to start by defining the Company’s Data Purge Strategy.
When starting this exercise, consider the following:
- The more data, the more difficult and costly decision-making will be.
The amount of outdated data makes it difficult to export, and use in terms of strategic analysis, thus becoming useless. The recommendation here is to narrow it down to keep it relevant and useful, which will improve the decision’s time and consequently save money.
- The more data, the greater control, and the greater risk.
Storing useless data increases the risk of security threats that could be avoided if a data purge strategy is implemented.
- Storage control definition
Defining a storage control may bring some benefits such as security improvement, time-saving, a decrease in the global database size, and an increase in the performance of the system, etc.
- Data grown forecast
Based on your business metrics and knowledge you can define a data-grown forecast and prevent a system performance from weakening. Customers normally use monitor applications to control the database grown periodically and based on that put in place the data purge policy, which we will cover more in detail in the next chapter.
2. Data Purge Policy
It is relevant to highlight one of the most important parts of the data purge strategy, the data purge policy. This policy establishes how and how often each company performs data purge. We are clear, from the definition of the data purge strategy, where we prioritize data security and its quality, that the purge must be something consistent and recurrent, and not just a single time.
When defining when and how the purge should be carried out, we must take into account the data protection regulations of each country/region. In general, these regulations stipulate that the subject may, at any time, request that his data be completely deleted from the database. As said, this is general and you must check each policy before defining your purge policy, otherwise, you may be deviating from what is determined by the law of the country.
Below are some countries/region examples of how the regulations define the data purge (Note this is just an example, you may analyze the entire regulation before defining your policy).
Points to consider when defining the data purge policy:
- How long the data should be kept, considering for example its validity/quality, which processes are required, etc?
There is a tendency to say that data will always be needed, but if we consider the purpose of data retention, we will see that ‘forever’ is not really necessary.
- Control your database.
The easiest way to clean up stored data is to control its quantity and quality. Through monitoring, you will be able to generate strategic data controls and determine what stays and what goes out.
- Use DRTM tool
Automating the process is always the most recommended option so that we do not run the risk of human error. Digital tools are always the best option to maintain a consistent data purge policy running.
3. Additional Considerations
3.1 Replication Systems
If data is purged in Employee Central that is needed for replication to other systems, the integration must react to the purge. That is, the Employee Central CompoundEmployee API and the standard integrations provided for SAP ERP HCM, SAP S/4HANA, and Employee Central Payroll, and the Employee Central Data Replication Monitor used in these integrations must consider data purge. More details can be found here.
3.2 Audit Data
When setting up retention times for audit data, consider that the delta transmission mode and the snapshot mode of Compound Employee API will only expose records if the last_modified_on date or the snapshot_date is within the audit retention time of the relevant entity.
4. Support Documentation
This ends our blog. Please note, the points presented in this blog should be considered on top of each company’s requirements.
Data is key in the digital world, but the importance of its quality vs quantity is normally left behind by companies. Controlling and purging, in other words, implementing a data purge strategy and policy, is the way to keep a secure and trustful system environment.
This blog post shared some considerations when talking about system data purge.
Looking forward to your comments and seeing your use cases/experiences on this topic.