In short: A defensible POPIA breach response is a six-stage lifecycle under section 22 - detection, containment, assessment, notification, remediation and post-breach review - built before an incident occurs. Section 22(1)’s two-part threshold turns on reasonable grounds to believe personal information was accessed or acquired by an unauthorised person; POPIA sets no harm threshold, so all qualifying compromises must be reported. Since 1 April 2025 the Regulator must be notified in writing through the eServices portal, not by email. Data subject notification runs in parallel under section 22(1)(b). Remediation is now mandatory under Regulation 4(1)(a), the post-breach review should be independent of the IT team, and a breach log is essential practice. Three rules hold throughout: time is statutory, the threshold is objective, and breach response is continuous.
It is 8:47 on a Monday morning. Your IT manager walks in and says the words no Information Officer wants to hear: “We’ve had a breach.” The clock is now running. You must notify the Information Regulator as soon as reasonably possible, but you do not yet know the scope of the compromise, how many data subjects are affected, or whether the breach is still active. Your incident response plan was last reviewed in 2022. Your operator agreement does not specify breach notification timelines. And you are not sure whether the Regulator expects a phone call, an email, or a formal submission through the eServices portal. This is the most consequential kind of morning in the role, and the difference between surviving it and being found wanting is a framework built before the breach, not during it.
Detection and containment
The lifecycle begins with detection. You cannot respond to a breach you do not know about. Under section 19 of POPIA the responsible party must maintain safeguards that enable timely detection of unauthorised access or acquisition of personal information, and a compliant framework needs at least three capabilities: system monitoring through log analysis, intrusion detection and anomaly alerts; operator breach notification, a statutory duty under section 21(2) reinforced in every operator agreement, requiring the operator to notify the responsible party immediately on discovering a compromise in its systems; and an accessible channel for data subjects to report suspected misuse. If you are not logging compromises, you are not detecting them, and your section 19 safeguards are not reasonable. Once a breach is detected, the immediate priority is containment: disabling compromised accounts, isolating affected systems, revoking access tokens, engaging forensic investigators, and preserving logs. Section 22(2) allows a delay in notifying the Regulator where it is reasonably necessary to determine the scope of the compromise and restore the integrity of the information system. That is the containment window, and it is not a blanket deferral. As the Lancet enforcement notice made clear, “we were still investigating” is not a defence to late notification once the responsible party drifts past the time reasonably necessary without documented justification.
The threshold test that decides everything
Once containment is underway, the Information Officer must decide whether the compromise meets the section 22(1) notification threshold. This is a legal determination, not a technical one, and it must be documented. The test has two elements. First, are there reasonable grounds to believe that personal information has been accessed or acquired by an unauthorised person? This is an objective standard, not proof beyond doubt: if the logs show unauthorised logins, downloads or database queries, or if you cannot rule access out, you have reasonable grounds. Second, does the compromise involve personal information as defined in section 1? Names, identity numbers, email addresses, and even login timestamps and IP addresses that can be linked to a person all qualify. POPIA does not define “security compromise” and sets no harm threshold: the Regulator’s position is that all compromises must be reported, so you cannot decline to notify because no harm has yet materialised. Where the compromise occurred inside an operator’s systems, the responsible party remains accountable for the assessment, and the operator must supply enough information to conduct it. Reduce the assessment to writing and keep it in the breach log; if the Regulator audits your response, it is the first document they will request.
Notifying the Regulator, and the data subjects
If the threshold is met, notify the Regulator as soon as reasonably possible after discovery, where discovery is the point you had reasonable grounds to believe a compromise had occurred, not the point the full scope was confirmed. Since 1 April 2025, compromises must be notified through the Regulator’s eServices portal in writing; email submission is no longer accepted, and a phone call is not sufficient. Section 22(5) requires the notification to give enough information for protective action, and the portal form captures it: a description of the compromise, the categories and volume of personal information involved, an evidence-based assessment of potential consequences, the measures taken or proposed, recommendations for data subjects, the data subject notification status, and Information Officer contact details. Keep it factual and complete: do not minimise the compromise, speculate about causes, or make commitments you cannot deliver, and retain the portal confirmation as evidence of timely compliance. Data subject notification runs in parallel, not after the Regulator approves: section 22(1)(b) requires notifying affected data subjects unless their identity cannot be established. Section 22(3) allows a limited delay where a public body responsible for investigating offences, or the Regulator, determines that notification would impede a criminal investigation, but the Regulator has discretion to refuse deferral, so prepare the data subject notifications in parallel and keep the tone clear, non-technical, and free of liability disclaimers.
Remediation and the post-breach review
Notification is not the end of the breach response lifecycle; it is the midpoint. Section 19 requires reasonable safeguards, and a breach is evidence they were insufficient, so the Regulator expects concrete, documented remediation across three fronts: technical fixes such as patching, stronger authentication, encryption and better logging; process improvements such as access-control policies, stronger operator agreements and staff retraining; and governance enhancements such as escalating breach risk to board level, more frequent safeguard reviews and third-party penetration testing. The continuous-improvement obligation added to Regulation 4(1)(a) in April 2025 makes remediation mandatory rather than discretionary, and it should be substantially complete within thirty days, or supported by a remediation plan and timeline where it needs significant investment. The final stage is a post-breach review: a structured, documented assessment of detection effectiveness, containment speed, notification compliance, root cause, remediation completeness, and framework updates. It should be conducted by the Information Officer or a designated compliance officer, not by the IT team that managed the technical response, so that it stays independent, and completed within sixty days with the findings presented to the board or the relevant governance committee.
The breach log
POPIA does not itself require a formal breach log, but keeping one is essential practice: it supports the continual-improvement duty in Regulation 4(1)(a) and the accountability condition, and it lets you record every compromise, including those that did not meet the section 22 threshold. The log gives you audit evidence that you are actively monitoring safeguard effectiveness, it supports root-cause and trend analysis when the same compromise recurs, and it links breaches to remediation actions and framework updates. Record the date of discovery, a description of the compromise, the categories and number of data subjects affected, the threshold assessment, the notification actions taken, containment and remediation, the review findings, and the safeguard improvements made. The Regulator may ask to see your compliance framework during an ordinary audit, not only after a breach, and an Information Officer who cannot show how compromises are logged and remediated will struggle to demonstrate the continual improvement Regulation 4(1)(a) now requires.
Three non-negotiable principles
Three principles underpin every defensible breach response. Time is statutory, not discretionary. Section 22(2) requires notification as soon as reasonably possible, and any additional time must be documented as reasonably necessary to determine scope or restore integrity. The threshold test is objective, not subjective: if there are reasonable grounds to believe personal information was accessed or acquired by an unauthorised person, the threshold is met, and you cannot decide not to notify because you judge the breach minor. And breach response is continuous, not episodic: detection, containment, notification and remediation are stages in a process that must be architected before a breach and executed under stress, with the breach log and post-breach review ensuring every compromise improves the framework.
Would your breach response survive a Regulator audit?
The free POPIA Assessment tests the compliance framework a breach response depends on - detection safeguards, operator agreements, notification readiness and your continual-improvement record under Regulation 4 - and shows where you would be defensible and where you would be exposed.
Run the POPIA Assessment →Frequently asked questions
As soon as reasonably possible after discovery, where discovery is the point you had reasonable grounds to believe a compromise occurred, not the point the full scope was confirmed. Section 22(2) permits only the delay reasonably necessary to determine scope or restore system integrity, and it must be documented. As the Lancet enforcement notice showed, “we were still investigating” is not a defence once you drift past that reasonable time without justification.
A two-part test. First, are there reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person - an objective standard, not proof beyond doubt. Second, does the compromise involve personal information as defined in section 1, including data like login timestamps or IP addresses that can be linked to a person. POPIA sets no harm threshold, so you cannot decline to notify on the basis that no harm has yet materialised.
In writing through the Regulator’s eServices portal. Since 1 April 2025, email submission is no longer accepted and a phone call is not sufficient. The section 22(5) content includes a description of the compromise, the categories and volume of personal information, an evidence-based assessment of consequences, measures taken, recommendations for data subjects, the data subject notification status, and Information Officer contact details. Retain the portal confirmation as evidence.
Yes, in parallel. Section 22(1)(b) requires notifying affected data subjects unless their identity cannot be established, and it is not contingent on Regulator approval. Section 22(3) allows a limited delay only where a body investigating offences, or the Regulator, determines notification would impede a criminal investigation - but the Regulator can refuse deferral, so prepare the data subject notifications in parallel.
No. The continuous-improvement obligation added to Regulation 4(1)(a) in April 2025 makes remediation mandatory. It should be substantially complete within thirty days, or backed by a documented plan and timeline where it needs significant investment, and it should be followed by an independent post-breach review - conducted by the Information Officer or a compliance officer rather than the IT team - within sixty days, with findings presented to the board.