Section 22 of South Africa's Protection of Personal Information Act (POPIA) is short. If there are reasonable grounds to believe someone unauthorised has accessed or acquired personal information, the responsible party must notify the Information Regulator and the affected people. It must do so as soon as reasonably possible after discovering the compromise.
That sentence is legal. Meeting it is an engineering problem. I founded ComplyMate, a POPIA compliance product for South African small businesses, and the hardest part of breach response is rarely the form. It's the questions you have to answer before you can fill it in.
The questions you'll be asked at 2am
When something goes wrong, you need to answer, quickly and with evidence:
- What happened, and when did it start?
- Which personal information was accessed: names, ID numbers, health data, bank details?
- Whose information was it, and how do we contact them?
- Is it still happening, and what have we done to stop it?
If your system can't answer these, "as soon as reasonably possible" becomes days of guessing. Here's what to build before you need it.
1. A data map you can trust
List every place personal information lives: database tables, file storage buckets, logs, analytics tools, email providers, backups. For each one, note what kind of information it holds and who can reach it. Keep it in the repo next to the code, so a new table without an entry fails code review.
2. Logs that can answer "who saw what"
Application logs should record access to sensitive records (who, when, which record) without copying the personal
information into the log. A log line that says user 812 exported customer list is evidence. A log line containing the
customer list is a second breach.
Keep these logs somewhere an attacker with app access can't delete them, and keep them long enough to cover the time between a breach starting and being discovered.
3. A way to reach affected people
Section 22 says you must notify affected data subjects unless their identity can't be established. If your data model can't tie a record to a contact method, you can't notify. Make sure you can turn "these 4,000 records" into "these 4,000 people, and here's how to reach them."
4. Contain first, investigate in parallel
The Act allows for the steps needed to determine the scope of the compromise and restore your system's integrity. Make containment fast and boring: rotate secrets with one command, revoke sessions, disable a compromised integration. If rotating a database password needs a meeting and a redeploy, practise until it doesn't.
5. Know where the report goes
The Information Regulator publishes a Security Compromises Notification form (SCN1) with guidelines, and its eServices portal has a channel for reporting compromises. Know who in your organisation owns the report (usually the Information Officer) and how engineering hands them the facts.
Rehearse it
Pick a scenario, such as a leaked API key with read access to the customers table, and run it as a tabletop exercise: the data map, the log queries, the contact list, the containment steps. You'll find the gaps on a Tuesday afternoon instead of during the real thing.
This is an engineer's guide, not legal advice. For your organisation's obligations, speak to a POPIA practitioner and read the Regulator's current guidance.
