POPIAdesk

Guide

Data breach under POPIA: section 22 notification explained

Data BreachSection 22Notification

When personal information in your care is accessed or acquired by someone unauthorised, section 22 of POPIA puts two notification duties on your business: tell the Information Regulator, and tell the affected people. The deadline is not a fixed number of hours; section 22(2) requires notification as soon as reasonably possible after you discover the compromise, allowing time to establish its scope and to accommodate law enforcement. The notice itself has prescribed content under section 22(5), data subjects must be told in writing through the channels section 22(4) lists, and delaying their notification is lawful only in the narrow case section 22(3) describes. Here is how each piece works.

For the broader picture - what counts as a breach, with examples, and how to prepare before one happens - see our overview of POPIA breach notification. This article is the close reading of section 22 itself.

What triggers the duty

Section 22(1) sets the threshold: reasonable grounds to believe that the personal information of a data subject has been accessed or acquired by an unauthorised person. Two things follow from that wording:

  • You do not wait for certainty. The duty attaches to reasonable grounds for belief, not to forensic proof. If the evidence in front of you would make a reasonable person conclude information was probably taken, the section is engaged.
  • Both notifications arise together. The Regulator is always notified. The data subjects are also notified, with two exceptions only: where their identity cannot be established (the section 22(1) proviso), and where notification is delayed under section 22(3).

One more piece sits just outside section 22: if the compromise happens at an operator - your hosting provider, payroll bureau, or any other processor - section 21(2) requires the operator to notify you immediately on the same reasonable-grounds threshold. The section 22 duties to the Regulator and the data subjects remain yours, which is one reason the written operator agreement matters.

The deadline: as soon as reasonably possible

Section 22(2) requires notification as soon as reasonably possible after discovery of the compromise, taking into account two things: the legitimate needs of law enforcement, and any measures reasonably necessary to determine the scope of the compromise and to restore the integrity of your information system.

Note what the Act does not say: there is no 72-hour deadline in POPIA. The 72-hour figure that appears in most breach advice comes from the GDPR, a different law. Under POPIA the clock is "as soon as reasonably possible", which cuts both ways: you may take the time genuinely needed to understand what happened, and you may not sit on a notification you are already able to make. Many businesses, ours included, adopt 72 hours as an internal ceiling because it is defensible evidence of acting promptly - but treat it as discipline, not as the statutory number.

What the notification must contain

Section 22(5) requires the notification to give the data subject enough information to take protective measures, including at least:

  • The possible consequences of the compromise (section 22(5)(a)) - what someone holding this information could do with it.
  • The measures you have taken or intend to take to address it (section 22(5)(b)).
  • What the data subject can do to mitigate the possible adverse effects (section 22(5)(c)) - change passwords, watch statements, place a fraud alert.
  • The identity of the unauthorised person who may have accessed or acquired the information, if known (section 22(5)(d)).

A precision worth having: the identity in section 22(5)(d) is the intruder's, not your Information Officer's. The Regulator's breach-reporting process does ask for your Information Officer's details along with more operational specifics, so have them at hand when you report - but on the statutory list, (d) is about who took the data.

How data subjects must be told

Section 22(4) requires the notification to data subjects to be in writing, communicated in at least one of the listed ways: mailed to the data subject's last known physical or postal address, sent to their last known email address, placed prominently on your website, published in the news media, or as the Regulator may direct. For most businesses email plus a website notice is the practical pair; the point of the list is that a notification nobody could reasonably have seen does not count.

When notification can wait, and when it cannot

Three separate provisions get conflated here, and keeping them apart matters:

  • Scoping time (section 22(2)). Time reasonably needed to establish what happened and to restore your systems is built into the deadline itself. This is not a delay; it is the clock working as designed.
  • Criminal-investigation delay (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, determines that notifying would impede a criminal investigation. The determination is theirs, not yours - deciding on your own that notification is awkward does not qualify, and the delay ground applies to the data-subject notice, not the report to the Regulator.
  • Directed publicity (section 22(6)). The Regulator can order you to publicise the compromise in a specified manner if it has reasonable grounds to believe the publicity would protect affected data subjects. Notification is the floor, not the ceiling.

Responding under section 22: five steps

  1. Contain, and start the log. Revoke the access, rotate the credentials, isolate the system - and record every action with a timestamp from the first minute. The log is how you later demonstrate "as soon as reasonably possible" was real.
  2. Establish scope. Which records, which people, which fields, over what period. Section 22(2) gives you this time; use it to make the notification accurate rather than vague.
  3. Notify the Regulator. Breach reports are submitted through the Regulator's eServices portal - the same profile your Information Officer registration lives on. Have the incident timeline, the categories of information involved, and your Information Officer's details ready.
  4. Notify the affected people. In writing, through a section 22(4) channel, with the section 22(5) content. Write it for the reader: what happened, what it means for them, what you have done, what they should do now.
  5. Close the loop. Finish remediation, keep the file - notifications sent, channel used, dates, the full log - and be ready for follow-up questions or a section 22(6) direction from the Regulator.

POPIAdesk generates the breach notification letter with the section 22(5) content structured for you, pre-filled with your organisation's details, so the drafting is not happening for the first time at 2am during an incident. Preparing that letter before you need it is step six of our POPIA compliance checklist.

Frequently asked questions

Does POPIA give us 72 hours to report a breach?

No. POPIA's deadline is "as soon as reasonably possible" after discovery, per section 22(2). The 72-hour figure is the GDPR's, and it has no statutory force in South Africa. Adopting 72 hours as your own internal ceiling is sensible practice precisely because the Act's standard is open-textured, but the number is yours, not the law's.

Do we have to notify for every security incident?

No. The section 22(1) threshold is reasonable grounds to believe personal information was accessed or acquired by an unauthorised person. A blocked attack, a laptop that never left encrypted, or an incident touching no personal information does not meet it. A stolen unencrypted laptop, a mailbox compromise, or ransomware on a server holding customer records almost certainly does. When the call is genuinely close, notifying is the defensible side to err on.

Can we hold back notification so we do not tip off the attacker?

Only within the Act's own allowances. Time reasonably needed to determine scope and restore your systems is already accommodated by section 22(2). Beyond that, the data-subject notification may be delayed only where a law-enforcement body or the Regulator determines it would impede a criminal investigation (section 22(3)). That determination cannot be your own, and it does not suspend the report to the Regulator.

Know where you stand before it happens

A breach is a bad moment to discover the rest of your compliance is missing - the Regulator's first questions assume an Information Officer, a privacy policy, and records that exist. The free POPIA assessment takes about five minutes and shows you which pieces are in place.

This is general information, not legal advice. For your specific situation, consult an attorney.

POPIAdesk is not open yet

The product generates the documents and tracks the deadlines this guide describes. Send us an email and we will reply once, on the day it opens.