An employee emails a spreadsheet to the wrong customer.
A laptop containing employee information is stolen. A supplier account is compromised. Someone clicks a phishing link. A former employee still has system access. A database is exposed to an unauthorised user.
These incidents may look very different operationally, but each should trigger the same fundamental governance question:
Are there reasonable grounds to believe that personal information has been accessed or acquired by an unauthorised person?
That question reflects the statutory notification trigger in section 22 of POPIA.
Stop the problem. Establish the facts. Apply the section 22 test. Notify appropriately. Fix the weakness. Keep the evidence.
Your processing inventory or ROPA helps identify which information, systems, processes and data subjects are affected.
Your PIIA process helps connect processing risk to appropriate controls and remediation.
Where the incident occurs at a supplier, your operator-governance framework should support rapid escalation and investigation.
Do not wait for perfect information before beginning the response. Containment, investigation, legal assessment and notification readiness should run in parallel.
A practical POPIA security-compromise response
What is a security compromise under POPIA?
POPIA does not contain a standalone statutory definition of the term security compromise.
For purposes of the section 22 notification duty, the statutory trigger is whether there are reasonable grounds to believe that the personal information of a data subject has been accessed or acquired by any unauthorised person.
That formulation is important. The organisation does not need absolute proof before the section 22 assessment begins.
The Information Regulator's current guidance uses the expression more broadly and gives examples including accidental disclosures, lost records or devices, fraud, employee misconduct, phishing and cyber-attacks.
What should an SMME do first?
The first objective is to stop further exposure while preserving enough information to understand what happened.
A practical response should bring together operational containment, privacy assessment, information security and decision-making rather than treating them as separate exercises.
When does section 22 require notification?
Section 22(1) applies where there are reasonable grounds to believe that the personal information of a data subject has been accessed or acquired by an unauthorised person.
When that trigger is met, the responsible party must notify:
POPIA does not contain a 72-hour notification rule
Section 22(2) requires notification to be made as soon as reasonably possible after discovery of the compromise.
In determining that timing, the Act expressly allows account to be taken of:
This does not create an unlimited investigation period.
Current Information Regulator guidance says the compromise does not need to be fully confirmed before notification and that the investigation does not need to be completed first. The Regulator also advises organisations to report on the information available and update the notification as further facts emerge.
Section 22(3) deals specifically with delaying notification to the data subject. Such notification may only be delayed where a public body responsible for preventing, detecting or investigating offences, or the Regulator, determines that notifying the data subject would impede a criminal investigation.
What must the notification tell the data subject?
Section 22(5) requires enough information to allow the data subject to take protective measures against the potential consequences of the compromise.
The notice must include:
Section 22(4) requires the notification to the data subject to be in writing and communicated in at least one of the following ways:
How is the Information Regulator notified?
The responsible party carries the section 22 duty to notify the Information Regulator.
The Information Regulator currently directs responsible parties to submit section 22 security-compromise notifications through its eServices portal.
The Regulator states that, from 1 April 2025, security-compromise notifications should be reported through that portal.
What if the compromise happens at your operator?
Outsourcing processing does not move the section 22 notification responsibility away from the responsible party.
Section 21(2) requires an operator to notify the responsible party immediately where there are reasonable grounds to believe that personal information of a data subject has been accessed or acquired by an unauthorised person.
The responsible party must then manage its applicable section 22 responsibilities.
Close the incident — but keep the learning
Restoring the system or recalling the email does not complete the governance response.
The organisation should be able to explain what happened, what decisions were made, what notifications were issued, what weakness contributed to the incident and what changed afterwards.
Section 19 is also relevant after the incident.
The responsible party must regularly verify that safeguards are effectively implemented and ensure that safeguards are continually updated in response to new risks or deficiencies in previously implemented safeguards.
An incident should therefore feed the control environment rather than disappear into an archive.
An employee emails a payroll spreadsheet to the wrong recipient
The spreadsheet contains employee names, employee numbers, salary information and other employment-related information.
The email is sent to an external recipient who was not authorised to receive it.
The business should not begin by asking whether the incident is “high risk” or “low risk”.
It should establish the facts and apply the section 22 test.
Could your business respond today?
POPIA security compromises: practical questions
Does POPIA define a security compromise?
POPIA does not provide a standalone definition of the term. Section 22 uses the notification trigger of reasonable grounds to believe that a data subject's personal information has been accessed or acquired by an unauthorised person.
Does POPIA have a 72-hour breach deadline?
No. Section 22 requires notification as soon as reasonably possible after discovery of the compromise, taking into account the factors specified in section 22(2).
Can a low-risk breach be left unreported?
Current Information Regulator guidance states that POPIA has no risk threshold for reporting security compromises. An internal low-risk classification should therefore not be treated as a notification exemption where the section 22 reporting regime applies.
Must the investigation be finished before notification?
No. The statutory timing is as soon as reasonably possible after discovery, subject to section 22(2). Current Regulator guidance also states that the investigation does not need to be completed before reporting and that updates can follow as additional information becomes available.
Who reports a breach that occurs at an operator?
Section 21(2) requires the operator to notify the responsible party immediately. The responsible party carries the applicable section 22 notification responsibilities to the Regulator and affected data subjects.
How are security compromises reported to the Information Regulator?
The Information Regulator currently requires section 22 security-compromise notifications to be submitted through its eServices portal.
Does POPIA require a breach register?
Section 22 does not prescribe a document called a breach register. Maintaining a structured incident record is, however, a practical governance method for preserving the organisation's assessment, notifications, remediation and evidence.
Good breach response starts before the breach
An organisation responds well to a security compromise because the roles, escalation channels, records, operator arrangements and notification process were established before the incident occurred.
For an SMME, that does not require an enterprise cyber-response function.
It requires a practical process that employees understand and responsible decision-makers can activate quickly.
Spot the incident. Contain it. Assess it. Notify appropriately. Fix what failed.
Prepare before the incident. Respond with structure when it happens.
The Provara Group POPIA Compliance Programme gives South African SMMEs a structured implementation pathway for security safeguards, operator governance, incident escalation, security-compromise assessment, notification processes, remediation and retained evidence.
This guide has been reviewed for alignment, as at 4 September 2026, with the Protection of Personal Information Act 4 of 2013, in particular sections 19, 20, 21 and 22, together with current published Information Regulator guidance on handling and reporting security compromises.
Section 19 requires the responsible party to secure the integrity and confidentiality of personal information in its possession or under its control by taking appropriate, reasonable technical and organisational measures. This includes identifying reasonably foreseeable internal and external risks, establishing and maintaining appropriate safeguards, regularly verifying their effective implementation and continually updating safeguards in response to new risks or deficiencies.
Section 21(2) requires an operator to notify the responsible party immediately where there are reasonable grounds to believe that the personal information of a data subject has been accessed or acquired by an unauthorised person.
Section 22(1) requires the responsible party, where there are reasonable grounds to believe that the personal information of a data subject has been accessed or acquired by an unauthorised person, to notify the Information Regulator and, subject to section 22(3), the data subject unless the identity of the data subject cannot be established.
Section 22(2) requires notification as soon as reasonably possible after discovery of the compromise, taking into account the legitimate needs of law enforcement and measures reasonably necessary to determine the scope of the compromise and restore the integrity of the responsible party's information system. POPIA does not prescribe a 72-hour period.
Section 22(3) permits delay of notification to the data subject only where a public body responsible for the prevention, detection or investigation of offences, or the Regulator, determines that notification will impede a criminal investigation.
Section 22(4) prescribes the permitted written methods of communicating the notification to affected data subjects. Section 22(5) prescribes the information necessary to enable the data subject to take protective measures, including possible consequences, measures taken or intended by the responsible party, recommendations for the data subject and, where known, the identity of the unauthorised person who may have accessed or acquired the information.
Current Information Regulator guidance states that POPIA does not provide a risk threshold for reporting security compromises, that investigations do not need to be completed before reporting, and that notification may be updated as additional information becomes available. The Regulator currently requires section 22 notifications to be submitted through its eServices portal.
References in this guide to incident registers, investigation records, response checklists, root-cause analysis, remediation plans, notification templates and lessons-learned reviews describe practical governance approaches. They are not presented as statutory document names or prescribed POPIA formats unless expressly identified as such.
Depending on the nature of the incident, additional legal, regulatory, contractual, employment, cybersecurity, sector-specific or law-enforcement requirements may also apply.
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. POPIA obligations depend on the facts of the particular security compromise, the information involved, the processing relationship, applicable regulatory requirements and the organisation's operating environment.