Your POPIA Breach Report Is an Audit of Your Incident Response. Will It Pass?

South African organisations are notifying the Information Regulator of security compromises in growing numbers. Commentary by Werksmans Attorneys’ Ahmore Burger-Smidt, published by Moonstone , reports 2,374 compromises in 2024/25 and a 40% year-on-year rise in monthly notifications in early 2025/26. A separate IT-Online column by Galix’s Ryan Boyes cites more than 1,600 incidents reported between April and September 2025.

I have seen larger figures quoted this month. They trace back to a vendor article with no named source, so I am not using them.

The trend matters because of what a notification is. It tells the Regulator you were breached, and it also shows how you behave when you are.

What the Regulator reads in a submission

Since 1 April 2025, Moonstone reports, all breach notifications must go through the Regulator’s eServices portal, and incorrect use, incomplete submissions or delays could lead to procedural non-compliance. The commentary adds that the Regulator wants “timely, accurate notifications both to the Regulator and affected data subjects” and plans to consolidate technical and legal expertise on breach matters. Moonstone reads that as closer scrutiny of incident management, notification quality and readiness. That is the commentator’s interpretation, but it is a reasonable one.

In practice, a submission lets a reader judge three things:

• Timeliness. How long between discovery and notice, and whether the gap has an explanation.
• Completeness. Whether you can say what was affected, how many people, and what you are doing about it.
• Consistency. Whether the notice to the Regulator, the notice to data subjects and your public statements tell the same story.

That list is my own framing and not a published checklist, so treat it as a lens. Each item depends on records you must create while the incident is still running.

Where the penalties have landed

The clearest recent case came on 27 October, when the Regulator fined FNB R1 million. According to TechCentral , some account holders had been wrongly classified as FNB employees in the banking app. That gave 696 customers access to the home loan applications of 88 other people, including contact details, addresses and income. Nine applicants had their account numbers exposed.

The fault itself was a mundane role misclassification. The handling drew the fine. Customers flagged the problem on 30 March and 3 May 2022. Each time FNB removed the individual’s access and treated the report as “an isolated incident”, and it did not report the matter to the Regulator. The Regulator became involved only after a complaint in September 2022. It called the handling “lackadaisical” and said FNB “did not address this vulnerability to the confidentiality of personal information even after two alerts by two parties”. ITWeb reports findings of deficient safeguards under section 19, an offence under section 105, and that FNB “reasonably ought to have known” the risk existed. The same day, Central Johannesburg TVET College was fined R500,000.

Moonstone lists earlier enforcement outcomes worth reading closely:

• A R5 million infringement notice to the Department of Justice and Constitutional Development, after non-compliance with an enforcement notice linked to a ransomware incident.
• R100,000 infringement notices to FT Rams Consulting and Lancet Laboratories. Lancet paid its fine after failing to notify the Regulator and affected data subjects of security compromises.

In each case the sanction followed the response: repeated reports closed without escalation, a failure to comply with an enforcement notice, and a failure to notify. Being breached did not, on its own, trigger any of them. Boyes makes the same point from the practitioner side: it “is not enough to have controls in place beforehand”, because organisations must show how they responded.

The trigger most plans lack

The coverage does not say how those two reports travelled inside FNB. The pattern is familiar, though: a report becomes a ticket, the ticket gets a fix, and the fix closes it. Most breach-notification policies describe what happens once the Information Officer knows. Few define how a helpdesk ticket gets to the Information Officer in the first place.

Write the trigger into your support procedures. Escalate to the Information Officer the same day when:

• a user reports seeing anyone else’s personal information;
• a second report describes the same fault, whatever the first ticket concluded;
• a fix changes access rights or roles because someone saw more than they should.

The first escalation is the start of the evidence pack below. Record it in the decision log even when the answer is “not a security compromise”. Under ISO 27001:2022 this is control 6.8, information security event reporting, feeding 5.25, assessment and decision on events.

The evidence pack

Showing how you responded needs artefacts. Start a folder the moment an incident is declared and keep it in a location the affected system cannot damage. The pack should hold:

1. Timeline. Discovery, containment, assessment, decision and notification, each with a timestamp and a name.
2. Decision log. The reasoning behind the “is this a security compromise?” call, including the evidence you had at that moment. Record uncertain calls as uncertain.
3. Preserved logs and snapshots. What you captured before remediation changed the system.
4. The notifications as sent. Portal submission and confirmation, data subject notices, and the list of who received them and when.
5. Third-party communications. Every request and reply with the operator or supplier involved.
6. Containment and remediation actions. What changed, who approved it, and when.
7. Corrective actions. Findings from the post-incident review with owners and due dates.

For ISO 27001:2022 this is the working evidence for Annex A controls 5.24 to 5.28: planning, assessment and decision, response, learning from incidents and evidence collection. Under NIST CSF 2.0 it lines up with the Respond function, especially incident management, analysis and incident reporting and communication.

For the triage matrix and an hour-by-hour runbook, see the earlier post on Section 22 readiness . For supplier-side obligations, see the post on operator agreements . This post starts after both: the incident is running, and you must be able to prove what you did.

A 90-minute tabletop

A plan that has never been used is an assumption. This exercise tests the pack and the notification together. Invite the Information Officer, the IT or security lead, someone from legal or compliance, a communications owner and an executive.

Scenario: a supplier that hosts a customer database tells you at 16:40 on a Friday that an unknown party accessed its environment. Your data is in it. The supplier cannot yet say which records.

Swap in other scenarios on later runs: a compromised mailbox, an outage that leaves systems exposed, or a customer telling the helpdesk they can see another customer’s application in your app. Run that last one starting from the support queue to test the trigger. Score each run on three numbers: minutes from first report to a written decision, whether the two notices agree, and how many of the seven pack items you could produce without searching.

FAQ

Does a report to the Regulator replace notifying data subjects?

No. The Moonstone commentary expects accurate notification to both. Section 22 deals with them together, so draft the two in one sitting.

What if we cannot yet say who was affected?

Record the decision with the facts you have and revise as the scope firms up. The tabletop’s scope-change inject exists to practise this. Revised information is easier to defend than silence.

Does the evidence pack need special tooling?

No. A restricted folder with a timeline, a decision log and copies of what you sent is enough. The discipline of filling it in matters more than the platform.

Run the tabletop in the next quarter, fix the gaps it finds, and keep the evidence pack template next to your incident response plan. When the notification goes in, the record will already exist.

Sources: Moonstone, “Information Regulator signals tougher POPIA and PAIA enforcement”, 7 May 2026 ( https://www.moonstone.co.za/information-regulator-signals-tougher-popia-and-paia-enforcement/); IT-Online, 16 October 2026 ( https://it-online.co.za/2026/10/16/popia-breach-reporting-exposes-gaps-in-incident-response); TechCentral, 27 October 2026 ( https://techcentral.co.za/fnb-fine-information-regulator-popia/287711/); ITWeb, 27 October 2026 ( https://itweb.co.za/article/fnb-issued-with-r1m-fine-for-popia-violation/O2rQGqAEWwBqd1ea) . Facts are as reported in the cited commentary and news coverage. Neither article gives the text of Section 22, so check the statute and the Regulator’s guidance. This is not legal advice.