Every semester I ask my students to build a small system for a real problem. A booking page for a salon, a fee tracker for a school, a sign-up form for a youth football league. The ideas are good. The code usually works by the second week. And almost every time, when I open the database, I find the same thing: full names, phone numbers, National ID numbers, sometimes photos, all sitting in a table with no password hashing and no explanation of why any of it was collected.
When I ask "who gave you permission to hold this?", the room goes quiet. Nobody has told them that in Uganda this is not just a bad habit. It is a legal matter. This post is the conversation I now have with every class, and with the small businesses I advise, before anybody collects a single phone number.
The law most developers have never read
Uganda passed the Data Protection and Privacy Act in 2019, and the detailed Data Protection and Privacy Regulations followed in 2021. You can read the Act itself on the Parliament of Uganda website, and NITA-U keeps a copy on its laws and regulations page. The Regulations are published as Statutory Instrument No. 21 of 2021.
The Act covers anyone who collects or processes personal data. That is not only banks and telecom companies. If your app stores a customer's name and number, you are inside the law. The Act talks about three roles: the data subject (the person the data is about), the data controller (whoever decides why and how the data is used) and the data processor (whoever handles it on the controller's behalf). A student who builds an app for a client is often a processor. The client is the controller. Both have duties.
Step one: register
This is the part that surprises people most. Section 29 of the Act requires the Personal Data Protection Office, which sits under NITA-U, to keep a Data Protection Register of every person, institution or public body collecting or processing personal data, along with the purpose. Regulation 15 says every data collector, processor and controller must register. The Office publishes guidance notes for registration that explain the form and the classification.
Failing to register is an offence. The penalty in the Regulations is a fine of up to six currency points or up to three months in prison, or both. The guidance notes put the fine at UGX 120,000. That is small in money terms, and I will be honest that I rarely hear of small organisations being chased for it. But the register is where the regulator starts. It is also the first thing a serious client, a bank or a donor will ask to see. A founder who can say "we are registered and here is our purpose statement" looks very different from one who cannot.
What I saw in a real consulting job
Last year I was asked to review a membership system for a small organisation. The staff were careful people and the system worked. But during the review we found that the sign-up form asked for date of birth, home address and National ID number, while the only thing the organisation actually did with members was send them a monthly newsletter and a payment reminder. Email and phone were enough.
We removed three fields, deleted the stored values for everyone who had joined, and rewrote the sign-up page to say plainly what the data was used for. The form became shorter, and sign-ups did not drop. If anything, people finished the form more often. That small change did more for the organisation's risk than any firewall would have.
It also taught me the rule I now repeat in class: the safest data is the data you never collected.
The principles, in plain language
Section 3 of the Act sets out the principles that every controller and processor must follow. I explain them to students with questions they can ask about their own projects.
- Is this data really needed? Collect only what the purpose requires. A library app does not need a home address.
- Did the person agree? Consent should be clear and informed. A pre-ticked box buried at the bottom of the page is weak.
- Did you tell them why? Say what you collect, what you do with it, and who else sees it.
- Is it accurate and kept only as long as needed? Old data that nobody uses is a liability. Delete it on a schedule.
- Is it protected? The Act requires appropriate technical and organisational security measures. This is where your engineering skills come in.
People also have rights. They can ask to see what you hold about them, ask for corrections, and object to certain uses. If your system has no way to export or delete one person's records, you will struggle to honour a request when it arrives. Build that feature early, while the database is small.
The technical side students forget
Compliance is not only paperwork. Most of the failures I see in student and startup projects are plain engineering mistakes, and they map directly to the security duty in the Act.
First, passwords. Never store them in plain text, and never use a fast hash like MD5. Use bcrypt or Argon2, which frameworks such as Laravel and Django already do for you if you let them. Second, transport. Run everything over HTTPS, including the admin page. Third, access. Not every staff member needs to see every record, so give people the smallest permissions that let them do their job. Fourth, backups. A backup of a database full of personal data is still personal data, so protect it the same way and do not email it around.
Then there is the habit I find hardest to break in students: sharing a spreadsheet of real user data in a WhatsApp group "so the team can test". Use fake data for testing. If you must use real records, strip names and numbers first. A leaked class WhatsApp export is exactly the sort of event the Act calls unlawful disclosure.
What the penalties look like
The small registration fine is the minor end. The offences section is more serious. Under section 35, unlawfully obtaining or disclosing personal data can lead to a fine of up to 240 currency points, imprisonment of up to ten years, or both. Selling personal data is its own offence. And where a company commits an offence, the officers who knowingly allowed it can be held liable too, and a court can add a fine of up to two percent of the company's annual gross turnover. You can check each of these in the consolidated text of the Act on the NITA-U site. Read the original wording yourself rather than trusting my summary, because laws get amended and revised.
I am a teacher and an IT practitioner, not a lawyer. If your organisation handles sensitive data such as health or financial records, get proper legal advice. What I can say from the engineering side is that most of the Act is simply good practice written down.
A short checklist before you launch
- Write down every field you collect and the reason for each. Delete any field you cannot justify.
- Register with the Personal Data Protection Office and keep your registration details somewhere visible.
- Add a short privacy notice in plain English, linked from every form that collects data.
- Hash passwords, use HTTPS, and restrict who can open the database.
- Build a way to find, correct and delete one person's data.
- Use fake data in development and testing.
- Decide how long you keep records, and set a reminder to clear them.
Why this matters for your career
Employers in Uganda are paying more attention to this. Banks, telecoms, NGOs and government projects now ask vendors how they handle personal data. A junior developer who can talk about consent, retention and registration stands out from one who only knows frameworks. In my own classes the students who take this seriously tend to be the ones who get trusted with real client work.
So before your next project collects its first phone number, open the Act, read sections 3, 29 and 35, and fix your sign-up form. It takes an afternoon. It is the cheapest security improvement you will ever make, and it protects the people who trusted you with their details.