POPIA Breach Notification: What You Legally Must Do in the First 72 Hours

Most businesses think about POPIA in terms of consent forms and privacy policies. Those matter, but they are the calm-weather part of the law. The part that catches people out is what you are required to do in the hours and days after a breach actually happens, when nobody is feeling calm at all.

This is worth understanding before you need it, because the clock starts the moment you discover the problem, not the moment you finish panicking about it.

What the law actually requires

Under POPIA, if there are reasonable grounds to believe that personal information has been accessed or acquired by an unauthorised person, you have a duty to notify. Two parties need to hear from you. The Information Regulator, and the people whose data was affected.

The notification must happen as soon as reasonably possible after discovering the breach. The Act does not set a rigid hour count the way some other laws do, but the expectation is clear. Delay is not your friend, and a long unexplained gap between discovery and notification is the kind of thing that turns a bad situation into a worse one.

What the notification has to contain

A notification is not a vague apology. It has to give people enough to protect themselves. That means describing the possible consequences of the breach, setting out the measures you intend to take or have taken to address it, recommending what the affected person can do to reduce their own risk, and naming the identity of the unauthorised person if it is known.

The point is to be useful, not just to be seen to comply. Someone reading your notification should come away knowing what happened to their information and what they should do about it.

The 72 hours that matter most

Although POPIA does not legislate a strict 72-hour rule, the first three days are where the outcome is decided in practice. Here is what those hours should hold.

Contain first. Stop the breach from continuing before you do anything else. A breach that is still actively leaking data while you draft notifications is not under control.

Assess the scope. Work out what was actually affected, whose data, and how. You cannot notify accurately if you do not yet know what happened, and guessing wrong in writing creates its own problems.

Document everything as you go. Every decision, every timestamp. If the Regulator asks later why you did what you did, your record is your defence. This habit of writing things down is the same discipline that prevents breaches in the first place, which we covered in your security policy and your security reality are not the same thing.

Then notify, clearly and usefully, to both the Regulator and the affected people.

Why this is a standing duty, not a one-off

The reason most businesses are unprepared is that they treated POPIA as a project they finished in 2021. It is not. It is an ongoing obligation, a point we made at length in POPIA is not a once-off exercise. A breach response plan written once and never rehearsed tends to fall apart on contact with a real incident.

The practical side of containment and recovery is where good IT operations earn their keep, which is part of how the Claritam platform is built. The legal clock and the technical response run at the same time, and both have to work.

If you do not have a breach response plan that someone has actually read recently, that is the gap to close before anything goes wrong. It is far cheaper to write it on a quiet afternoon than during the worst week of your year.

Common mistakes in the first 72 hours

The most common mistake is not containing the breach before starting the investigation. Teams rush to understand what happened, pulling logs and interviewing people, while the attacker still has access. Containment comes first. Disconnect the affected system. Revoke the compromised credentials. Block the network path. Understand later.

The second mistake is notifying too broadly or too vaguely. Some organisations send a generic notification to everyone who might possibly be affected, which causes unnecessary panic and damages trust. Others send a notification that is so vague the recipient cannot tell whether their data was actually involved. The right approach is to notify only the people whose data was actually compromised, with enough detail for them to take protective action.

The third mistake is failing to document the response in real time. When the Regulator asks six months later what happened and why, the team that kept a timeline and a decision log has a straightforward answer. The team that did not has a credibility problem. This is the same discipline that makes POPIA an ongoing practice rather than a once-off project — the habit of writing things down as they happen.

Preparing before you need to

A breach response plan written during a quiet afternoon is worth ten written during an active incident. The plan does not need to be long. It needs to name who makes the call to notify the Regulator, who communicates with affected parties, who handles the technical containment, and who manages legal counsel. It needs contact numbers that are current. It needs to be somewhere the on-call person can find it at 2am on a Sunday.

And it needs to be rehearsed. A tabletop exercise once a year, running through a realistic breach scenario with the people who would actually respond, will surface every gap in the plan. The gaps you find during a tabletop are free. The gaps you find during a real breach are expensive. Every board should be asking whether their IT team has run a tabletop in the last twelve months — it is one of the three questions every board should be asking their IT team.