POPIA, the breach notification clock, and what nobody tells you about the seven-day window

When the OpSouthAfrica hacktivism campaign named SARS and SITA in May 2026, both agencies issued public refutations within 48 hours. SARS went on record by midday Monday. SITA was on the wires by Sunday morning. Two well-resourced public bodies, with legal teams, communications teams, and 24/7 security operations centres, moved that fast for a reason.

The reason is POPIA, the Protection of Personal Information Act. Specifically, Section 22, which governs notification of security compromises. The part of Section 22 that most South African SME owners have either never read or remember incorrectly.

This article is for the founder, the operations manager, and the person inside your business who would be the one fielding the call if a breach claim landed against your domain tomorrow morning. It is not legal advice. It is the structural reality of how the notification mechanic works, in plain English, with the practical steps you can take this week so that the day you need them is not the day you draft them.

What Section 22 says

POPIA Section 22 requires that where there are reasonable grounds to believe that the personal information of a data subject has been accessed or acquired by an unauthorised person, the responsible party must notify the Information Regulator and the affected data subjects.

Three things in that sentence carry weight.

Reasonable grounds to believe. Not forensic certainty. Not confirmed compromise. Reasonable suspicion. The bar is informed concern, not proof.

Accessed or acquired. Either one. The data does not need to leave your environment. Unauthorised viewing is enough.

Notify the Regulator and the data subjects. Both. The Regulator first, in writing. The data subjects in a manner that gives them sufficient information to protect themselves.

The Act says notification must happen "as soon as reasonably possible after the discovery of the compromise". The Information Regulator's enforcement guidance and most legal interpretation in South Africa now treat that as a 72-hour window for Regulator notification and a seven-day window for data subject notification, modelled on but not identical to GDPR.

The seven-day clock starts when you have reasonable grounds, not when the investigation concludes.

What this means when a breach claim lands

Walk through a scenario that mirrors the OpSouthAfrica pattern.

Monday morning, 06:30. A hacktivist crew posts a forum thread claiming they have a database from your business. They include a sample. The sample has the company logo on it, three customer email addresses you recognise, and what appears to be an export of your customer list.

At 06:31, your legal exposure under POPIA has already started. You have reasonable grounds to believe personal information was accessed. You do not yet know whether the claim is real. You do not need to.

What you do in the next 72 hours determines whether the Information Regulator treats this as competently handled or as evidence that your information officer is not doing the job. The procedural facts are these.

You need a written internal incident record by end of day Monday: date, time, source of the claim, the sample data, who saw it, and who was notified internally. This becomes the foundation of every subsequent step.

You need a Regulator notification draft ready by end of day Tuesday. The Regulator publishes the form. It asks for the nature of the compromise, the categories of data subjects affected, the categories of personal information involved, possible consequences, measures taken or proposed to address the breach, and any contact details for further information.

You need a data subject notification ready by end of day Wednesday. This is the customer-facing letter or email that goes to anyone potentially affected. The notification must give the data subject enough information to protect themselves: plain language and specific actions.

If you wait until you have confirmed the claim is real, all of the above happens too late. The Regulator's enforcement notices on POPIA non-compliance through 2024 and 2025 cite delayed notification as one of the most common findings. It is also the most easily avoidable.

Why it hits harder here

POPIA enforcement has been ramping up. The Information Regulator's 2024 annual report listed several seven and eight-figure administrative fines against organisations that failed to notify within reasonable time. The Department of Justice itself was issued an enforcement notice. The Polmed disclosure during the same period included specific findings on notification timing.

The SA SME problem is structural. Most businesses we audit have an information officer named on paper, often the finance director or the founder, who has never been trained on POPIA mechanics and has never run a breach notification drill. The information officer learns the job the day the claim arrives.

The reputational cost of late notification is bigger than the regulatory fine. Customers find out from social media before they find out from you. Suppliers withdraw because they cannot reach a named contact at your business. By the time the notification goes out, the narrative is already set.

There is a further dimension that most guidance glosses over: credential exposure through infostealer logs often precedes a visible breach claim by weeks or months. Organisations that monitor for leaked credentials can sometimes identify the exposure before a public claim forces the issue, giving the information officer more time to prepare rather than less.

What to do

Five concrete actions. None of them require a lawyer to do the first pass. All of them benefit from one to review.

1. Name your information officer in writing, this week. Register them with the Information Regulator if you have not (the form is on the Regulator's website and takes 20 minutes). The information officer is the person who signs notifications. Without a named officer, the founder is the officer by default, and the founder is rarely the right person to write the document under pressure.
2. Draft your Regulator notification template now, before any incident. Use the form fields on the Regulator's website as the structure. Fill in everything that does not change incident-to-incident: your responsible party details, your sector, your typical data subject categories. When a real incident hits, you fill in the specifics rather than draft from scratch.
3. Draft your data subject notification template now. Plain language. South African English. Tell the data subject what happened, what data was involved, what they should do (rotate passwords, watch for fraud, contact you), and how to reach you. Get a plain-language editor or a lawyer to review the template once. Then it sits in the folder until needed.
4. Run a tabletop exercise once a year. Pick a fictional incident. Walk through it with the information officer, the founder, the IT lead, and whoever handles communications. Time the response. Note where it broke down. Fix that.
5. Pre-build the technical evidence chain. When the breach is real, your forensic ability to say which records were accessed depends on log retention and access auditing you should already have. If your customer database does not log who accessed what and when, you will not be able to scope the notification properly and the Regulator will read that as carelessness.

© 2026 Ubuntu Guard Cybersecurity | Durban, South Africa
ubuntuguard.co.za