At 16:40 on a Friday, Amanzi Credit's statement-printing operator sent an email: a storage location used to stage monthly statements had been misconfigured, and "some files may have been accessible" for an unknown period. The next two hours were spent on a call with eight people. The security lead wanted to know how severe it was. Legal wanted to know whose fault it was. The business wanted to know whether it would be in the news. The operator wanted to know what its contract said. Nobody could say whether it had to be reported, because nobody agreed on what the question was.
That argument is normal, and it is expensive. Every hour spent debating definitions is an hour not spent containing the exposure or telling the people affected.
CloudNala's view is that the classification of a security compromise should be decided before any incident happens, as a short set of questions with named owners, so that on the day the discussion is about facts rather than definitions. The facts will still be uncertain. The questions should not be.
This series is general information about running privacy controls in production systems, not legal advice. It summarises the Protection of Personal Information Act for a technical and business audience; read the primary text and take advice from your information officer and a qualified legal practitioner before relying on any interpretation.
This is Part 5 of POPIA in Production. For the technical containment of a compromised software dependency, see What to do when an AI dependency is compromised. This part is about the classification and notification decisions that sit alongside containment.
Amanzi Credit is fictional, and its systems and figures are illustrative. It is a Gqeberha lender with about 180,000 customers and three operators: a collections agency, a statement-printing house and a cloud telephony provider.
What the Act and the Regulator require
Section 19 requires appropriate, reasonable technical and organisational measures to prevent loss of, damage to or unauthorised destruction of personal information, and unlawful access to or processing of it. Section 21(2) requires an operator to notify the responsible party "immediately where there are reasonable grounds to believe" that personal information has been accessed or acquired by an unauthorised person.
Section 22(1) sets the trigger for notification: "where there are reasonable grounds to believe that the personal information of a data subject has been accessed or acquired by any unauthorised person", the responsible party must notify the Regulator and, subject to section 22(3), the data subject, unless the data subject's identity cannot be established. Section 22(2) requires notification "as soon as reasonably possible after the discovery of the compromise", taking into account the legitimate needs of law enforcement or any measures reasonably necessary to determine the scope of the compromise and restore the integrity of the information system. Under section 22(3), notification of the data subject may only be delayed if a public body responsible for the prevention, detection or investigation of offences, or the Regulator, determines that it will impede a criminal investigation.
The Information Regulator's own guidance adds four practical points worth building into any process. Its fact sheet on handling security compromises, published in 2025 and checked on 31 October 2026, says:
- POPIA "does not have a threshold for reporting"; all security compromises must be reported irrespective of the deemed level of risk;
- a compromise "does not have to be confirmed before it is reported", and an investigation does not need to be completed first;
- it is advisable to report on the information at hand and update the notification as further information comes to light, and any delay must be explained;
- "all security compromise reports must be submitted via the Information Regulator eServices Portal". Law-firm and press reports of the Regulator's April 2025 announcement date the mandatory portal route, replacing email, from 1 April 2025.
Note the shape of the trigger. It is not severity, and it is not certainty. It is reasonable grounds to believe that personal information was accessed or acquired by someone not authorised to do so.
Why the argument happens
The Friday call went badly because each person was answering a different question, and each question was legitimate.
Security asked how severe the incident was, which drives the technical response.
Legal asked about liability, which drives the contractual and litigation response.
The business asked about reputation, which drives communications.
The operator asked about its contract, which drives who pays.
The notification question is narrower than all four. Severity matters for how you respond, but by the Regulator's reading it does not decide whether you report. Liability and fault matter later, and the Technology Health Check series explains why a search for blame is the wrong frame for the first hours anyway. Agreeing in advance that the classification question is separate lets the other four run in parallel instead of blocking it.
The classification path
Amanzi wrote its classification path from the sections above and the Regulator's guidance, had it reviewed by its legal advisers, and printed it on one page.
Is personal information involved? If a system outage affects only internal configuration with no personal information, it is a security incident to handle, but not a section 22 matter.
Are there reasonable grounds to believe it was accessed or acquired by an unauthorised person? This is the hinge, and Amanzi's rule is that uncertainty counts in favour of "yes" unless evidence points the other way. Examples help, so the page includes them:
| Situation | Amanzi's classification | Why |
|---|---|---|
| Statement emailed to the wrong customer | Notify | Disclosure to an unintended recipient, an example the Regulator's fact sheet itself gives |
| Storage location left open, access logs show downloads from unknown addresses | Notify | Evidence of acquisition |
| Storage location left open, no access logging enabled | Notify | No evidence either way, and the absence of logs is not reasonable grounds to believe nobody looked |
| Ransomware encrypts servers holding customer data | Notify unless forensics shows no access | Encryption by an attacker requires access; exfiltration is common |
| Laptop lost, full-disk encryption verified, key not with the device | Record and review with the information officer | Grounds to believe access occurred may be absent; the decision and reasons are recorded |
| Database outage, data restored intact, no external access | Record and review with the information officer | No sign of access or acquisition, but the fact sheet's description of a compromise includes availability, so the decision and reasons are recorded |
The Regulator's fact sheet describes a security compromise more broadly than the section 22(1) trigger, in terms of confidentiality, integrity and availability. Amanzi records every case in which the two readings could differ, takes the decision with its information officer, and writes down the reasons. When in doubt, it reports and explains.
Did it happen at an operator? If so, the operator's duty under section 21(2) is to tell Amanzi immediately. Amanzi remains the party that notifies the Regulator and its customers.
The Friday incident, run through the page, took four minutes: personal information was involved, the storage location had no access logging, so there were reasonable grounds; it happened at an operator; notify. The rest of the evening was spent on containment and on what customers needed to know.
What must not wait
Section 22(2) allows time for law enforcement needs and for measures to determine scope and restore systems. It does not allow time to finish the investigation or to perfect the count of affected people. Amanzi's runbook splits the work into what happens on the information at hand and what follows as facts arrive, and records the reason for any delay, because the Regulator expects one.
Operators need operational definitions
"Immediately" in section 21(2) is clear in the Act and vague in most contracts. Amanzi updated its operator contracts and onboarding to define, in operational terms:
- a named contact on each side, reachable out of hours;
- a maximum time in hours from the operator's discovery to its first notice to Amanzi;
- the minimum content of that first notice, even when incomplete;
- an obligation to preserve logs and evidence;
- cooperation with Amanzi's notifications and with the Regulator.
It then ran a joint exercise with each operator. The statement printer's first exercise revealed that its out-of-hours contact was a shared mailbox nobody monitored on weekends.
Write the notification before you need it
Section 22(4) requires notification to the data subject in writing, by at least one of the listed methods: post to the last known address, email to the last known email address, a prominent notice on the responsible party's website, publication in the news media, or as the Regulator directs. Section 22(5) requires enough information for the person to take protective measures, including the possible consequences, the measures the responsible party has taken or intends to take, recommendations for what the person should do, and the identity of the unauthorised person if known.
Amanzi keeps pre-approved templates for its most likely scenarios, with placeholders for facts. Writing a clear recommendation to customers ("be alert to calls claiming to be from Amanzi that ask for your PIN") is much easier on a quiet Tuesday than at 21:00 on the day.
Rehearse it
Each quarter, Amanzi runs a 45-minute tabletop exercise using one row from the example table, with a different person leading. It measures one number: minutes from first report to an agreed classification. The first exercise took 52 minutes. The most recent took eight. The AI-assisted incident response article covers where automation can help in the technical work. Classification stays with people, using a page they agreed on in advance.
Start this week
- Write the three classification questions on one page, with your own examples, and ask your information officer and legal advisers to review it.
- Check that your information officer can log in to the Regulator's eServices portal, and that a deputy can too.
- Ask each operator who they would call at 17:00 on a Friday if they found a problem with your data, and test the answer.
Next: Part 6, Governance after an AI failure. All parts are on the series page.
How CloudNala can help
CloudNala helps organisations prepare for security compromises before they happen. We work with your security team and information officer to write a classification path from the Act and the Regulator's guidance, align operator contracts and onboarding with it, prepare notification templates, and run tabletop exercises that measure how quickly your teams reach a decision. Legal determinations remain with your legal advisers.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a POPIA Controls Review or write to us at consult@cloudnala.co.za