POPIA Section 14 does two things that pull in opposite directions, and a serious backup posture has to satisfy both. It sets a ceiling — you may not keep personal information for longer than is lawfully necessary — and, read together with the security safeguards in Section 19, it implies a floor: while you are lawfully holding a record, you are responsible for its integrity. Immutability answers the floor. Disposition answers the ceiling. Most conversations about "immutable backup" only ever cover the first half.
This is a plain reading for operators, not legal advice. But the mechanics line up with the statute closely enough that it is worth being precise about them.
The floor: immutability while the record lawfully lives
Most backup failures are not hardware. They are a person with valid credentials — a ransomware operator who has phished an administrator, or a departing employee with standing access. If your backups can be deleted using the same identity that manages the live data, then the moment those credentials are compromised, the backup is compromised with them. The recovery plan and the thing it depends on share a single point of failure.
Immutability removes that single point of failure. On object storage it is implemented as WORM — write once, read many — through a mechanism called Object Lock. When a restore point is written, the storage layer stamps it with a retain-until date, and until that date passes the object cannot be overwritten or deleted. The storage service itself refuses the operation and returns an access-denied error, regardless of who issues it. It is enforced below the permission layer — it is not a permission you can grant yourself out of.
Governance mode versus compliance mode
Object Lock has two modes, and the difference is who — if anyone — can override the lock before it expires.
In governance mode, the lock holds against ordinary deletes, but a sufficiently privileged operator holding a special bypass permission can still remove the object. In compliance mode, no one can shorten or remove the lock before it expires — not an administrator, not the storage-account root, not the backup vendor. The practical test to put to any vendor: can anyone delete a restore point before its retention expires? The answer you want is no — compliance-mode Object Lock guarantees it outright, and a governance-mode lock achieves the same in practice only if the vendor's software never issues a bypass-delete. Ask which safeguard they actually rely on.
The ceiling: Section 14(4) and (5) require destruction
Immutability is sometimes misread as "keep everything forever." Under POPIA that is not a virtue — it is a contravention. Section 14 requires that records of personal information not be retained beyond the period for which they are lawfully needed, and Section 14(4)–(5) require that, once that period lapses, the record is destroyed or deleted "in a manner that prevents its reconstruction in an intelligible form."
That last phrase is a technical specification hiding in a statute. Ordinary deletion — unlinking a file, emptying a recycle bin — does not, on its own, prevent reconstruction; the bytes often linger. And under an active Object Lock, you cannot overwrite the bytes even if you wanted to. So how do you satisfy Section 14(5) for data you are contractually forbidden to overwrite?
Cryptographic disposition, and the certificate that proves it
The answer is to attack the key, not the ciphertext. If every restore point is encrypted, then destroying the encryption key renders the stored data permanently unrecoverable — mathematically, not merely administratively. The ciphertext can remain under its lock, ageing out harmlessly, while the information it encodes is already gone in the sense the statute means: it cannot be reconstructed in an intelligible form.
The evidence-grade way to do this pairs the erasure with a destruction certificate: a record of what was disposed of, when, by what method, and with what key-destruction status, chained into a tamper-evident audit trail. That is the artefact a responsible party hands the Information Regulator to demonstrate lawful disposition under Section 14 — not a log line that says "deleted," but cryptographic proof that the record is beyond reconstruction.
Independent and immutable — both, or neither counts
One last property matters for a South African responsible party. Immutability inside the same trust boundary as the live data is worth less than it looks. If the protected copy shares the primary tenant's region, its identity plane, and its keys, then a boundary-wide compromise takes both. The property worth paying for is an independent copy — held outside the primary tenant, under separate keys the primary's administrators do not hold, in a jurisdiction you can attest — that is also immutable. Independence without immutability can still be deleted; immutability without independence can still share the primary's fate.
Immutability protects the record through its lawful life; cryptographic disposition ends that life on schedule, with proof; independence keeps both out of a single blast radius. Section 14 asks for all three, even if it never uses those words.