POPIA has been in motion for a while, but now that we’re in the grace period, I’m seeing many more Data Subject Access Requests (DSARs) at my clients. These rights allow for the deletion of a subject’s personal data on request (among others). While simple on the surface, it is goes a lot deeper and is quite tricky. Often, a deletion request can create a major headache given all the locations where data is generated and stored in a business.

The Text

First, let’s look at section 5(c) of POPIA, it states:

5. A data subject has the right to have his, her, or its personal information processed in accordance with the conditions for the lawful processing of personal information as referred to in Chapter 3, including the right – … (c) to request, where necessary, the correction, destruction or deletion of his, her or its personal information as provided for in terms of section 24

This is very much an overview, and the law goes into a bit more detail. Lets head over to section 24.

24(1) A data subject may, in the prescribed manner, request a responsible party to – (a) correct or delete personal information about the data subject in its possession or under its control that is inaccurate, irrelevant, excessive, out of date, incomplete, misleading or obtained unlawfully; or (b) destroy or delete a record of personal information about the data subject that the responsible party is no longer authorised to retain in terms of section 14.

Now we have a bit more meat to the statement. If information is out of date or incorrect, there can be a deletion, or if the responsible party is not authorised to retain the data in terms of section 14. Again, another run to another section. Let’s see what section 14 says, particularly section 14(1), which is most likely where a request will be actioned. I have abbreviated some of this section.

14(1) … 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, unless – (a) retention of the record is required by law; (b) the responsible party reasonably requires the record for lawful purposes related to its functions and activities; (c) retention of the record is required by a contract between the parties thereto; or (d) the data subject or a competent person where the data subject is a child has consented to the retention of the record.

This gives us more to chew on, as it were. There are a number of important things to note from these three sections, let’s break these down.

It’s a request, not an order

If you look at section 5 above, it states that the subject can REQUEST the destruction or deletion. You do not have to honour every request, in fact you can land yourself in hot water if you do. If we look at section 24, the second part of this, it states that you can be requested to delete the information if it’s inaccurate/incorrect/illegally obtained (which is fair enough), but also where the responsible party is no longer authorised to retain the information (more on that in a moment). Section 14 details that the information should be deleted when there is no longer a purpose involved.

Contractual and consenting purposes

Looking at 14(1)(c), if the information has to be processed in order to fulfil a contract, you need to determine whether you may delete the information. If deleting the information would halt you from completing something that you have been contractually obliged to fulfil, then effectively you cannot honour the request, and will need to enter into discussions with the data subject to see whether you can halt processing on their information, but still retain it, or flat-out deny the request with reasons. This is called processing restriction, and forms part of later clauses in section 14.

14(1)(d) refers to consent. Part of consent, is that if it has been given, it can ultimately be revoked. In these cases, it’s most likely that you’ll have to remove the records.

Retention required by law

Sections 14(1)(a) and 14(1)(b) refers to retention of information being required by law or for lawful purposes. In these cases, the request would likely not be honoured. When we refer to information being required by law, it’s referring to the likes of accounting information that is required by the revenue service, or perhaps demographic information required by the Employment Equity Act. A data subject access request should not cause you to break another law. When we talk about lawful purposes, this may relate to information that has to be kept in terms of legal proceedings or court cases / prosecution. If this is the situation you find yourself in, I strongly recommend you read the entirety of Section 14.

Are you a Responsible Party or an Operator

The next note from the above clauses, is you’ll see that section 24 states that the request goes to the Responsible Party. The Responsible Party can be seen as the decision maker when it comes to data – they’ve collected it, and they are deciding the purpose of it’s collection. If you are dealing directly with the individual and they have contracted with you, you are likely the Responsible Party. If you are a Software-as-a-Service provider, or are outsourced/contracted by a company who is collecting the information, and are operating on the instruction of that company, you are likely an Operator.

If a request comes to you as the Responsible Party, you need to act on it. The same applies to the Operator (you need to act), but you should be referring the requester to the Responsible Party. Part of the duty of the Responsible Party is to inform all Operators that they may use about the request for deletion, as well as facilitating the decision as to whether information can be deleted.

Follow Form 2

In 2018, regulations were released which includes Form 2 – a form that data subjects can complete to give you all the information that you should require when it comes to a deletion request. The form is available here. The contents of the form are as follows:

  • Subject Name and surname / Registered entity name
  • Subject Unique identifier / ID number
  • Subject Address
  • Subject Contact details
  • The same information for the Responsible Party
  • What information needs to be corrected/deleted/destroyed
  • The reasons for the deletion/correction


There are practical challenges to all of this. From the get go, you need to validate that the identity of the person or entity is correct. Don’t just act on a deletion request without verifying that the request has come from the correct and authorised person/entity.

Next, you need to ascertain whether you are allowed to delete the information. Look at the exceptions, what was requested, and consider your legal obligations in all of this (section 14).

Finally, it comes down to being able to delete the information. You need to map out where all this information lies. Bear in mind that information sprawls out like a spiderweb in an organisation. There is accounting information, support tickets, email correspondence, contractual information, marketing details and potentially much much more. You also have to contend with a mix of physical and digital data.

Another significant challenge is that of dealing with “live” data, versus “archived” data. A subject access request will affect both. Are you able to extract information from a backup without breaking your backup sets? How do you deal with that if you cannot? (I will be writing a separate article dedicated to backups soon).

Through all of this, you need to keep the data subject informed. As you are working through the process, please be collaborative and supportive. Being dismissive or unsupportive can land you in hot water both in the court of public opinion, as well as the regulator – whom you can be reported to if you do not honour these requests.

What can you do?

There are advanced options out there for eDiscovery and subject request automation, but these are often out of reach for any non-enterprise level organisation. Part of the POPIA requirements is mapping out what activities you perform on data, and along with this will often come a map of what data is stored where. You need to have both in place, and you need to keep them up to date as part of your privacy programme. Data subject requests for GDPR have time limits of 1 month on them, and I wouldn’t be surprised if South Africa starts adopting the same approach; as such it would be in your favour to ensure that you have a policy and process in place to deal with DSARs, before they arrive in your inbox.

Ross G Saunders Consulting offers a number of solutions that can drive your compliance; from affordable 16 week group coaching programmes to comply on your own, through to advisory retainers and full programme management. To find out more about the offerings available, book time directly with Ross using the calendar below.

Share This

Share this post with your friends!