The Breach a Journalist Had to Report: What Gauteng's e-Panic Button Teaches Us About Section 22

On 21 September, GroundUp told the Gauteng government and the vendor behind its e-Panic Button app that the database behind the app was unsecured. According to GroundUp’s investigation, the exposed data included names, phone numbers, email addresses, vehicle registration numbers, GPS coordinates and movement histories, the contents of crime reports, and more than 5,000 report photographs. Some reports concerned domestic violence and assault.

The vendor, Evolve Value Added Services, responded and fixed the reported vulnerabilities. The government’s first public response came on Tuesday 29 September, eight days after the tip-off. It said no citizens’ personal information was compromised. On 30 September the Information Regulator told the Mail & Guardian it had not received a notification from the department. By 3 October the Gauteng Legislature’s e-Government Committee was saying the app was not safe to use and asking for a report on access logs going back to the app’s 2024 launch.

Several of these points are still contested. The department disputes that anyone’s information was compromised, and the Regulator said the department’s Section 22 obligations depend on the circumstances it establishes. This post is not a verdict on that case. It uses the public record to show three process failures that any South African organisation could repeat, and a way to test whether you would repeat them.

What Section 22 requires

Section 22 of the Protection of Personal Information Act (Act 4 of 2013) applies when a responsible party has reasonable grounds to believe that personal information has been accessed or acquired by an unauthorised person. The responsible party must then notify the Information Regulator and the affected data subjects.

Two details matter in practice:

• The trigger is reasonable grounds to believe, not proof. You do not wait for a forensic report to conclude before the clock starts to matter.
• The notice must be timely and useful. It must be made as soon as reasonably possible after discovery of the compromise, and the notice to data subjects must give them enough information to protect themselves.

The statute does not care who found the problem. A flaw found by your own SOC, a vendor, or a journalist creates the same duty.

Three questions that measure readiness

Most POPIA programmes stop at a policy document. A policy tells you what should happen. These three questions tell you what would happen.

1. Can an outsider report a problem to you and get a reply within 24 hours?

The e-Panic Button case reached the public through a news organisation. Whether a better channel existed is not clear from the reporting, but the question applies to you either way. Ask:

• Is there a published address where a stranger can report a vulnerability?
• Does anyone monitor it daily, including weekends?
• Does a reply, even a simple acknowledgement, go out within 24 hours?

The cheapest fix is a security.txt file (RFC 9116) at /.well-known/security.txt on your main domain, plus a short vulnerability-disclosure page. It lists a contact address, your disclosure expectations, and a promise not to pursue good-faith researchers. It takes an afternoon. It also covers the systems your vendors run on your behalf, so make sure their domains have one too.

2. Who decides that an event counts as a “security compromise”, and how fast?

When a tip-off arrives, someone has to decide whether personal information was accessed or acquired by an unauthorised person. If nobody owns that decision, the default outcome is delay.

A simple triage matrix removes the ambiguity:

Write down who signs off and the time limit for each step. Exposure without evidence of access is a harder call than confirmed access, and that is exactly why the decision needs a named owner and a deadline. Under ISO 27001:2022, this is the assessment-and-decision step in Annex A control 5.25, and the wider incident lifecycle sits in controls 5.24 to 5.28.

3. Do you keep enough access logging to say what actually happened?

The committee’s request is the most revealing detail in the case. It asked who had accessed the data since 2024. As the chairperson put it, if one person was able to log in, who else could have? Only logs can answer that.

If your logs cannot show who read a record, from where, and when, then you cannot tell the Regulator the scope of the compromise, and you cannot tell data subjects what they need to protect themselves. Section 22 compliance then becomes guesswork.

Check three things for every system that holds personal information:

• Coverage: Are reads logged, or only writes and logins?
• Retention: Do logs go back far enough? The committee asked for two years. A 30-day rolling window would answer none of it.
• Integrity and ownership: Are logs stored away from the system they describe, and does your contract with the vendor guarantee you can get them?

This is ISO 27001 Annex A control 8.15 (logging). Treat it as POPIA evidence, not just a SOC convenience.

A one-page Section 22 runbook

Keep this where your on-call team can find it without a login to the affected system.

Hour 0 to 4: contain and record

1. Log the report: who, when, what they said they found.
2. Acknowledge the reporter in writing.
3. Page the Information Officer and the IT lead.
4. Close the exposure, but preserve logs and a snapshot first.

Hour 4 to 24: assess

5. Pull access logs for the exposed window.
6. Decide, using the matrix above, whether there are reasonable grounds to believe unauthorised access or acquisition occurred. Record the reasoning either way.
7. If a vendor runs the system, invoke the operator agreement and demand their logs in writing.

Hour 24 to 72: notify

8. Send the Regulator notification through the Regulator’s channel, using the template you prepared in advance.
9. Notify affected data subjects with plain-language guidance on what was exposed and what they should do.
10. Brief your executive and keep a decision log for the post-incident review.

Prepare the notification templates now. Nobody drafts a good notice at 02:00 under pressure.

What to do this month

1. Publish a security.txt and a disclosure page. About 2 hours.
2. Name the owner of the “is this a breach?” decision and write down the deadline. About 1 hour.
3. Audit read-access logging on your top three personal-information systems, and note the retention period of each. About half a day.
4. Check whether your vendor contracts guarantee log access.
5. Run a 30-minute tabletop using this post’s runbook.

The measure of Section 22 readiness is not whether you have a policy. It is whether you hear about your own breach before someone else tells you, and whether you can answer the first three questions the Regulator will ask.

Sources: Mail & Guardian, “Information Regulator to engage Gauteng over e-Panic Button data breach” (30 September 2026); eNCA, “Gauteng e-panic safety under scrutiny” (3 October 2026); GroundUp’s investigation as reported in those articles. The incident facts are as publicly reported at the time of writing and may change as the Regulator and the department respond.