Uganda's Data Protection and Privacy Act treats personal data with more seriousness than most organisations' current systems assume — and enforcement attention on this is only increasing. This is a plain translation of what it actually requires, not the legal text.
This article explains general principles to help you plan your systems. It is not legal advice — for a specific compliance question, please consult a qualified lawyer.
What counts as "personal data" here
Broader than most people assume: names, phone numbers, national ID numbers, location data, photographs, and any information that can identify a specific person, combined or alone. If your systems hold customer records, staff files, beneficiary data or even a supplier contact list, the Act applies to how you collect, store and use it.
Registration with the Personal Data Protection Office
Organisations that collect or process personal data as part of their operations are generally required to register with the PDPO. This isn't a one-time formality to file and forget — it's meant to reflect what you're actually doing with people's data, so it's worth revisiting when your systems or data practices change materially.
Having a lawful basis for collecting data
You need a clear, documented reason for collecting each category of personal data you hold — consent, a contractual necessity, or a legal obligation, among others. "We might need it someday" is not a lawful basis. This has a very practical consequence: it's worth auditing what data your systems currently collect and asking, honestly, whether you actually use all of it.
Consent has to be genuinely informed
A pre-ticked checkbox buried in page four of terms and conditions does not meet a reasonable informed-consent standard. People need to understand, in plain language, what data is being collected and why, before they hand it over. This is a design problem as much as a legal one — it's why our systems build consent language into the actual point of collection, not a separate document nobody reads.
Breach handling — the part most systems aren't ready for
If personal data is exposed through a breach, there are obligations to notify affected individuals and the relevant authority within a defined window. Meeting that window requires you to already know what data you hold, where it lives, and who to contact when something goes wrong — decisions that need to be made calmly in advance, not improvised during an actual incident.
Cross-border data transfers need extra care
Storing data with an international cloud provider, or sharing it with a donor or partner organisation based outside Uganda, can trigger additional requirements around where and how that data is protected once it leaves the country. This is directly relevant to the cloud-versus-on-premise decision many NGOs and businesses are weighing — see our related piece on cloud vs on-premise for NGOs for how the two questions connect.
Where we can help, and where we can't
We are not a law firm, and this article isn't legal advice — for a formal compliance opinion, talk to a lawyer who specialises in this area. What we do help with is the technical side: building the access controls, encryption, audit logging and breach-response tooling that turn a compliance requirement into something your systems actually satisfy day to day. See our cybersecurity service for how that usually starts.