A Botswana privacy policy needs to cover, at minimum, what the Data Protection Act, 2024 itself requires a business to disclose under sections 39 to 41. That’s a narrower, more specific list than most generic templates cover, and it’s worth checking your policy against it directly rather than assuming a template pulled from an overseas site already handles it.

What the Act actually requires you to disclose

The full breakdown of a data subject’s rights, and what a controller has to tell them to make those rights usable, sits on how to exercise your rights. A privacy policy is where most of that disclosure happens in practice, so at minimum it needs to cover:

  • Who you are. The identity and contact details of the controller, and of the data protection officer if the business has one.
  • Why you’re processing the data, and on what basis. The purposes of the processing, and the lawful basis relied on for each one. “We use it to run our business” isn’t specific enough.
  • What you actually collect. The categories of personal data involved, not a vague catch-all.
  • Who else sees it. Who the data is shared with, and whether it leaves Botswana at all. If it does, see international data transfers for what that requires beyond disclosure.
  • How long you keep it. Data retention covers this properly, but the honest version for a policy is that the Act doesn’t set fixed retention periods for most processing. What it expects is that your business has actually worked out its own reasoning, tied to why the data was collected, and states that reasoning rather than leaving it out entirely.
  • What rights the person has, and how to use them. A plain statement of data subject rights and the practical steps to exercise them, not a copy-pasted list with no working contact route attached.

The disclosure most templates miss

Section 41 adds a requirement that almost no imported template accounts for: if the personal data wasn’t collected directly from the person themselves, for example if it came from a data broker, a public register, or a referral from someone else, the policy has to say where it came from. Most generic privacy policies are written on the assumption that all data comes straight from the person filling in a form, and simply don’t have a section for this. If your business buys in lists, receives referrals, or pulls information from a third party, this is worth checking specifically.

Where a policy also functions as a consent request, for a newsletter sign-up buried inside it, for example, section 27 requires that request to be clearly distinguishable from the rest of the document, not folded into dense paragraphs where nobody will notice what they’re agreeing to. See consent for the full conditions that apply. A privacy policy that asks for consent in the same font, same paragraph, same wall of text as everything else, doesn’t meet that bar.

It’s easy to treat a privacy policy as words that make a website look legitimate rather than as a document with actual legal content. It’s the latter.

A privacy policy is a compliance document

It’s easy to treat a privacy policy as words that make a website look legitimate rather than as a document with actual legal content. It’s the latter. Copying one from a different country’s website is the fastest way to get this wrong, because the rights section, the lawful basis language, and often the retention wording will reflect a different law entirely, one that doesn’t match what sections 39 to 41 of Botswana’s Act actually ask for.