Your organisation holds people's data. Here's what Zambia's Data Protection Act means for your website and member systems.

If your organisation keeps a list of members, customers, donors, or voters — names, emails, phone numbers, ID or payment details — you are handling personal data, and in Zambia that now carries legal obligations under the Data Protection Act. Most of the organisations we work with are surprised by how much of the Act already touches something as ordinary as a membership register or a website contact form. This is a plain-language look at what it means for your website and internal systems, and the practical steps that actually matter. One honest caveat up front: this is general information, not legal advice — for the precise, current requirements and any penalties, confirm with the Office of the Data Protection Commissioner or your own legal counsel.

Start with what the law is actually about, because the principles are the ones you'd arrive at yourself if you thought about it from the other person's side. Collect only the data you genuinely need. Be clear about why you're collecting it. Keep it accurate and secure. Don't keep it forever. And don't use it for something the person never agreed to. A membership database, an event registration form, a payroll file, a board-election voter roll — every one of those is personal data the moment it can be tied to an identifiable person, and every one of those principles applies to it.

Your website is where a lot of this becomes concrete, because every contact form, newsletter signup, and online registration is a data-collection point. The Act's expectations show up as real, buildable site features: a clear privacy notice explaining what you collect and why, genuine consent rather than a pre-ticked box, a lawful reason for processing the data at all, and a route for someone to ask what you hold and have it corrected or deleted. If your current site gathers email addresses with no privacy notice and no record of how consent was given, that is the first and cheapest gap to close.

Some data sits at a higher bar. Health information, financial details, and anything tied to a secret ballot carry more risk and more responsibility. This is exactly the territory of the election and creditor-voting platforms we build — and the reason those systems verify eligibility, keep ballots secret even from the administrator, and hold an audit trail is not only good governance. It is the same standard of security and confidentiality that data-protection law expects of sensitive processing. Building for members' trust and building for the legal standard turn out to be the same job, which is a large part of why we build them the way we do.

Then there is the part nobody plans for until it happens: a breach. A lost laptop, a shared spreadsheet, a compromised email inbox. Data-protection regimes expect organisations to secure personal data proactively and to have a plan for when something goes wrong — knowing what was exposed, who needs to be told, and how quickly. For a small organisation this does not mean a security department; it means a few unglamorous habits. Give people access only to the data their role needs. Encrypt what genuinely matters. And stop emailing the full member list around as an attachment, which is the single most common way small organisations leak data without ever being hacked.

The Act also places obligations specifically on the organisations that decide how and why personal data is processed — which is you, if you run the member register or the customer database. The details here (any registration or notification steps, whether you need someone formally responsible for data protection, specific timelines, and the penalties for getting it wrong) are precise and can change, so they are exactly the things to confirm with the Commissioner's office or your lawyer rather than take from a blog — including this one. What can be said without any hedging is that "we didn't realise it applied to us" has never been a defence anywhere this kind of law exists, and Zambia is no exception.

If you want somewhere practical to start, work through five questions. Where is personal data collected and stored across your organisation — forms, spreadsheets, third-party tools, inboxes? Is there a plain privacy notice, and does every form capture real consent? Who can access what, and is any of that access wider than it needs to be? What data are you holding that you no longer have a reason to keep? And if something leaked tomorrow, would you know what was exposed and who to tell? None of this requires rebuilding your website. Most of it is process plus a few targeted changes to how your forms and systems handle data.

Compliance is not the reason to build good systems — but good systems make compliance close to automatic, because "collect only what you need, secure it, and be honest about it" is simply how member platforms and websites ought to be built in the first place. If you are not sure where your site or member system stands against any of this, that is a conversation we have with organisations regularly, and usually the earlier the cheaper.