You have 72 hours to tell the Information and Data Protection Commission, and depending on how serious the breach is, you may also have to tell affected customers directly. Data breaches covers the exact statutory text and timelines behind that. This article is the practical walk-through: what a Botswana business dealing with an actual breach needs to do, and when.

Take a realistic scenario: a business discovers its customer database was accessed by someone who shouldn’t have had access to it. Here’s how that plays out.

Hour zero: the moment you become aware

The 72-hour clock in section 63 starts from the moment the business becomes aware of the breach, not the moment the breach actually happened. A database could have been exposed for weeks before anyone notices it. Once someone does notice, that’s hour zero, and the countdown starts from there, not from whenever the exposure actually began.

The 72-hour clock starts from the moment the business becomes aware of the breach, not the moment the breach actually happened.

What to do first

Before drafting any notification, contain the breach: close off whatever access point was used, and work out, as fast as is realistically possible, what data was involved and roughly how many people are affected. You can’t write a meaningful notification without knowing what happened and to whom, so this isn’t a step you can skip to save time.

The 72-hour Commission notification

Where notification is required, it has to reach the Commission within 72 hours of that hour-zero moment, and it needs to contain:

  • the nature of the breach,
  • the approximate number of people affected,
  • a contact point for follow-up,
  • the likely consequences of the breach, and
  • the mitigation steps already taken.

That’s a real amount of detail to produce quickly, which is why the next point matters.

When you also have to tell the people affected

Separately from the Commission notification, a high enough risk to the affected individuals triggers a duty to notify them directly too, not just the regulator. This is a judgement call tied to how much actual harm the breach could cause someone, not a box that gets ticked every time a breach happens.

Two contrasting examples

Probably no Commission notification needed: a single laptop containing customer data is stolen, but the data on it was properly encrypted, in line with the data security measures the Act expects. Because the encryption means the data was never actually accessible to whoever took the laptop, the real risk to anyone’s rights is very low, even though a device physically left the business’s control.

Clearly needs notification: an unencrypted customer database, including phone numbers and ID numbers, is exposed publicly online. Here the data is fully accessible to anyone who finds it, the categories involved, especially ID numbers, carry real risk of misuse, and there’s no meaningful mitigating factor reducing that risk.

The obligation that applies either way

Regardless of whether a breach crosses the threshold for Commission notification, every breach has to be recorded internally. That documentation obligation doesn’t disappear just because you conclude the risk was low enough not to notify. If the Commission ever asks, the business needs to be able to show it assessed the breach properly, not that it simply decided nothing had happened.

Why an incident-response plan matters more than it sounds

Figuring out what happened, how many people are affected, and who to notify all takes real time, and 72 hours goes fast once you’re inside it. A business that only starts working out who’s responsible for what, and who to call, after a breach has already happened is unlikely to hit that window cleanly. Having an actual plan, however basic, in place beforehand is what makes 72 hours a realistic target rather than a countdown you’re racing from a standing start.