Old CVs sit in recruitment folders.
Former-employee records remain in shared drives. Customer information stays in systems long after the relationship has ended. Email archives continue growing. Cloud platforms retain records because nobody has decided when they should be removed.
For many SMMEs, information is retained for a very simple reason:
Nobody has decided when it should stop being retained.
POPIA requires a more deliberate approach.
Know why you collected it. Know why you are still keeping it. Know what must happen when that reason ends.
Your processing inventory or ROPA should identify the processing activities and information to which retention rules apply.
Your data-subject rights process should deal with requests to delete information where section 24 applies.
Your operator-governance process should also address information retained in systems operated on your behalf.
A retention period should have a reason behind it. “We have always kept it” is not a retention basis.
Building a practical POPIA information lifecycle
Start with what sections 13 and 14 actually require
Section 13 requires personal information to be collected for a specific, explicitly defined and lawful purpose related to a function or activity of the responsible party.
Retention begins with that purpose.
Section 14(1), subject to subsections (2) and (3), provides that 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 one of the statutory grounds for longer retention applies.
What can justify keeping information for longer?
Section 14(1) identifies four circumstances that can permit retention beyond the period otherwise necessary for the original or subsequent processing purpose.
Historical, statistical or research purposes
Section 14(2) permits records to be retained for periods longer than those contemplated in subsection (1) for historical, statistical or research purposes where the responsible party has established appropriate safeguards against the records being used for other purposes.
Records used to make decisions
Section 14(3) creates an additional rule where a record of personal information was used to make a decision about the data subject.
The record must be retained for the period required or prescribed by law or an applicable code of conduct.
If no law or code prescribes a retention period, it must be retained for a period that gives the data subject a reasonable opportunity, taking all considerations relating to the use of the information into account, to request access to that record.
How long should an SMME keep personal information?
There is no single POPIA answer such as three, five or seven years.
The retention period depends on the particular record and the reason for keeping it.
Build a retention schedule that the business can actually use
POPIA does not prescribe a document called a retention schedule.
A retention schedule is a practical governance mechanism for translating section 14 and other applicable retention requirements into operational rules.
Delete, destroy or de-identify when the retention basis ends
Section 14(4) requires a responsible party to 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 section 14(1) or (2).
Section 14 therefore expressly recognises three possible end-of-life outcomes:
Under section 14(5), destruction or deletion under subsection (4) must be carried out in a manner that prevents reconstruction of the record in an intelligible form.
Do not forget copies
Operational deletion should consider where the information actually exists.
That may include active systems, shared folders, email repositories, archives, paper files and systems operated by service providers.
Backup environments may require their own controlled lifecycle because deletion from a live application does not necessarily remove every retained copy immediately.
Sometimes the correct action is restriction — not deletion
Section 14 also contains specific circumstances in which the responsible party must restrict processing of personal information.
Where information is restricted under section 14(6), section 14(7) limits processing, apart from storage, to the circumstances specified in that subsection — including processing for purposes of proof, with the appropriate consent, for protection of the rights of another natural or legal person, or where processing is in the public interest.
Section 14(8) requires the responsible party to inform the data subject before lifting a restriction imposed under subsection (6).
What if a data subject asks you to delete their information?
A deletion request is not automatically a command to delete every record associated with the person.
Section 24(1)(a) allows a data subject, in the prescribed manner, to request correction or deletion of personal information that is inaccurate, irrelevant, excessive, out of date, incomplete, misleading or obtained unlawfully.
Section 24(1)(b) separately allows the data subject to request destruction or deletion of a record that the responsible party is no longer authorised to retain under section 14.
The organisation therefore needs to test the request against the actual retention basis.
Turn the retention schedule into an operating control
The biggest retention failure is often not an incorrect retention schedule.
It is a correct schedule that nobody actually implements.
Build a hold mechanism
Operational retention processes should also allow authorised deletion to be paused where a record must legitimately be preserved — for example because an applicable law, contractual requirement, dispute, investigation or other lawful purpose requires continued retention.
The reason for the hold, its scope and the point at which it must be reviewed should be documented.
A former employee's information remains across several systems
The employee left the business two years ago.
HR has a personnel file. Payroll holds historical payroll records. The employee appears in old email correspondence. A benefits provider holds related records. Some information also exists in archived systems.
The correct question is not:
“Should we delete the employee?”
Different record categories may have different purposes and retention grounds.
Is your retention programme actually operating?
POPIA retention and deletion: practical questions
Does POPIA say personal information must be deleted after a fixed number of years?
No. Section 14 does not create one universal retention period. The period depends on purpose and the applicable statutory retention grounds and exceptions.
Can we keep personal information forever just in case we need it?
Section 14 requires a defensible retention basis. Information cannot simply be retained indefinitely because it may potentially be useful one day.
Can another law require us to retain information longer?
Yes. Section 14(1)(a) expressly recognises retention that is required or authorised by law. Applicable record-specific legislation should therefore be considered when setting the retention rule.
Can we retain information because we may need it for proof?
Section 14 contains specific rules relevant to continued retention and restriction. The facts should be assessed to determine the applicable retention or restriction basis rather than automatically deleting the information.
Does deleting information from the main system mean the lifecycle is complete?
Not necessarily. The organisation should understand where relevant copies exist, including archives, paper records, other systems and operator environments, and manage those copies through an appropriate lifecycle process.
Can we de-identify information instead of deleting it?
Section 14(4) expressly includes de-identification as an alternative end-of-life action in the circumstances covered by that subsection, provided the information is genuinely de-identified within POPIA's definition.
Must every data-subject deletion request be granted?
No. The request must be assessed under section 24 and section 14. Continued retention may still be justified or required depending on the applicable circumstances.
Does POPIA require a retention schedule?
POPIA does not prescribe a document with that title. A retention schedule is a practical governance mechanism for translating section 14 and other applicable requirements into rules the organisation can implement.
The goal is not to keep less information. It is to keep information deliberately.
An SMME does not need an enterprise records-management department.
It needs to understand its material records, establish why they are retained, set defensible lifecycle rules, identify accountable owners and ensure that the rules actually reach the systems and suppliers holding the information.
The strongest retention programme is therefore not the spreadsheet with the most rows.
Know why you keep it. Know how long. Know what happens when the reason ends.
Map the records. Define the rules. Make the lifecycle operational.
The Provara Group POPIA Compliance Programme gives South African SMMEs a structured implementation pathway for processing records, retention mapping, deletion and disposal controls, data-subject requests, operator governance, accountability, remediation and retained compliance evidence.
This guide has been reviewed for alignment, as at 4 September 2026, with the Protection of Personal Information Act 4 of 2013, particularly sections 13 and 14 concerning purpose specification, retention and restriction; the definition of de-identification in section 1; and section 24 concerning correction, deletion and destruction requests.
Section 14(1), subject to subsections (2) and (3), provides that records of personal information must not be retained longer than necessary for achieving the purpose for which the information was collected or subsequently processed unless retention is required or authorised by law, reasonably required by the responsible party for lawful purposes related to its functions or activities, required by a contract between the parties, or consented to by the data subject or competent person where the data subject is a child.
Section 14(2) permits longer retention for historical, statistical or research purposes where appropriate safeguards have been established against use of the records for other purposes.
Section 14(3) imposes particular retention requirements where a record of personal information was used to make a decision about a data subject. Where no law or code of conduct prescribes the period, the record must be retained long enough to afford the data subject a reasonable opportunity, taking all relevant considerations into account, to request access.
Section 14(4) requires destruction, deletion or de-identification as soon as reasonably practicable after the responsible party is no longer authorised to retain the record under subsection (1) or (2). Section 14(5) requires destruction or deletion under subsection (4) to prevent reconstruction of the record in an intelligible form.
Sections 14(6) to (8) contain separate rules concerning restriction of processing, permitted processing of restricted information and informing the data subject before a restriction is lifted.
Section 24 allows a data subject, in the prescribed manner, to request correction or deletion of personal information that is inaccurate, irrelevant, excessive, out of date, incomplete, misleading or obtained unlawfully, or destruction or deletion of a record that the responsible party is no longer authorised to retain under section 14.
Current Regulation 3 governs the prescribed process for section 24 correction, deletion and destruction requests and permits requests through the accessible methods specified in that Regulation.
The Regulations relating to the Processing of Data Subjects’ Health Information by Certain Responsible Parties, 2026, which commenced on 6 March 2026, apply to specified responsible parties and applicable operators, including employers. Regulation 5.2.2 requires appropriate measures for the proper disposal of health records to prevent reasonably anticipated unauthorised use or disclosure of, or unauthorised access to, health information following disposal.
References in this guide to retention schedules, deletion logs, legal holds, review cycles, lifecycle registers, system-retention configuration, deletion evidence and retention owners describe practical governance mechanisms. They are not presented as statutory POPIA document names or prescribed formats unless expressly identified as such.
Specific retention periods may arise from legislation other than POPIA, applicable codes of conduct, contractual requirements, litigation or dispute considerations, sector-specific requirements or other lawful purposes. Those requirements should be assessed for the particular record rather than treated as universal retention periods.
Important: This article provides general compliance information and practical governance guidance. It is not legal advice, does not constitute a legal opinion and does not guarantee compliance. Appropriate retention and deletion depend on the particular records, purposes, applicable laws, contracts, processing environment and circumstances of the organisation.