Zambia’s Data Protection Act, explained for people who build and run software businesses

If you run a company that collects customer details, whether that’s a fintech app, a school portal, a logistics platform or a plain online shop, the Data Protection Act No. 3 of 2021 applies to you. It came into force in 2021, the Office of the Data Protection Commissioner is now operating, and registration of controllers and processors has been open for a while. “We’ll look at it when someone enforces it” is no longer a safe plan.

I’m an engineer, not a lawyer, so this is the engineering reading of the Act: what it asks your systems and your habits to do. For anything that depends on exact wording, take it to your legal counsel. I’ll say where that matters.

Two words to learn first

The Act sorts organisations into two roles. A data controller decides why and how personal data is used. A data processor handles data on a controller’s behalf and follows its instructions.

Most software businesses are both, depending on the day. If you run your own customer app, you’re a controller. If you build a payroll system that holds your clients’ staff records, you’re probably a processor for those clients and a controller for your own users. Work out which one you are for each system you run, because the duties and the contracts differ.

“Personal data” is broader than people expect. A name and a phone number count. So does an email, an NRC number, a device identifier, or anything else that can point back to a real person, even indirectly. “Sensitive” data, such as health, biometric, religious or criminal records, gets stricter handling.

What the Act asks of you

Reading the Act as a build list, it comes down to a handful of things.

Register. Controllers and processors are expected to register with the Data Protection Commissioner and display the certificate. This is the most visible obligation and the easiest one to check from outside.

Have a reason for every piece of data. You need a lawful basis for collecting something: consent, a contract, a legal duty, or a legitimate interest that doesn’t override the person’s rights. If you can’t say why you’re storing a field, that’s a sign you shouldn’t be.

Tell people what you’re doing. Before you collect data, say what you’re collecting, why, and who gets to see it. A privacy notice written in plain language does more good than a long one nobody reads.

Let people see and fix their data. People can ask what you hold about them, correct it, object to certain uses and ask for it to be deleted. Those requests need to be answerable by someone on your team, and your system has to be able to do it.

Keep it safe, and keep only what you need. The Act expects reasonable technical and organisational protection, and expects you to stop holding data once its purpose has passed.

Report breaches quickly. The window for telling the regulator is short. Ask your counsel for the current timeline, and decide today who on your team makes that call at 2am.

Name someone responsible. The Act expects a data protection officer, and certain high-risk processing calls for an impact assessment before you start.

Mind where the data lives. There are rules on storing data in Zambia and moving it out. That deserves its own explanation, which I’ve written up in a separate post on hosting and cross-border transfers.

Where companies usually trip

In my experience the problems are rarely dramatic. They’re ordinary.

A staging database holding a copy of real customer records, open to every developer. A spreadsheet of client IDs emailed around because the system had no export feature. A third-party analytics script nobody remembers adding. An admin panel where every employee sees everything. A “delete my account” button that hides the row and keeps the data.

None of these are exotic failures. They’re what a team accumulates when it moves fast and nobody owns data handling. The Act mostly asks you to own it.

And I haven’t even started on the customer lists, contracts and salary spreadsheets your employees are pasting into public AI chatbots to “save time.” That’s personal data leaving the building too, through a text box nobody thinks of as a data transfer. If you do nothing else this quarter, agree on which tools staff may use and what may go into them.

Compliance with a data protection law is mostly a record of decisions you’d already want to have made on purpose.

A sensible order of work

If you’ve done nothing yet, here’s the order I’d take it in.

1. Make a list of every system that holds personal data, and who can reach it.
2. Register with the ODPC if you haven’t, and confirm which role you hold in each system.
3. Write a plain privacy notice and put it where people actually see it.
4. Decide who handles access, correction and deletion requests, and test that they can.
5. Fix the ordinary problems above before you go looking for exotic ones.
6. Review your vendors and hosting, since your obligations follow the data to them.

An afternoon on step one tells you more about your risk than any checklist will.

Where a lawyer comes in

Questions about whether a particular use is lawful, what a contract with a vendor should say, or how to respond to a regulator’s query are legal questions, and you should put them to legal counsel. Bitsmiths clients can also use our in-house legal counsel for this. We keep the legal advice and the engineering advice in one conversation, which saves a surprising amount of back and forth.

If you’d like to walk through where your systems stand, get in touch.

• Ali