What is a data-breach response procedure?
Is a POPIA data-breach notification compulsory in South Africa?
“Where there are reasonable grounds to believe that the personal information of a data subject has been accessed or acquired by any unauthorised person, the responsible party must notify the Regulator and the data subject. The notification must be made as soon as reasonably possible after the discovery of the compromise, taking into account the legitimate needs of law enforcement or any measures reasonably necessary to determine the scope of the compromise and to restore the integrity of the responsible party’s information system. The notification to a data subject must be in writing and must provide sufficient information to allow the data subject to take protective measures against the potential consequences of the compromise.”
“A responsible party must secure the integrity and confidentiality of personal information in its possession or under its control by taking appropriate, reasonable technical and organisational measures to prevent loss of, damage to or unauthorised destruction of personal information; and unlawful access to or processing of personal information.”
When you need a Data-Breach Response Procedure
- When your organisation processes personal information of clients, staff or third parties and must be ready to respond if that information is lost, stolen, hacked or disclosed without authorisation.
- When you act as a responsible party under POPIA and need a documented process to meet the section 22 duty to notify the Information Regulator and affected data subjects after a security compromise.
- When you engage an operator (processor) — a payroll bureau, cloud host, marketing agency or IT provider — and your Data Protection Addendum requires them to notify you of any breach so the notification clock can start.
- When you must demonstrate accountability to the Information Regulator, an auditor or an insurer that you have a tested incident-response plan and a register of incidents, not just security software.
- When a ransomware attack, lost laptop, mis-sent email, exposed database or rogue-employee incident has already happened and you need to assess, contain and notify correctly and quickly.
What a Data-Breach Response Procedure should contain
Roles and responsibilities
Name the people, not just the functions: the Information Officer accountable for POPIA compliance, an incident lead who coordinates the response and decision-making, IT and security who contain and investigate, legal who assesses the section 22 notification trigger, and communications who handle messaging. Pre-assigning roles prevents the paralysis that turns a contained incident into a reportable disaster.
Detection and logging
Set out how a suspected compromise is detected and reported — monitoring alerts, staff reports, operator notifications, third-party tip-offs — and require every suspected incident to be logged immediately with a timestamp. The date of discovery is legally significant because the POPIA “as soon as reasonably possible” clock runs from discovery of the compromise.
Containment and evidence preservation
Describe the immediate steps to stop the compromise spreading — isolating affected systems, revoking credentials, disabling accounts — while preserving logs, images and evidence rather than wiping them. Containment and preservation run together: you must restore integrity without destroying the forensic record needed to assess scope and to support any later investigation.
Risk and severity assessment (triage)
Define how the team assesses whether personal information was actually accessed or acquired by an unauthorised person, what categories of information and how many data subjects are affected, and how serious the potential harm is. This assessment is what determines whether the section 22 notification duty is triggered and how urgent the response must be.
Notification to the Information Regulator and data subjects
Specify that, where there are reasonable grounds to believe personal information was accessed or acquired by an unauthorised person, the responsible party notifies the Information Regulator and the affected data subjects as soon as reasonably possible after discovery, in writing. The notice must describe the compromise, its possible consequences, the measures taken or proposed, recommendations to the data subject, and the identity of the unauthorised person if known.
Communications to affected data subjects
Set the channels and tone for notifying affected people — direct written communication where possible, and the prescribed alternatives (such as a website notice or media communication) where direct contact is not feasible. The message must be clear, must not over-promise, and must give people practical, actionable steps to protect themselves, such as changing passwords or watching for fraud.
Remediation and recovery
Require the underlying weakness — the failure of the section 19 security safeguards — to be fixed, not just the symptom. Patch the vulnerability, restore data from clean backups, tighten access controls, and verify the system’s integrity before declaring the incident closed. Remediation is what stops the same breach recurring and what you show the Regulator as your corrective response.
Post-incident review and register of incidents
Mandate a post-incident review that records the root cause, the response timeline, lessons learned and actions taken, captured in a standing register of incidents. The register evidences accountability under POPIA, drives continual improvement of your safeguards, and gives the Information Officer a defensible audit trail of how each compromise was handled.
Operator (processor) breach-notification link
Tie the procedure to the breach-notification duty in your Data Protection Addendum. POPIA requires an operator who learns of a compromise to notify the responsible party immediately, so the DPA must oblige your operators to alert you without delay — your section 22 clock cannot start until you, the responsible party, are told.
POPIA section 22 vs EU GDPR breach notification
| Feature | POPIA (South Africa) | EU GDPR |
|---|---|---|
| Who must be notified | The Information Regulator and the affected data subjects | The supervisory authority and, where high risk, the data subjects |
| Deadline to notify the regulator | “As soon as reasonably possible” after discovery — no fixed hour | Without undue delay and, where feasible, within 72 hours |
| Trigger | Reasonable grounds to believe personal information was accessed or acquired by an unauthorised person | A personal data breach (risk-based threshold for notifying authority and subjects) |
| Permitted delay | For law enforcement, or to determine scope and restore system integrity | Reasons for delay must accompany a late notification |
| Form of notice to data subjects | In writing, with prescribed content and protective recommendations | Clear, plain language describing the breach and its likely consequences |
Common South African pitfalls
- Treating the breach as an IT problem only: a security compromise is a legal-notification event, not just a technical clean-up. If IT contains the incident but no one assesses the section 22 trigger or notifies the Information Regulator and data subjects, the organisation has breached POPIA even though the systems are back online.
- Misreading “as soon as reasonably possible”: this is not a licence to delay indefinitely, nor a fixed 72-hour clock. Sitting on a known compromise while you “investigate” — beyond what is genuinely needed to determine scope and restore integrity — risks an unreasonable-delay finding. Notify promptly once you have reasonable grounds.
- No clear date of discovery: because the notification clock runs from discovery of the compromise, failing to log exactly when and how the incident was detected leaves you unable to show you acted in time. Undated, untimed incident logs undermine the whole response.
- Destroying evidence while containing: wiping or re-imaging affected systems to get back online can erase the forensic record you need to assess scope, identify the unauthorised person, and defend your response. Contain and preserve together — restore from clean backups, do not overwrite the evidence.
- No operator notification chain: if your cloud host, payroll bureau or marketing agency suffers the breach but your Data Protection Addendum does not require them to tell you immediately, you may discover the compromise far too late to notify in time. The section 22 duty sits with you, the responsible party, even when an operator caused the breach.
- Vague or panicked communications: a notice that is alarmist, evasive, or light on practical guidance fails the section 22 purpose — to let data subjects protect themselves. The communication must describe the compromise, its likely consequences, the measures taken, and concrete protective steps, in writing and in plain language.
Frequently asked questions
When must I notify the Information Regulator of a data breach in South Africa?
Under section 22 of POPIA, you must notify the Information Regulator as soon as reasonably possible after discovering that there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person. There is no fixed-hour deadline; the standard is reasonable promptness from the date of discovery, allowing only for the time genuinely needed to determine scope and restore system integrity.
Does POPIA have a 72-hour breach notification deadline like the GDPR?
No. The EU GDPR imposes a fixed “without undue delay and within 72 hours” deadline for notifying the supervisory authority. POPIA, by contrast, requires notification “as soon as reasonably possible after the discovery of the compromise”. South African organisations should act with the same urgency, but the legal standard is reasonable promptness, not a fixed hour count.
Who must I notify when personal information is compromised?
Section 22 of POPIA requires you to notify both the Information Regulator and the affected data subjects — the people whose personal information was accessed or acquired. The notice to data subjects must be in writing and must give them enough information to take protective measures, such as changing passwords or watching for identity fraud.
What must a POPIA breach notification to a data subject contain?
It must provide sufficient information to allow the data subject to take protective measures: a description of the possible consequences of the security compromise, the measures the responsible party has taken or intends to take, a recommendation about what the data subject can do to mitigate the adverse effects, and, if the responsible party knows it, the identity of the unauthorised person who may have accessed or acquired the information.
Can I delay notifying about a breach?
Only in limited circumstances. POPIA allows you to take the time reasonably necessary to determine the scope of the compromise and to restore the integrity of your information system, and you may delay notification if a public body responsible for investigating offences, or the Information Regulator, determines that notifying would impede a criminal investigation. Outside those grounds, you must notify as soon as reasonably possible.
What happens if our operator (processor) causes the breach?
The notification duty under section 22 still sits with you, the responsible party. POPIA requires an operator who becomes aware of a compromise to notify the responsible party, which is why your Data Protection Addendum should oblige operators to alert you immediately. Once you are told, your duty to notify the Information Regulator and affected data subjects is triggered.
What security duty does a breach response respond to?
Section 19 of POPIA requires a responsible party to secure the integrity and confidentiality of personal information by taking appropriate, reasonable technical and organisational measures against loss, damage, unauthorised destruction, and unlawful access or processing. A breach is a failure of those safeguards, so your response procedure should both notify under section 22 and remediate the section 19 weakness that allowed the compromise.
Do we need a written data-breach response procedure?
POPIA does not prescribe a single template, but having a documented procedure and a register of incidents is how an Information Officer demonstrates the accountability and reasonable organisational measures POPIA expects. A tested, written playbook lets you detect, contain, assess and notify correctly under pressure, and gives you a defensible audit trail if the Information Regulator asks how an incident was handled.
Sources & authority
- Protection of Personal Information Act 4 of 2013 (POPIA), s 22 — Notification of security compromises
- Protection of Personal Information Act 4 of 2013 (POPIA), s 19 — Security measures on integrity and confidentiality of personal information
This guide is general information, not legal advice. It reflects the law as at June 2026.