Sooner or later most businesses lose control of some personal information: a laptop is stolen, a mailbox is phished, a supplier is hacked, a spreadsheet is emailed to the wrong person. POPIA does not punish the incident itself. It punishes failing to protect the information properly and failing to tell the right people. A written plan, agreed before anything goes wrong, is the difference between a stressful week and a serious problem.
General information compiled from public sources, not legal advice. For a live incident involving sensitive data or large numbers of people, get specialist help quickly.
What the law says
Section 19 requires a responsible party to secure personal information with appropriate, reasonable technical and organisational measures. Section 22 deals with what happens when that fails. Where there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person, the responsible party must notify the Information Regulator and, unless the identity of the person cannot be established, the affected data subjects.
- Timing: "as soon as reasonably possible after the discovery of the compromise", allowing for what is needed to find the scope and restore the integrity of the system. POPIA does not set a fixed number of hours, unlike some foreign laws. Do not read that as permission to wait.
- Who is told: the Regulator, and the data subjects affected. The Regulator may direct you to publicise the breach if that would protect people.
- How the data subject is told: by mail to their last known address, email, placing a notice in a prominent place on your website, publishing in the news media, or as the Regulator directs.
- What the notice must contain: enough for the person to take protective steps, including a description of the possible consequences, what you did or will do, a recommendation of what they can do, and, if known, the identity of the unauthorised person.
Where operators fit in
A business that processes information for someone else, such as a software provider, is an "operator". Under section 21 the operator must tell the responsible party immediately when it has reasonable grounds to believe information has been compromised. The responsible party, not the operator, then notifies the Regulator and the people affected.
Customers' contracts often set a shorter and more concrete deadline for the operator, such as 24 or 48 hours. That deadline comes from the contract, not from POPIA, and the operator should be able to keep it. See our guide to operator agreements.
The first 24 hours
- Stop the bleeding. Disconnect the affected system or account, revoke tokens and passwords, and isolate infected devices. Do not wipe anything that is evidence until you have copied it.
- Alert the Information Officer immediately and start an incident log with timestamps. Write down who found it, when, how, and what was done. This log becomes your evidence.
- Assemble the team: the Information Officer, whoever runs IT, whoever owns the affected system, a decision-maker, and communications.
- Work out what was affected: which systems, which categories of data, roughly how many people, and whether it includes special personal information (health, children, biometric, criminal or financial account numbers that could be misused).
- Decide whether the information was actually accessed or acquired, or only exposed. If you cannot rule it out, treat it as accessed.
Days 1 to 3: assess and notify
- Establish the cause and whether it is contained.
- Decide who must be told. If you are the operator, tell the responsible party at once and cooperate. If you are the responsible party, prepare the Regulator notification and the data subject notice.
- Notify the Regulator on its prescribed form, SCN1, which you can find on inforegulator.org.za. Give the facts you have and say what is still being investigated. Update the Regulator as you learn more.
- Notify affected people clearly and without jargon. Explain what happened, what information was involved, what you are doing, and what they should do (for example change passwords or watch bank statements).
- Consider other duties: your insurer (many policies require prompt notice), your bank if payment data is involved, the police if a crime occurred, and customers whose contracts require a notice.
After the incident
- Write a short post-incident report: timeline, cause, impact, what worked, what did not, and what will change.
- Fix the root cause and record it as a task with an owner and a date.
- Update your risk register, policies and training. If someone made an honest mistake, treat it as a process failure first.
- Keep the incident log and the notifications. Regulators ask for them.
What a good response plan contains
- Roles and phone numbers: who is called first, who decides, who talks to the Regulator and to customers, and a backup for each.
- A definition of what counts as an incident and a simple severity scale.
- A one-page checklist for the first hour, kept somewhere that still works if email is down.
- Templates: the Regulator notification, the data subject notice, and the customer notice for operators.
- A contact list: insurer, forensic or IT support, attorney or adviser if you use one, hosting and email providers.
- A test. Run a 30-minute table-top exercise once a year with a made-up scenario and fix what fails.
Common mistakes
- Waiting until the investigation is finished before telling anyone.
- Deleting logs while cleaning up.
- Forgetting that a lost laptop or an email to the wrong person is a breach too.
- Assuming the supplier will deal with it. As responsible party the notification duty is yours.
- Having a plan that names someone who has left the company.
ComplianceDesk includes a data breach response plan template and an incident log, so you can fill in names and numbers now and not during a crisis.