When a client’s data is accessed by someone unauthorised, two statutory clocks start, and the stricter one belongs to the MSP. POPIA breach notification now runs through the Information Regulator’s eServices portal, and it asks for a timeline most small businesses can’t produce without their service provider’s logs. Here is what section 22 requires of your client, what section 21 requires of you, and which parts of your stack supply the evidence.
What triggers a POPIA breach notification?
The trigger is “reasonable grounds to believe” that personal information of a data subject has been accessed or acquired by an unauthorised person. Not proof, not a completed forensic investigation. Reasonable grounds.
That threshold is lower than most incident response plans assume. Teams commonly wait for certainty because they do not want to report something that turns out to be nothing, and in doing so they let the statutory clock run while they investigate.
The Information Regulator addressed this directly in its August 2025 fact sheet on handling security compromises. A responsible party should notify as soon as it is reasonably sure a compromise occurred. The investigation does not need to be complete. Report on the information at hand and update the Regulator later.
There is also no materiality threshold in the Act. All security compromises must be reported, regardless of how small the affected dataset looks.
What is an MSP’s duty in a client breach?
An MSP that processes personal information on a client’s behalf is an operator, and under section 21(2) an operator must notify the responsible party “immediately” where there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person. Immediately, not as soon as reasonably possible.
Read that twice. Your notification clock is stricter than your client’s. A provider that spends two days confirming an incident before phoning the client has already failed its own statutory duty.
Build the escalation path now. Who at the client gets called, on what number, at what hour, and what gets said before the forensics are finished. Our guide on ransomware in South Africa covers the incident mechanics this sits on top of.
Who must be notified and when?
Section 22(1) of POPIA requires the responsible party to notify both the Regulator and the affected data subjects, unless a data subject’s identity cannot be established. Both, not either.
The timing standard in section 22(2) is “as soon as reasonably possible after the discovery of the compromise”, taking into account the legitimate needs of law enforcement and any measures reasonably necessary to determine the scope of the compromise and restore the integrity of the information system.
Note what POPIA does not say. There is no 72-hour rule. South African practitioners frequently import the GDPR deadline out of habit, and it is not in the Act. That cuts both ways: there is no safe harbour at hour 71 either, and “as soon as reasonably possible” is judged after the fact by a regulator reading the incident timeline you helped write.
Delay is permitted in one narrow circumstance. Under section 22(3), notification of the data subject may be delayed only if a public body responsible for the prevention, detection or investigation of offences, or the Regulator itself, determines that notification will impede a criminal investigation. That ground never applies to notifying the Regulator.
How do you notify the Information Regulator?
Notification goes through the Information Regulator’s eServices portal, and only through it. From 1 April 2025 the portal became mandatory for section 22 notifications and the old Security Compromise Notification Form is no longer accepted. A notification submitted any other way is treated as non-compliant.
Here’s the operational detail that catches organisations out. Registration takes time, needs the right person to hold the credentials, and cannot sensibly be done at 23:00 on the night an intrusion is discovered.
The client is the responsible party, so the portal account should be theirs. Make checking it part of onboarding. Confirm at least two people at the client can log in, because the one person who set it up will inevitably be on leave. If you want help building this into a client-ready incident process, you can talk to our team about partner enablement.
What must the notification to data subjects contain?
Section 22(4) requires the notification to a data subject to be in writing, delivered by at least one of five routes: posted to their last known physical or postal address, sent by email, placed in a prominent position on the responsible party’s website, published in the news media, or as directed by the Regulator.
Section 22(5) sets out what it must say. Enough information to allow the data subject to take protective measures, including a description of the possible consequences of the compromise, a description of the measures the responsible party intends to take or has taken to address it, a recommendation on what the data subject should do to mitigate adverse effects, and the identity of the unauthorised person if known.
Section 22(6) allows the Regulator to direct a responsible party to publicise the compromise. Tell the client that before they draft a carefully minimised statement.
Which tools produce the evidence section 22 asks for?
Section 22 evidence comes from three places in a managed stack: detection, logging and recovery. The notification has to describe what happened and what is being done about it, and the Act allows time to determine the scope of the compromise and restore the integrity of the information system. Each of those is a tooling question, and your client will bring it to you.
Detection starts the clock. Reasonable grounds arrive when somebody notices. Barracuda Managed XDR commits to responding to high-risk incidents within 20 minutes, and SonicWall publishes a four minute average SOC response for SonicSentry MXDR. Our managed XDR guide for MSPs covers the build-or-buy decision behind both.
Logging builds the timeline. Mail flow and the network edge are the first places to look. Email security logs from Barracuda Email Protection and firewall logs from SonicWall network security are usually the first two sources a timeline draws on. Check the retention period on both, because a log that rolled over last week is no use against an intrusion that began two months ago.
Recovery restores integrity. Immutable backup is what lets you restore a system you can trust. Arcserve, Barracuda and Wasabi all offer immutable storage, and our cloud backup guide explains the difference between the modes.
IS YOUR INCIDENT PROCESS READY FOR A REAL NOTIFICATION?
We help South African partners build detection and response that produces the evidence section 22 asks for.
Start my partner enquiry
How often is this actually happening?
The Information Regulator reported in August 2026 that it had received more than 8,000 security compromise notifications since POPIA’s enforcement provisions commenced, with more than 1,220 arriving since 1 April 2026 alone. It projected the year would pass 3,000 and called the rate very alarming.
In the 2024/25 financial year the figure was 2,374, averaging 198 per month. From April 2025 that rose to roughly 284 per month. The Regulator attributed the increase to inadequate security controls, employee negligence, weak passwords and ransomware.
Every one of those notifications represents an organisation that had to produce a timeline, and a timeline is only as good as the logging behind it.
What has the Regulator fined people for?
Lancet Laboratories is the clearest notification case. It failed to report security compromises and to inform the affected people, and was fined R100,000, which was paid. The penalty was for the notification failure itself rather than the underlying security incident.
The larger point is the enforcement chain. A notification failure exposes the responsible party to an enforcement notice, and ignoring an enforcement notice is the offence that carries up to R10 million or 10 years. The Department of Justice was fined R5 million on exactly that basis after letting an enforcement notice lapse without response.
Answering the Regulator promptly is, on the public record, worth more than any other single thing a client does after a breach.
What should an MSP put in place this month?
An MSP should first confirm that every client is registered on the eServices portal and that the credentials are reachable out of hours. Agree in writing who decides that “reasonable grounds” has been met, on your side and on theirs, because in the moment that decision stalls without a named owner.
Put the section 21(2) call into your own runbook: the client contact, the number, and the first three sentences. Draft the data subject notification template for them, covering the four elements section 22(5) requires, so everyone is editing rather than writing during an incident.
Check that your logging supports a timeline: which records were accessed, by whom, when. Most providers discover the gap only when the Regulator asks the client and the client asks them.
Then rehearse it once with a real client. An incident process nobody has walked through is a document, and section 22 does not ask for documents.
BUILDING INCIDENT RESPONSE FOR SOUTH AFRICAN CLIENTS?
Loophold distributes the SonicWall, Barracuda, Arcserve and Wasabi products that detection, logging and recovery depend on.
Become a Loophold partner
