How long do you have to report a data breach in Botswana?

A controller has 72 hours, where feasible, to notify Botswana’s Information and Data Protection Commission after becoming aware of a personal data breach. That deadline comes from section 63 of the Data Protection Act, 2024, and it is one of the few hard timelines the Act sets anywhere. If the breach is also likely to pose a high risk to the people affected, a separate duty under section 64 requires telling them directly, not just the Commission.

The 72-hour rule (s.63(1) and (2))

Section 63(1) sets out the core timeline:

“…without undue delay and, where feasible, not later than 72 hours…”

after the controller becomes aware of the breach, unless the breach is unlikely to result in a risk to the rights and freedoms of data subjects. Two things follow from that wording. First, “without undue delay” is the actual standard, and 72 hours is the outer limit where notifying that fast is feasible, not a grace period to use in full by default. Second, there is a built-in exception: if a breach genuinely poses no real risk to data subjects, notification is not required at all.

If notification happens after the 72 hours has passed, section 63(2) requires it to be accompanied by reasons for the delay. Missing the deadline is not automatically a breach of the Act on its own, but showing up late with no explanation is treated differently from showing up late with a documented reason.

When a processor is involved (s.63(3))

Where a processor, rather than the controller itself, discovers the breach, section 63(3) requires the processor to notify the controller without undue delay on becoming aware of it. The processor does not notify the Commission directly. The chain runs from processor to controller to Commission, which means the 72-hour clock for the controller’s own notification effectively starts running from whenever the processor tells it, so a slow processor can eat into the time the controller has left to act.

What the notification to the Commission has to contain (s.63(4))

Section 63(4) requires the notification to describe:

• the nature of the breach, including, where possible, the categories and approximate number of data subjects and records concerned,
• the name and contact details of the data protection officer or another contact point,
• the likely consequences of the breach, and
• the measures taken or proposed to address the breach and mitigate its effects.

Documenting every breach (s.63(6) and (7))

Every breach has to be documented, including the facts of what happened, its effects, and the remedial action taken, so that the Commission can verify compliance with section 63. This applies whether or not the breach ends up meeting the threshold for notification: a business needs a record even of the breaches it decides, on the “unlikely to result in a risk” test, did not need to be reported.

Telling the people affected (s.64)

Where a breach is likely to result in a high risk to the rights and freedoms of natural persons, section 64(1) requires the controller to communicate the breach directly to the affected data subject or subjects, without undue delay. This is a separate and higher threshold than the one for notifying the Commission: many breaches will need to be reported to the Commission without also triggering the direct-notification duty to individuals, because “a risk” and “a high risk” are not the same test.

Section 64(3) sets out three situations where direct notification to individuals is not required, even if the high-risk threshold is otherwise met:

• the data was rendered unintelligible to unauthorised persons, for example through proper encryption,
• the controller has since taken measures that mean the high risk is no longer likely to materialise, or
• direct notification would involve disproportionate effort, in which case a public communication must be used instead of individual notices.

Even where a controller decides one of these applies and direct notification is not needed, section 64(4) allows the Commission to itself require the controller to notify data subjects if it disagrees with that decision.

A realistic example

A business whose customer database is exposed in a hack generally has three days to notify the Commission, unless it can show the exposure was unlikely to pose a real risk to the people in it. If the exposed data included things like national ID numbers or financial details, that data is very unlikely to clear the “no risk” bar, and the business will also likely need to tell the affected customers directly under section 64, unless the data was properly encrypted or one of the other section 64(3) exceptions genuinely applies. Getting the security measures right in the first place is what keeps a business out of this situation altogether.