How to Handle a Data Breach Under POPIA.

Published: 24 August 2026  |  By AOLC

A data breach is not just a technical problem — it is a legal and reputational crisis that starts a clock the moment your systems are compromised. Under the Protection of Personal Information Act (POPIA), South African businesses have specific obligations when personal information is lost, stolen, or accessed without authorisation. Those obligations are time-bound, and failing to meet them can result in fines of up to R10 million or criminal prosecution under Section 107.

The good news is that a structured response — one you plan before anything goes wrong — dramatically reduces the damage. Whether the breach was a ransomware attack, a phishing compromise, a lost laptop, or an accidental email to the wrong recipient, the steps are largely the same. This guide walks you through exactly what to do, step by step.

What Counts as a Data Breach Under POPIA.

POPIA defines a security compromise broadly: it is the unauthorised access to, or acquisition, interference, modification, destruction, disclosure, or use of personal information. This covers a wide range of incidents that many South African businesses would not immediately recognise as reportable breaches:

• Ransomware attacks — Encrypting customer or employee data counts as a compromise, even if you never see the data leave your systems.
• Phishing compromises — If a staff member's email account is accessed by a third party, every client email in that inbox is potentially compromised.
• Lost or stolen devices — An unencrypted laptop left in a car or a USB drive misplaced at a client site triggers reporting requirements.
• Accidental disclosure — Emailing a client list to the wrong person, or posting a document with personal data to a public SharePoint link, is a breach.
• Cloud misconfigurations — A database exposed to the public internet due to incorrect permissions is a breach from the moment it was misconfigured, not from when it is discovered.
• Third-party incidents — If a supplier or cloud provider you share data with suffers a breach, your obligation to notify may still apply.

If you are uncertain whether an incident meets the threshold, treat it as a reportable breach and document your reasoning. The cost of unnecessary caution is a few hours of administration. The cost of missing a required notification is far greater.

Your First 72 Hours — What to Do.

While POPIA does not prescribe a specific time window (the European GDPR uses 72 hours), the "as soon as reasonably possible" language means you need to move quickly — days, not weeks. The moment you suspect a breach, activate the following steps:

• Contain immediately — Isolate affected systems. If a server is compromised, take it offline. If an email account is accessed, reset credentials and revoke active sessions. Do not wait for a full investigation before containing the threat.
• Preserve evidence — Before making changes, take screenshots, preserve logs, and document what you see. Your IT provider or managed security team should capture forensic data before affected systems are restored. This evidence is critical for both the Regulator and any insurance claims.
• Assess the scope — What categories of personal information were involved? How many records? Which data subjects — employees, clients, suppliers? The Regulator will ask these questions, and you need answers before you notify.
• Notify internally — Your Information Officer (every organisation must designate one under POPIA) must be alerted immediately. If you do not have one formally appointed, the most senior responsible person takes on this role.
• Engage your response team — This should include your IT provider, legal counsel, and senior management at minimum. If you have cyber insurance, notify your insurer early — most policies require prompt notification and may provide breach response support.

Notifying the Information Regulator.

Section 22 of POPIA requires the responsible party — that is, the business or organisation that collected and holds the personal information — to notify the Information Regulator of South Africa. The Regulator is contactable at inforeg.org.za and accepts notifications by email (complaints.IR@justice.gov.za) or through its online portal.

Your notification to the Regulator must include:

• A description of the compromise — What happened, how it was discovered, and the likely timeline.
• Categories of personal information involved — For example: names, ID numbers, financial data, health records. Special personal information (health, race, religion, criminal history) attracts heightened scrutiny.
• Approximate number of data subjects affected — Even an estimate helps; say "approximately 500 clients" if you do not yet have exact figures.
• Contact details of your Information Officer — Full name, role, phone number, and email address.
• Likely consequences of the breach — What risks does this create for the affected individuals? Identity theft? Financial fraud? Reputational harm?
• Measures you have taken or plan to take — What you have already done to contain the breach, and what remediation steps are planned.

You may submit an initial notification before all details are known, and follow up with a supplementary report as the investigation progresses. Do not delay the initial notification waiting for a complete picture.

Notifying the People Affected.

Alongside notifying the Regulator, POPIA requires you to notify the affected data subjects — the real people whose information was compromised. This is often the harder conversation. You may not want to alarm clients or employees unnecessarily, but delayed notification exposes them to harm they cannot protect themselves against, and it exposes you to greater legal risk.

Notifications to affected data subjects must include:

• What happened — A plain-language description of the incident, without minimising it.
• What information was involved — Be specific about what categories of their data may have been accessed.
• What you are doing about it — The steps you have taken to contain the breach and protect their information going forward.
• What they can do to protect themselves — For example, if financial data was involved: monitor bank statements, change online banking passwords, watch for phishing emails purporting to be from you.
• How to contact you — A dedicated email address or phone number for affected individuals to ask questions.

Notification can be made by email, letter, SMS, or a prominent notice on your website if the number of affected people makes individual outreach impractical. If you cannot reach some data subjects directly, the Regulator may allow a general public notice.

What You Must Document.

Good record-keeping serves two purposes in a breach response: it demonstrates to the Regulator that you acted appropriately, and it gives your own team the information needed to prevent a recurrence. Your breach log should capture:

• Date and time of discovery — And, if known, the date and time the breach actually occurred.
• Nature of the breach — Ransomware, phishing, accidental disclosure, theft, etc.
• Systems and data affected — Which servers, databases, or cloud services; which categories of personal information.
• Number of records and data subjects involved — Even an estimate, with the basis for the estimate documented.
• All notifications sent — Date, method, and content of notifications to the Regulator and to affected data subjects.
• Remediation steps and timeline — Every containment action, system restore, credential reset, and configuration change.
• Post-incident review findings — Root cause, what was working, what failed, and what changes are being made.

Retain this documentation for at least three years. If the Regulator investigates, this record is your primary evidence of a good-faith response.

After the Breach — Preventing the Next One.

Once the immediate crisis is contained and notifications are complete, the real work begins. Every breach is a window into a gap in your controls — and that gap almost certainly still exists. A thorough post-incident review should answer three questions: How did this happen? What would have stopped it? What do we change now?

Common improvements South African businesses make after a breach:

• Multi-factor authentication — If the breach involved a compromised email account or cloud login, MFA would have stopped it. Deploying MFA across Microsoft 365, cloud applications, and remote access should be the first post-breach priority. See our cloud security services for managed MFA rollouts.
• Security awareness training — Phishing and social engineering cause the majority of breaches. Regular, practical cyber awareness training reduces the risk significantly — and a trained workforce is also a POPIA compliance requirement.
• 24/7 monitoring — Many breaches go undetected for weeks because nobody is watching the systems overnight or on weekends. Managed security monitoring detects anomalies in real time, often before data is exfiltrated.
• Access reviews — After a breach, audit who has access to what. Former employees with active accounts, overly permissive sharing settings, and service accounts with no password rotation are common entry points.
• A formal POPIA gap assessment — If this breach revealed that your POPIA readiness was incomplete, a structured assessment with your IT and compliance team will surface the remaining gaps before regulators do. Our security assessment service includes a POPIA readiness component.

---

Breach Response Checklist.

Use this checklist to guide your response the moment a breach is suspected:

• Contain — Isolate affected systems immediately. Do not wait for a full diagnosis.
• Preserve — Capture logs and forensic data before restoring or cleaning systems.
• Assess — Determine what personal information was involved and how many data subjects are affected.
• Activate — Notify your Information Officer, legal counsel, and senior management.
• Notify the Regulator — Submit an initial notification to inforeg.org.za as soon as possible, even if your investigation is not yet complete.
• Notify data subjects — Contact affected individuals with a plain-language explanation and practical guidance.
• Document everything — Maintain a detailed breach log from discovery through resolution.
• Review and improve — Conduct a post-incident review and implement the controls that would have prevented or limited the breach.

← Back to Blog