The right way to respond to The Right to be Forgotten

Ever since Europe introduced GDPR, privacy compliance laws have been popping up across various geographies. California added the CCPA; Brazil came up with LGPD, Singapore with PDPA, and so on. Although the length and breadth of the requirements for each of these legislations vary, one common aspect they share is the provision of some or other form of a ‘right’ for data subjects to delete their information. This Data Subject Right (DSR) is known by different terminology in different legislations; for example, the GDPR terms it the Right to be Forgotten while the CCPA calls it the Right to Erasure. No matter what it’s called, the purpose remains the same – upon request, an organization is liable, by law to delete the information about the data subject. An interesting fact – most requests for GDPR’s Right to be Forgotten have come from employees and not customers. This follows the underlying reason that employees have a better understanding of company systems and how they store/use their data. So, in the case of an ex-employee requesting that his/her data be deleted, how do organizations using Oracle PeopleSoft or EBS respond to it?

While you ponder this, there are a few challenges to keep in mind:

• One, these applications are extraordinarily complex data models.

• Two, the applications are generally in use for long periods and hence have accumulated massive amounts of data, which have proliferated into custom tables and other hard to find areas.

• Three, and possibly the most crucial challenge, is that the functionality of these applications relies on referential integrity. This means the deletion of operational information, in this case, the employee’s data, negatively impacts transactional information like paychecks, expense reports, even general ledgers, and so on. The deletion of the data at the top leads to the impairment of all child data branches.

So, what is the right way to approach the Right to be Forgotten?

The answer lies within the challenge - the key is not to delete the data, but to deidentify it. In this way, you don’t compromise the transactional integrity of the application since you’re only getting rid of the operational part of the data, and the system still retains the transactional part of it. Some companies are already using tokenization solutions that create rules to comply with data retention policies and DSRs. Apart from these, there is also the issue of rehiring. How can a company retrieve the data of an ex-employee, once deidentified? In such a situation, the company, apart from tokenizing the data, should also secure the token mapping in case it needs to pull up the details of the ex-employee.

Now that you know deletion is not the answer. Here are some things to keep in mind when you come up with a de-identification solution:

• One, have a system that discovers all sensitive data and not just what is easily identifiable. The discovery should be comprehensive and accurate and be able to find data in seemingly hidden areas, like standard and custom tables.

• Two, tokenize the data without compromising the application infrastructure. This can be done with support from the vendor.

• Three, provide the ability to reverse the deidentification – it will be useful for needs regarding compliance, audit, rehiring, and the like.

Finally, how do you go about the whole process of responding to such a request? There are two ways – you can either respond to the letter of the law and implement a solution as when you get a request, or, you can respond to the spirit of the law and implement the right solution regardless of whether or not you receive a request. The time and resources spent on doing the latter always prove to be worth it – compliance is something that companies will never have to worry about if they stopped carrying inactive sensitive data, in other words, data that they do not need. In this way, you do not have to wait for a request to tell you to do something – you have already been proactive about it. The choice is yours.

Find more information about Data Governance, Privacy and Security