What a data-protection-ready system actually looks like under the hood

When a law like Zambia’s Data Protection Act lands, founders often hand it to the nearest lawyer and the nearest developer, and hope the two meet somewhere. They rarely do. The lawyer writes a policy, the developer ships features, and the policy describes a system that doesn’t exist.

Here’s the version I’d rather see: the policy describes what the software does, because the software was built to do it. This post is for the person deciding what to ask their engineers for. It isn’t legal advice, so confirm the specific duties that apply to you with your counsel.

Know what you hold before anything else

Every other step depends on this one. Someone on your team should be able to answer, for each system: what personal data do we store, where, why, who can read it, and which other services receive a copy?

Most teams can’t, and the gap shows up the first time a customer asks what you hold about them. A simple data inventory, even a shared document kept current, is the foundation. In code terms, it helps to mark personal fields in your data model so they can be found, exported and removed on demand, instead of hunted down by hand.

Consent that you can prove

If you rely on consent, you need to show who agreed to what, when, and in which version of your notice. A checkbox that vanishes into the UI doesn’t give you that.

Store consent as its own record: the person, the purpose, the timestamp, the wording they saw, and whether it’s since been withdrawn. Make withdrawal as easy as giving it, and make sure it actually changes behaviour. If someone opts out of marketing, the next campaign run should skip them without anyone remembering to.

Access and correction requests

People have the right to see what you hold about them and to have errors fixed. For the engineers, that means an internal way to pull everything tied to one person across your systems and produce it in a readable form.

If answering a request means three developers querying four databases by hand, you’ll answer slowly and miss things. A single internal tool, even a crude one, changes that.

Deletion that deletes

This is where I see the biggest gap between promise and reality. A “delete account” button that sets a flag and leaves the rows in place isn’t deletion. Neither is removing the user record while their data lives on in an analytics warehouse, a search index and last month’s backups.

Decide what deletion means in your system. Often the answer is: remove or anonymise the personal data, keep what a legal or financial duty requires you to keep, and let backups expire on a schedule you can state. Then test it end to end, with a real account, and check every place the data went.

Access control and logs

Not everyone on your team needs to see every customer record. Give people the access their job needs and nothing more, and review it when roles change. A support agent rarely needs to export the whole user table.

Keep an audit trail of who accessed or changed personal data, and protect that log from the people it records. When something goes wrong, it’s the difference between “we think a few records were seen” and “here are the 212 that were, and by whom.”

Encryption and the boring basics

Encrypt data in transit and at rest. Hash passwords properly. Keep secrets out of source code. Keep production data out of test environments, or mask it first. None of this is clever, and most breaches I’ve read about came from skipping one of these.

A breach response plan is a document until the night you need it. Run it once as a drill and it becomes a process.

Retention: decide how long, then enforce it

“We keep data as long as needed” is a sentence, not a rule. Pick periods for each kind of data, write them down, and build the cleanup: a scheduled job that removes or anonymises what has outlived its purpose. Data you no longer hold can’t leak, can’t be subpoenaed, and doesn’t have to be explained.

Breaches and the 2am problem

The Act expects you to report certain breaches quickly. Whatever the current timeline is (confirm it with counsel), you can’t meet a short deadline if you’ve never decided who declares an incident, who tells the regulator, and who tells affected customers. Name those people in advance, give them the contact details they’ll need, and keep your logs good enough to scope the damage in hours.

Where to start

You don’t need all of this at once. If I had to pick three things for a team starting from nothing, they’d be the data inventory, deletion that really deletes, and role-based access with an audit log. Those three alone remove most of the everyday risk, and they make the rest easier to add later.

For the legal overview, see our guide to the Data Protection Act. For hosting questions, there’s a separate post on cloud and cross-border data. If you want a second pair of eyes on a system you’re building or inheriting, talk to us. Our in-house legal counsel is available to Bitsmiths clients when a question crosses from engineering into law.

• Ali