If your organisation has an annual turnover or revenue of KES 5,000,000 or more, or more than ten employees, and it handles personal data, you are required to register with Kenya's Office of the Data Protection Commissioner. Registration is mandatory: under the Data Protection Act 2019, no person may act as a data controller or data processor without it. Being a processor for someone else's data counts.
That is the short answer. The longer answer is that registration is the easy part — it is an online form and a fee — and the hard part is that the form asks you a question most engineering teams cannot answer from their own systems.
This is engineering context, not legal advice. Whether your organisation is caught, and on what terms, is a question for Kenyan-qualified counsel. What follows is what the obligation does to your codebase once counsel says yes.
What the registration actually requires
The mechanics are set by the Data Protection (Registration of Data Controllers and Data Processors) Regulations, 2021, issued as Legal Notice No. 265. Applications are submitted electronically through the ODPC website in the prescribed form, accompanied by a registration fee. The form asks for your organisational details and — this is the part worth your attention — a description of your processing activities.
The thresholds are not purely numerical. Turnover or revenue of KES 5,000,000 and above, or more than ten employees, are the headline triggers, but the regime also takes account of the nature of your industry, the volume of data processed, and whether sensitive personal data is involved. A six-person health-tech startup below the revenue line should not assume it is outside the regime on headcount alone.
The certificate is valid for two years, and must be renewed 30 days before expiry.
"A description of your processing activities" is a data inventory
Here is where most teams discover a gap. That phrase, read as an engineer rather than a lawyer, means: what personal data do you hold, where did it come from, why do you have it, who else sees it, and how long do you keep it.
Almost nobody can answer it from the system. They answer from memory, in a spreadsheet, the week before the application goes in. Six months later a feature ships that adds a new column, a new webhook, a new analytics destination — and the spreadsheet is now fiction while the certificate still says otherwise.
The fix is to make the inventory a property of the codebase rather than a document beside it. On any relational stack, that means:
- Annotate personal data at the schema layer. A comment on the column, a decorator on the model field, a tag in a central registry keyed by table and column. The mechanism matters less than the rule that a field holding personal data cannot be added without the tag.
- Generate the inventory, don't maintain it. A script that walks the schema and emits the current list of personal-data fields, their category, their purpose and their retention period. Run it in CI. If a tagged field appears with no declared purpose, fail the build.
- Include the edges, not just the database. The inventory that matters covers log lines, error trackers, analytics, your email provider, backups and every third party you POST a phone number to. If you take M-Pesa payments, the phone number and transaction reference moving through that integration are personal data, and your M-Pesa integration is a processing activity in the sense the form means, not just a payment path.
Done this way, the description you submit to the ODPC is an export, not an archaeology project.
Lawful basis and purpose limitation are schema decisions
The second thing teams get wrong is treating lawful basis, purpose limitation and data subject rights as things a privacy policy page asserts. They are structural.
Lawful basis. If some of your users' data is processed on consent and some on contract, you need to know which record is which. That is a column, a timestamp, and a version of the thing consented to — not a checkbox whose state you overwrite. A consent record you cannot reconstruct as of a past date is a consent record you cannot evidence.
Purpose limitation. "We collected this for delivery and now marketing wants it" becomes a schema question the moment you have declared a purpose per field. If purpose lives in the registry above, the awkward conversation happens at design review, not during an inquiry.
Retention and deletion. Deletion is the most expensive thing to retrofit, because production data has usually been copied into places nobody owns: read replicas, warehouse tables, a CSV in someone's Drive, three years of backups, a support tool. A deletion path that only clears the primary row is not a deletion path. Decide early whether a request means hard delete or anonymisation, and make it one call that fans out, with an audit record of what it touched.
Export. A data subject asking for their data should trigger a code path, not a person with SQL access. Build the export endpoint at the same time as the deletion one; they walk the same graph.
None of this is exotic engineering. It is cheap while the schema is young and genuinely painful at year three, which is the only real argument for doing it now. It is the same shape of work we describe for teams building into Nigeria's regime in our NDPR-compliant software guide — the instruments, the regulator and the thresholds differ, but the engineering that satisfies either is largely the same, which is worth knowing if you build for both markets.
The processor trap
Plenty of agencies, SaaS vendors and dev shops assume registration is their client's problem because the data belongs to the client. The Act does not read that way. It says no person shall act as a data controller or data processor without registering. If you host, store or transform personal data on another organisation's behalf, the duty attaches to you on your own facts, against the same thresholds.
That catches the obvious cases — multi-tenant SaaS, managed hosting — and less obvious ones: a production database dump kept on a laptop for debugging, an analytics contractor with read access to the warehouse.
If you are engaging a partner to build software in Kenya, this is a fair thing to ask about before the contract is signed, and it is one of the things we expect to be asked about our own app development work in Kenya.
Two years is a calendar obligation someone has to own
The certificate expires after two years and renewal is due 30 days before that date. Stated plainly: that is a recurring operational task with a hard deadline, and in most companies it belongs to nobody.
Two years is long enough that the person who filed the original application may have left. Put both dates wherever your TLS certificate expiries and domain renewals already live, with an owner's name attached, and treat renewal as the moment to regenerate the processing description from the schema and see what drifted.
What this changes
Concrete actions, in the order we would do them:
1. Tag personal-data fields in the schema and add a CI check that fails on an untagged or purpose-less addition.
2. Generate the processing-activity description from that registry, and submit the generated version rather than a hand-written one.
3. Store lawful basis as versioned, timestamped data, not mutable state.
4. Build export and deletion as real endpoints with audit records, fanning out to replicas, warehouse, logs and third parties.
5. Write down retention periods per data category and implement at least one automated job that enforces one of them, so the mechanism exists before you need five.
6. Assign the renewal. Calendar entry, named owner, 30 days before expiry, with regeneration of the description as part of the task.
7. Decide, with counsel, whether you are a controller, a processor, or both for each product you run — the answer can differ per product.
Doing this as engineering rather than paperwork means it survives contact with the next sprint. A document describing your data goes stale the moment someone merges. A generated one does not.
Again: this is engineering context, not legal advice. Confirm your own position — thresholds, classification, and what your registration must say — with Kenyan-qualified counsel.