Reporting a data breach to the Information Regulator
How a South African business reports a security compromise to the Information Regulator, tells the people affected, and documents what happened.
By Achekam · · 5 min read · For Running a business businesses in South Africa
A laptop with the customer database is stolen from a car. A staff member's e-mail account is taken over and used to forward payslips. A spreadsheet of client ID numbers is sent to the wrong recipient. Each of these is the kind of event South African businesses dread, and in each the first reaction is usually to fix the immediate problem and hope it goes no further.
POPIA asks for more than that. When personal information may have fallen into the wrong hands, the business has to tell the Information Regulator and the people affected, and the Regulator expects a report with specific contents. This article sets out when notification is required, how to tell the people affected, how the report is submitted and what it must contain, and how to use your own records to work out what happened.
When notification is required
The POPIA text published on the government's page, in section 22 of the Act as published, requires a responsible party that has reasonable grounds to believe personal information was accessed or acquired by an unauthorised person to notify the Information Regulator and the data subject as soon as reasonably possible.
Three phrases in that sentence decide most cases:
- "Reasonable grounds to believe". The wording does not demand certainty. A stolen laptop holding an unprotected customer file is the kind of event that can give reasonable grounds, even if you never learn whether anyone opened it.
- "Accessed or acquired". Someone seeing the information counts, as well as someone taking a copy.
- "As soon as reasonably possible". Waiting until every detail of the internal investigation is settled is hard to square with that wording.
Telling the people affected, in writing
The notice to data subjects is not optional and not informal. Under section 22 as published, the notice to the data subject must be in writing, by post, e-mail, a prominent notice on the business's website, the news media, or as the Regulator directs.
A useful notice is plain about what happened, what information was involved, what the business has done, and what the person can do to protect themselves. Keep a copy of every version sent, and a record of who received it and how. As the next sections show, the Regulator will ask for samples.
Reporting on the eServices portal, and registering first
The Regulator's step-by-step guide says security compromises are reported on its eServices portal, and that the organisation and its information officers must be registered before a report can be submitted.
That has an awkward consequence. A business that never registered its information officer cannot report a breach until it does, at exactly the moment when time matters most. The Information Regulator says bodies must register their information officers with it under section 55 of POPIA, and that information officers may only take up their duties once registered. If your registration is not done, do it now, before anything goes wrong.
The Regulator's step-by-step guide to reporting a security compromise takes you through notifying it under section 22 on the eServices portal, screen by screen, and it is worth reading before you ever need it.
What the report must contain
The guide sets out what the Regulator expects to see. It says a report must:
- Describe the incident. What happened, when, and how it was discovered.
- Explain how affected data subjects were notified. The method and timing.
- Include samples of the notifications sent to them. The guide describes these samples as mandatory.
- Set out the actual or potential consequences for data subjects. What could happen to them because of the compromise.
- Say whether the compromised information was retrieved. For example, whether a misdirected e-mail was deleted by its recipient.
- Describe the remedial steps taken to prevent further unauthorised access.
The guide adds that supporting documents, such as forensic findings or internal investigation reports, may be uploaded with the report.
A breach response checklist
- Contain the incident: lock accounts, revoke access, retrieve what can be retrieved.
- Decide, with the information officer, whether there are reasonable grounds to believe personal information was accessed or acquired.
- Identify the people affected and the information involved.
- Send written notices and keep samples.
- Submit the report on the eServices portal with the required contents.
- Record the remedial steps and the evidence for each one.
Using change logs and share records to establish what happened
Most of the report depends on facts: who had access, what was changed, what was opened or downloaded and by whom. Records made at the time are far more reliable than recollection.
In Achekam, two kinds of record can help.
Share records. Staff can share a document from the vault with a named person by an e-mailed link that can block downloading, require a code and be revoked, and every view and download is recorded. Links last 7 days by default, and the recipient needs no account. If a document was shared with the wrong person, the record shows whether and when it was viewed or downloaded, and revoking the link stops further access. That answers two of the report's questions directly: whether the information was accessed, and what was done to prevent further access.
Change logs. Record Governance keeps a log of changes to governed records, showing who did what, when and with what result, which can be filtered and checked for an unbroken chain. It sits under QUALITY & GOVERNANCE, in Record Governance, and viewing it needs the AUDIT_LOG_VIEW permission. It covers records under record governance, not every screen, so it will not tell you about activity elsewhere.
Breaches are not only about outsiders. Information can also arrive at your business by mistake from someone else; how to handle tax information received in error is covered in SARS information received in error. The safeguards that make a breach less likely in the first place are set out in POPIA security safeguards for a small business.
Prepare the response before you need it
Register the information officer, read the step-by-step guide, draft a template notice for data subjects, and agree who decides whether an incident is reportable. With those four things in place, a breach becomes a procedure to follow rather than a crisis to improvise.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
