Gericke is responsible for marketing systems management and data analytics at EPI-USE Labs. He is a qualified ISO 27001 Lead Implementer and has an MA in Socio-informatics (Decision Making Theory). He has spent most of his career in IT, strategy consulting and software development.
Deleting data is never as simple as pressing a button. In this eighth article on GDPR and POPIA we look at the requirements and complexities of data deletion. Read on:
For the past few weeks, you’ve been dating someone you met in a coffee shop. It was only after an incident at the zoo that things became uncomfortable. It turns out that they “made a backup” of your information on their neighbour’s device. You haven’t spoken to them in a while, so maybe it is time to cut them loose.
“Hey you, thanks for the good times, but it is time to part ways. Also, please remove my information from your mobile, as well as from your neighbour’s device. I’ve been getting strange calls.”
And with a single tap of a button, this awkward chapter comes to an end. You hope.
The days are over where lists of names with contact details can be bought and sold, kept ad infinitum on a server somewhere or used for a wide range of purposes without consent. Data destruction is now a legal requirement whether it is requested by a person or not.
In this article, we explore the ins and outs of data destruction as an integral part of the data lifecycle and compliance with GDPR and POPIA.
GDPR and POPIA require irreversible data deletion or anonymization of data when the lawful basis and purpose of the data expires, or when consent is withdrawn.
GDPR highlights the deletion of data in the following sections:
In Section 24 POPIA addresses the issue of correction of personal information. This section then also gives the data subject the right to request that “inaccurate, irrelevant, excessive, out of date, incomplete, misleading or unlawfully obtained” data is destroyed or deleted. Data subjects may also request the destruction of records where authorization to retain data no longer applies (in terms of Section 14).
Different to GDPR, POPIA does not expressly provide for a Right to be Forgotten. It incorporates the right to request data deletion in Section 24 as part of a broader discussion on data accuracy and links it back to the lawful basis and purpose for processing the data in the first place.
When should you delete a record?
Data destruction is required as part of a healthy approach to data management, for the purpose of compliance or on the basis of a request from the data subject. However, when it comes to compliance there is a particular challenge, namely the destruction of individual records held in backups and archives.
The issue of data held in backups remains an open debate that may only be clarified as the law is tested in courts. However, there are some strategies that may be considered to reduce the risk of non-compliance:
A few minutes ago you received the dreaded “it’s not me, it’s you” message, along with a civil request to be wiped from your phone, as well as your weird neighbour’s. Should you tell them that you took their advice and backed things up to the cloud? It isn’t as if they will know…
GDPR and POPIA give their respective authorities the power to perform extensive and potentially disrupting audits on your data. It is the better choice to ensure that your data is as clean as possible, void of personal data for which there is no legal basis or purpose.
Are you POPIA compliant? We recently hosted a webinar that tells you more about:
Click here to view it for free.
SAP is a powerful system because business processes are integrated through ERP, CRM, SRM, HR and more. It also means deleting data is not simple. You can’t just delete a single field or record, as this will break SAP’s data models and your systems will become inconsistent. For example, let’s say you delete a client from your system due to a GDPR/POPIA request. You might still have invoices related to the client and CRM interaction data, which will now be orphaned, and probably break some standard functionality.
To comply to Right to be Forgotten legislation, you have a few options. Most frequently, people will first think of archiving. The problem, of course, is that when you archive data it doesn’t actually go away. It still exists in your archiving system. So this doesn’t seem to meet the spirit of Right to be Forgotten. Archiving can also be a complex and costly project, if you don’t already have a robust solution in place.
Sometimes, our clients will also ask if SAP UI masking is sufficient to address the Right to be Forgotten. SAP UI masking doesn’t actually alter the records in the database, it merely masks portions of the data displayed to end users. In our opinion this is not sufficient for compliance to Right to be Forgotten laws, since the actual data is still stored. If the database itself is compromised, UI masking will not protect the sensitive data. We can’t imagine that the data protection authorities would look kindly on personal data leaked after the data subject explicitly asked to be forgotten.
At EPI-USE Labs we’ve created Data Redact specifically to address Right to be Forgotten compliance. This is the only solution we currently know of that actually forgets data, as opposed to archiving or hiding it from end users. With Data Redact, you can selectively redact sensitive fields, without deleting the whole record. For example, you might replace Name, Email and Address fields with “REDACTED”, but keep financial, geographic and gender information for reporting purposes. As long as a record can no longer be used to identify a specific individual, this seems to meet the spirit of the law. The redaction settings are all highly configurable and we’ve done all the hard work for you of mapping data between tables and systems. For example, when we redact a person’s record in ERP, we’ll also do so consistently across CRM and SuccessFactors.