A data controller decides why personal data is processed and how. A data processor doesn’t decide either of those things: it processes personal data because a controller told it to, on the controller’s behalf. The roles aren’t interchangeable, and getting them backwards is one of the more common mistakes Botswana businesses make when working out who’s responsible for what.

A working example

Take a retail business that runs its own shop and employs ten staff. It hires an external bookkeeping firm to run payroll each month, using the employee records the retail business already holds: names, bank details, salaries, tax numbers.

The retail business is the controller. It decided to collect that employee data, and it decided why: to pay staff and meet its own tax obligations. The bookkeeping firm is the processor. It didn’t decide to collect the data, it isn’t accountable for why it exists, and it only touches it because the retail business instructed it to, for the specific purpose the retail business set: running payroll.

Two practical tests

If you’re not sure which role a business plays, ask two questions:

  • Who decided to collect this data, and why? That’s the controller. The retail business decided to hold employee records so it could run a business and pay its staff.
  • Who is just following someone else’s instructions, on data they don’t own the relationship with? That’s the processor. The bookkeeping firm has no independent reason to hold that employee data. It only has it because the retail business gave it access, for one specific job.

The twist: a processor can become a controller

The line isn’t fixed. A processor that starts making its own decisions about the data, beyond what it was instructed to do, becomes a controller for that particular use, under section 58. Sticking with the example: if the bookkeeping firm decided, on its own initiative, to pool payroll data from its various clients to run marketing analysis of its own, salary bands, spending patterns, whatever it found useful, it would be acting as a controller for that specific activity. It would no longer just be following instructions. It would have decided, unprompted, why that data should be used a new way, and that decision is exactly what makes a controller a controller.

That decision is exactly what makes a controller a controller.

The retail business’s payroll processing stays exactly as it was. The bookkeeping firm has simply picked up a second role, controller, for a use it invented itself.

Why the distinction actually matters

This isn’t just a labelling exercise. Two real consequences follow from it.

A written processing agreement is required. Where a controller hands personal data to a processor, sections 55 to 59 of the Act require specific terms to be in place between them before that processing happens. See processor agreements for what that agreement actually has to contain. Skipping this because “it’s just our bookkeeper” is a common gap.

Someone has to be first in line for a rights request. If an employee of the retail business asks to see what data is held on them, or asks for a correction, the retail business is answerable in the first instance, because it’s the controller. The bookkeeping firm isn’t who that employee should be contacting, and it isn’t positioned to decide how to respond on its own, since it doesn’t own the underlying relationship or the purpose behind the data.

Knowing which side of that line a business sits on, for each relationship it has, is the starting point for getting both of those things right.