Data Masking in PeopleSoft HCM
PeopleSoft HCM customers regularly copy their production database to development and test environments in order to keep the different databases synchronised and up-to-date. Regularly, the question arises as to whether to anonymise the production data so that maintenance personnel cannot access employees’ confidential data. In the end, in our experience, most companies choose to better their application security but not to apply any data masking between production and its copies. But let’s review some elements of the debate, and what data you might want to scramble if you choose this path.
An important motivation behind data masking is legal liability. Most countries now have legislation in place to protect individuals’ privacy, and companies collecting their information are bound to protect this data and use it appropriately. In Canada, we have the Personal Information Protection and Electronics Documents Act (PIPEDA) federally, with some provincial variations.
Regarding data dissemination, my understanding (insisting that I’m not in any fashion a legal professional) is that the most critical aspects are:
- to collect only data with a reasonable purpose for the organisation,
- to obtain the individual’s consent for this collection
- to dispose -delete, anonymise- of the data when it is no longer necessary to fulfil the original purpose.
Thus the question of whether to proceed with data masking when copying from production to another environment is, legally, whether masked data can be used to do the job in a maintenance environment. I think most payroll administrators would find it hard to test, say, a payroll correction with a sufficient trust in the results and in a time-efficient manner without somehow recognising their production data (positions, jobs, departments, dependants, pay history, etc…) . Of course, you could anonymise more easily a development environment, but it is only meaningful if the developers whose access you are limiting never have access to test or production environments when a bug has to be tracked there, including for emergency situations.
It is easy to superficially scramble the data: name, street address. But anybody with minimum application knowledge can research information based on position, job, department, hierarchy, number and birth date of dependant… And modifying some of this data would render the environment inadequate for testing. For instance, payroll data must be consistent in its history, and modifying the job, salary, location… of an employee might produce some undesirable results.
In the end, the support teams must decide, in agreement with the legal team, if and how much they can scramble the data while still obtaining a database that is usable for testing (allowing to find the necessary information) and trustworthy in its results (giving test results that gives confidence to transfer application modifications to production).
If data masking is deemed part of the data privacy solution, here are some HCM examples of fields that are candidate for masking, providing a degree of anonymity:
- addresses (street),
- Telephone numbers,
- Bank account numbers
- Driving licence numbers
- Email addresses
- Emergency Contacts
- Honors and Awards
- Performance Data
- Licenses and Certificates
An alternative is to consider that IT people (including external consultants and outsourced resources) are not inherently less trustworthy that HR/Payroll administrators, given similar information, training, and contractual terms. As long as you implement adequate segregation of duties.