Most incident response plans are written around a moment that feels obvious in hindsight: the point where you know you’ve had a breach. POPIA doesn’t wait for that moment. Section 22 sets a much lower bar for when the reporting clock starts, and the gap between that legal trigger and the point where most organisations feel ready to report is exactly where quiet breaches happen — incidents that are already legally notifiable while the internal conversation is still “let’s confirm what actually happened.”
The trigger in Section 22 is deliberately low. It isn’t “we have confirmed a breach and completed our forensic scope.” It’s reasonable grounds to believe that personal information has been accessed or acquired by an unauthorised person. That threshold can be crossed the moment you find an unexplained admin login, a database export nobody authorised, or a phishing report that turns out to be real — long before anyone can say with confidence how much data actually left, or whether it left at all. The Act doesn’t ask you to wait for certainty. It asks you to act on reasonable suspicion.
Timing compounds the problem. POPIA doesn’t set a fixed statutory clock the way the GDPR’s 72-hour window does — the wording is “as soon as reasonably possible after the discovery of the compromise,” which sounds like room to breathe. In practice it isn’t much. The Information Regulator’s own guidance treats a prompt window as the practical expectation, and “reasonably possible” has consistently been read as fast, not comfortable. The organisations that get this wrong aren’t usually the ones who ignore the law. They’re the ones who spent three weeks in an internal “let’s be sure before we say anything” holding pattern, not realising the clock had already started while they were still confirming the details.
Two audiences need telling, not one. Section 22 requires notification to both the Information Regulator and the affected data subjects, unless the identity of those data subjects genuinely cannot be established. The notification itself isn’t a one-line email — it needs to describe what happened, name the categories of personal information and the likely number of people affected, explain the probable consequences, set out what you’ve done or plan to do about it, give the data subject a recommendation for protecting themselves, and disclose the identity of the unauthorised party if you know it. Delay is only justified if law enforcement or the Regulator itself determines that notifying now would compromise a criminal investigation — that’s a decision made by them, not a call an organisation gets to make quietly on its own.
Getting the notification wrong — late, incomplete, or skipped entirely — isn’t just a governance footnote. Non-compliance with Section 22 is treated as an interference with the protection of personal information under Section 73, which is the gateway to an actual Regulator investigation and, from there, administrative fines. The reputational cost of a delayed disclosure usually outweighs the fine anyway: a breach that’s reported promptly reads as an organisation in control of its incident. A breach that surfaces later, after the Regulator or the media found it first, reads as one that wasn’t.
The practical fix isn’t a faster legal team after the fact — it’s deciding, before an incident, what “reasonable grounds to believe” actually looks like inside your own environment, and who has the authority to make that call at 11pm on a Friday without waiting for a steering committee to convene. That decision procedure belongs in the incident response plan itself, sitting right next to the technical playbook, not bolted on afterwards by whoever picks up the phone to legal. It’s the difference between a breach you controlled the story on, and one that controlled you.