Data protection by design and by default in Botswana

Section 52 of the Data Protection Act, 2024 requires a controller to build data protection into how it processes personal data, rather than treating it as something to fix after the fact. It has two parts: protection by design, which is about how systems are built, and protection by default, which is about what those systems do automatically unless someone changes them.

Protection by design

Section 52 requires a controller to implement appropriate technical and organisational measures, both at the time of determining the means of processing and at the time of the processing itself, designed to implement the data protection principles effectively and to integrate the necessary safeguards into the processing. In practice, this means a business has to think about data protection when it chooses a system or designs a process, not only when something goes wrong with it. A company building a new customer database has to consider access controls, retention and security while it is choosing the software and setting up the fields, not as an afterthought once the database is already full of customer records.

Protection by default

The “by default” half of section 52 is more specific. It requires ensuring that, by default, only the personal data necessary for each specific purpose is processed, measured across four things:

• the amount of personal data collected,
• the extent to which it is processed,
• the period it is stored for, and
• how accessible it is.

That means the default setting, the one that applies unless a person actively changes it, should already be the more protective option. A system that requires someone to opt out of wide data sharing has the default backwards. A system that starts with the most private setting and lets someone opt in to sharing more is doing what section 52 asks.

What this looks like on a sign-up form

A common example is a new customer sign-up form. If all a business actually needs to complete an order is a phone number, the form should ask for a phone number, not a full postal address, date of birth and employer “just in case it’s useful later.” Every extra field collected by default is personal data being processed beyond what the specific purpose requires, which is the exact problem section 52 is aimed at.

The same logic applies to privacy and account settings. A messaging feature that ships with profile visibility set to “public” and expects users to find the setting and switch it to “private” has built the wrong default. Setting it to “private” from the start, with sharing as something a user chooses to turn on, is what protection by default looks like in a product.

Why this connects to the rest of the Act

Section 52 is not a standalone rule. It is the mechanism for putting the data protection principles, particularly data minimisation, into the actual design of a system rather than leaving them as a policy statement. It also overlaps with data security: a system designed with fewer unnecessary fields and shorter retention by default is also a smaller target if something does go wrong. Getting this right at the design stage is generally far cheaper than retrofitting it into a live system once a customer base, and a habit of over-collecting, already exist.