GDPR and POPIA: Data destruction

Missed the previous articles?  Read them here: Article 1 | Article 2 | Article 3 | Article 4 | Article 5 | Article 6 | Article 7

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:

• “All good things come to an end”
• No purpose? No data.
• The laws encourage deletion
• The Right to be Forgotten
• Deleting records is a priority, but what about backups?
• Clean data is a clean conscience
• We have a webinar you need to watch
• SAP Knowledge Sidebar

“All good things come to an end”

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.

No purpose?  No data.

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.

The laws encourage deletion

GDPR highlights the deletion of data in the following sections:

1. Par. 39 of the opening statement: “Every reasonable step should be taken to ensure that personal data which are inaccurate are rectified or deleted.”
2. Par. 64 of the opening statement: “A controller should not retain personal data for the sole purpose of being able to react to potential requests.”
3. Par. 65 of the opening statement: “In particular, a data subject should have the right to have his or her personal data erased and no longer processed where the personal data are no longer necessary in relation to the purposes for which they are collected or otherwise processed, where a data subject has withdrawn his or her consent or objects to the processing of personal data concerning him or her, or where the processing of his or her personal data does not otherwise comply with this Regulation.”

1. “the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed;”
2. “the data subject withdraws consent on which the processing is based according to point (a) of Article 6(1), or point (a) of Article 9(2), and where there is no other legal ground for the processing;”
3. “the data subject objects to the processing pursuant to Article 21(1) and there are no overriding legitimate grounds for the processing, or the data subject objects to the processing pursuant to Article 21(2);”
4. “the personal data have been unlawfully processed;”
5. “the personal data have to be erased for compliance with a legal obligation in Union or Member State law to which the controller is subject;”
6. “the personal data have been collected in relation to the offer of information society services referred to in Article 8(1).”

1. Par. 1 of Section 14: “Subject to subsections (2) and (3), records of personal information must not be retained any longer than is necessary for achieving the purpose for which the information was collected or subsequently processed…”
2. Par. 4 of Section 14: “A responsible party must destroy or delete a record of personal information or de-identify it as soon as reasonably practicable after the responsible party is no longer authorised to retain the record in terms of subsection (1) or (2)”

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).

The Right to be Forgotten

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.

Deleting records is a priority, but what about backups?

When should you delete a record?

1. When the purpose related to processing the data expired
2. When inaccurate data can’t be rectified
3. When the purpose of the data is “just in case they request something”
4. When consent is withdrawn or processing is objected to
5. When the data has been unlawfully processed
6. For the general purpose of compliance

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:

1. Opt for indexed archives that allow for the extraction and removal of specific records.
2. In the case of non-indexed backups, implement policies and processes to ensure that data deleted from production systems are not restored from the backups. This approach is technically made more complex as some record of deleted data must exist that can be identified from the backups. This must not be personally identifiable information (e.g. an email address), so an anonymous record identifier may have to be incorporated into the system for the purpose of blocking records upon restore.
3. Indicate in your privacy policy that some records may exist in non-destructible backups, along with stating your operational policies for dealing with the exclusion of records on restoration.

Clean data is a clean conscience

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.

We have a webinar you need to watch

Are you POPIA compliant?  We recently hosted a webinar that tells you more about:

• The similarities and differences between GDPR and POPIA
• How the privacy laws apply over the full data lifecycle
• An overview of how these laws affect your policies and SAP systems
• Non-compliance consequences – penalties, fines and personal liabilities
• An introduction to the EPI-USE Labs GDPR Compliance Suite for SAP

Click here to view it for free.

SAP Knowledge Sidebar

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.