POPIA section 24 meets the archive you are not allowed to edit
By Dylan Wolpe
The short version
- POPIA section 24 gives a data subject the right to have inaccurate, irrelevant, excessive or unlawfully obtained personal information corrected or deleted, while section 14 requires records to be kept no longer than necessary — except where another law prescribes retention.
- That exception is where the conflict lives: FICA, the Companies Act, tax and sector rules prescribe retention periods that a deletion request cannot override, so the two duties apply to the same record at once.
- Crypto-shredding resolves the conflict without editing the archive, because destroying a per-subject key changes no bytes and therefore breaks no integrity attestation.
- The Information Regulator has not issued guidance specifically endorsing cryptographic erasure, so treat it as a well-founded technical position rather than a settled regulatory one.
We are a South African company, so we meet this conflict in its local form more often than the European one — and the local form is sharper. Under GDPR a controller often has some latitude to argue about how long “necessary” is. Under South African financial and corporate law, the number is frequently written down by someone else.
The two duties
Section 24 gives a data subject the right to request correction or deletion of personal information that is inaccurate, irrelevant, excessive, out of date, incomplete, misleading, or obtained unlawfully. Section 14 says records must not be retained longer than necessary for the purpose — and then carves out the case that matters here: unless retention is required or authorised by law.
Read together, they are coherent. Applied to one record, they frequently are not. A customer’s identity documents collected under FICA sit inside a retention period prescribed by statute. The customer asks for deletion. You cannot simply comply, and you cannot simply refuse either, because the duty to delete what falls outside the prescribed set has not gone anywhere.
The request is rarely “delete everything”. It is “delete what you are not legally required to keep” — which requires knowing, per record, which of the two rules applies.
Why the archive makes it worse
Most South African firms of any size keep long-horizon records in a form that is deliberately difficult to change: WORM storage, immutable buckets, or compressed archives that would have to be fully restored to edit. That is not an accident. Regulators and auditors want records that cannot be quietly revised, and firms want to be able to demonstrate they were not.
So the archive is doing exactly its job when it refuses to let you delete one customer from it. The property that satisfies the auditor is the property that blocks section 24. In practice this produces one of three outcomes, and we have seen all three:
- The archive is quietly excluded. Deletion is performed in the operational systems and the archive is left alone, on the reasoning that nobody looks at it. This is the most common approach and the least defensible one.
- Deletion is refused wholesale. Retention is cited for the entire record, including the parts no statute covers. Convenient, and over-broad.
- The archive is destroyed entirely at end of period. Compliant, and it throws away everything else in it.
What actually resolves it
Encrypt each data subject’s personal information under its own key inside the archive. To erase that subject, destroy their key. No bytes change, so nothing is edited, so no integrity guarantee is disturbed — the archive’s hash is identical before and after, and every attestation made about it still verifies. We wrote the mechanism up in full in deleting one person from an archive you promised never to change.
The reason this matters more here than in Europe is granularity. When your retention obligation is prescribed to the record type, you need to be able to act on a subset of one person’s data — erase what section 24 reaches, keep what FICA requires — and per-subject keying is what makes that a routine operation instead of a project.
The operational half nobody sells you
The cryptography is the easy part, and it is worth being blunt that the rest of this is ordinary unglamorous data governance:
- You must know where the person’s data is.Erasure from the archive is erasure from the archive. Copies in a warehouse, an extract, a spreadsheet or a service-provider’s system are untouched, and section 24 does not stop at your perimeter.
- You must be able to identify the subject inside the archive. Per-subject keying requires deciding what a subject is at the point of writing. Retrofitting it onto twenty years of history is genuinely hard, and any vendor implying otherwise has not tried.
- You must be able to account for the key. The claim rests on custody: where keys lived, who could reach them, how destruction was performed and recorded.
- Operators are a separate obligation. If a third party processes on your behalf, your section 24 response has to reach them too.
Where to start
The most useful first step is not technical. It is a straight answer to: for each category of personal information you hold, which statute prescribes its retention, and for how long? Most firms discover they have been applying one blanket period to several categories with quite different rules — which means they are simultaneously keeping some data too long and deleting other data too early, and neither is defensible.
Once that map exists, the archive stops being the hard part. Our side of it ships as the Provably-Erasable Archive, and the South African framing lives on the POPIA page. Neither makes you compliant, and you should be wary of anything that says it does.