Controller or Processor? Who Owes What Under Kenya's Data Protection Act
The Data Protection Act 2019 made every Kenyan business that holds staff or customer records a data controller with statutory duties. Most of those duties are yours and cannot be bought — but a handful of them are properties of the system you keep the records in. Here is the line between the two.
Most Kenyan businesses met the Data Protection Act as a compliance rumour: something about registering with a commissioner, something about a data protection officer, probably something a lawyer handles. Then a staff member asked for a copy of everything held about them, or a laptop went missing, or a donor asked how personal data is protected — and the rumour became a question with a deadline.
The Act itself is not mysterious. What causes trouble is the boundary: which duties belong to you as an organisation, which are properties of the software your records live in, and which are neither — obligations no vendor can discharge on your behalf no matter what their brochure implies. Getting that boundary wrong in either direction is expensive. Assume the software handles it and you are exposed. Assume nothing helps and you spend money on lawyers to describe a system that could have answered the question itself.
This article and its companion
This one is about who owes what — the controller and processor boundary, which of the Act's duties are genuinely yours, and what belongs in a processing agreement. If your question is instead what to do this week — where personal data is hiding in your operation, how retention actually behaves in software, and how to handle a data-subject request — start with Kenya's Data Protection Act, retention and deletion. Neither is legal advice, and nothing here states a threshold, deadline or penalty figure: confirm your specific position with the ODPC and a qualified adviser.
What the Act actually asks of you
The Act applies if you process personal data of people in Kenya — which means every employer with a payroll, every business with named customers, and every organisation with a supplier contact list. Not just large or "tech" companies. The duties that most often become operational rather than legal:
| Duty | What it means in practice | Where it lands |
|---|---|---|
| Registration with the ODPC | Controllers and processors above the prescribed thresholds register with the Office of the Data Protection Commissioner | Legal and administrative — entirely yours |
| Lawful basis and purpose limitation | You can say why you hold each category of data and stay within that purpose | A policy decision, documented by you |
| Data subject rights | A person can ask what you hold, ask for correction, and in defined circumstances ask for erasure | Partly the system — it has to be able to produce and erase |
| Data minimisation and retention | You do not keep personal data longer than the purpose requires | Partly the system — something has to actually delete |
| Security safeguards | Appropriate technical and organisational measures against unauthorised access | Split — the system provides controls, you configure and enforce them |
| Breach notification | Notify the ODPC, and affected people, within the timeframes the Act sets | A process you own — software can only tell you something happened |
| Impact assessment for high-risk processing | A documented assessment before you start processing that carries real risk | Yours, though the system determines several of the answers |
Read that last column carefully, because it is the whole point of this article. Four of the seven are wholly or largely yours. Three are shared. Not one is something you can outsource to a software purchase, and any vendor telling you their product makes you compliant with the Data Protection Act is describing something that cannot exist.
No software makes you compliant with the Data Protection Act. Some software makes the questions answerable — which is a different and much more useful claim.
Controller and processor: the boundary that decides who does what
The Act distinguishes the controller — who decides why and how personal data is processed — from the processor, who processes it on the controller's instructions. If you keep your staff and customer records in a hosted system, you are almost always the controller and your software provider is a processor. That is not a technicality; it determines who answers when the ODPC or a data subject asks.
Who is responsible for what
You, the controller
You decided to collect this data, for these purposes, about these people.
- Registering with the ODPC where the thresholds apply to you
- Deciding your lawful basis for each category of personal data
- Issuing privacy notices to staff, customers and suppliers
- Deciding retention periods — how long is long enough for your purposes
- Responding to data subject requests within the statutory timeframe
- Notifying the ODPC and affected people of a reportable breach
- Appointing a data protection officer if your processing requires one
Your software provider, the processor
We hold and process the data you put in, on your instructions, and nothing more.
- Processing only on your documented instructions, not for our own purposes
- Providing the technical controls — access control, audit logging, encryption of sensitive fields
- Providing the mechanics to export and erase an individual's data on your instruction
- Providing retention settings that actually delete when the period expires
- Notifying you promptly of a breach affecting your data so your clock can start
- Maintaining a processing agreement and a disclosed list of sub-processors
What has to cross the boundary, in writing
- A data processing agreement — not a paragraph in the terms of service
- Who the sub-processors are and where they process, since transfers outside Kenya have their own requirements
- How fast you will be told about a breach, because your notification clock depends on theirs
- What happens to your data when the contract ends, and how you get it out first
The single most useful sentence in any processing agreement is the one that says how fast you will be told about a breach. Your statutory clock starts when you become aware — so a provider who tells you a week later has spent your deadline for you.
Our own positions on each of these are published at the compliance matrix and the data processing addendum rather than described in sales conversations, and you should expect the same of any provider — a document you can send to a lawyer, not an assurance you have to remember.
The four things a system has to be able to do
Strip away everything that is policy and paperwork, and a small number of duties reduce to mechanical questions about your software. These are worth testing before you need them, because each one is answered under time pressure when it finally arrives.
-
Produce everything held about one named person
A data subject access request is a search across every table that mentions someone. If the answer involves a developer writing queries against a database, you do not have days of work ahead of you — you have an unknown amount, and no way to be sure you found everything.
-
Erase a person without destroying the record of what they did
This is the subtle one. Erasing an employee must not delete the approvals they gave or the stock movements they recorded, because those are your business records and in many cases you are legally required to keep them. What has to disappear is the personal identity attached to them.
-
Actually delete data when the retention period expires
A retention policy that nothing enforces is a document, not a control. Something has to run on a schedule and remove what is past its period — and you should be able to see that it ran.
-
Show who accessed what
When you have to assess whether a breach is reportable, the question is what was actually accessed and by whom. Without an access record, every incident is worst-case by default, because you cannot prove it was not.
Test the erasure, not the promise
Ask a vendor to erase a test user in front of you, then show you that the approvals that user gave are still intact and still auditable. A vendor whose erasure deletes the audit trail has handed you a different compliance problem. A vendor whose erasure leaves the name in the audit trail has not erased anything.
Where AWRA OpsHub sits on each of these
Because this is a subject where vague reassurance is the industry norm, here is the four-way split — what is built, what you configure, what remains yours regardless of what you buy, and what we have not built.
Data protection duties, by who actually discharges them
Data subject access — producing everything held about one person
A per-user data export runs on a queue and delivers a secure download link, gathering the personal data held across the system rather than one screen's worth. Restricted to users with the permission to view users.
Erasure that preserves the business record
Erasure replaces the person's name, email, phone and country with erased placeholders, clears their photo, social identity and authentication secrets, deletes their sessions, API tokens and role assignments, deactivates the account, and rewrites their name and email in the audit log — while the audited actions themselves survive. The erasure is itself audited.
Encryption of the most sensitive personal fields
Employee bank account names and numbers, mobile money numbers and statutory identity numbers are encrypted at the application layer rather than sitting in plain text in the database.
Access logging — who did what, from where
An audit log records actor, action, module, route, method, IP address, user agent, session and the affected record. Document vault access is logged separately, and impersonation by support is logged as its own event type.
Retention periods for logs and operational data
Per-category policies ship with defaults you can change — audit logs at 730 days, sessions at 30, notifications at 180, and so on across roughly forty categories — enforced by a scheduled job with a dry-run mode. Note the scope carefully: this covers logs and operational data plus the purge window on trashed records. It does not quietly age out live customer or employee records, and assuming it does is the most common mistake on this subject. The mechanics are covered properly in retention and deletion.
Who can see which personal data
Role and permission assignment is yours. The system enforces whatever you configure, which means it also faithfully enforces a configuration where everyone can see everything.
Authentication strength — MFA, allowed networks, device control
Multi-factor authentication can be set to required for your whole organisation rather than merely recommended, access can be restricted to specific IP addresses, devices are fingerprinted and can be locked or revoked, and idle sessions time out. All off or permissive until you turn them on.
ODPC registration, lawful basis, privacy notices, DPO appointment
These are organisational obligations. No configuration screen discharges them, and any vendor implying otherwise is selling you a false sense of completion.
Deciding your retention periods
We can enforce a period. Choosing it is a decision about your purposes, your sector's record-keeping rules and your risk appetite, and it should be written down and dated.
Breach notification to the ODPC and affected people
There is no breach register, no notification workflow and no statutory-clock tracking in the product. Security signals are surfaced for you to investigate; deciding whether something is reportable and notifying within the timeframe is a process you must own, with named people and a rehearsed playbook.
Data protection impact assessments
No DPIA tooling. The system can tell you what data exists, who can reach it and how long it is kept — which are several of the answers — but the assessment is a document you produce.
Consent capture and a record of processing activities
There is no consent management module and no ROPA generator. If your lawful basis is consent, you need to capture and evidence it somewhere, and today that is outside the product.
The export and erasure mechanics were built to the GDPR pattern, which is why they are named for it in the product. The mechanics — access, rectification, erasure, retention — are what the Kenyan Act's data subject rights also require, so they serve both. But the naming is a fair warning about origin, and you should satisfy yourself that the mechanics meet your specific obligations rather than trusting the label.
The gap that catches people out
Almost every organisation that fails a data protection question fails it on the same thing, and it is not a missing feature. It is that personal data lives in more places than the system of record.
- The spreadsheet on the finance laptop with staff salaries and national ID numbers, emailed to three people last April.
- The WhatsApp group where photographs of customer ID documents were shared to verify a credit sale.
- The recruitment inbox holding two years of CVs from candidates you never hired and never told you were keeping.
- The old system you migrated off and left running "in case we need to look something up".
- The consultant's copy of the staff list, sent for a project in 2024, never asked back.
A data subject access request covers all of it. So does a breach. Which is why the operational answer to data protection is the same as the operational answer to shrinkage or to a clean audit: reduce the number of places the truth lives. The full inventory exercise — including the categories most often forgotten — is in retention and deletion, and the reconstruction discipline is in what an audit trail actually has to reconstruct.
The access side of that is roles and permissions as a design problem and getting back from everyone-is-an-admin as a recovery problem, while the single most common failure in Kenyan SMEs — one login shared by a whole team — is covered in the shared login. None of these is a data protection feature as such. All of them are the reason a data protection question is answerable.
A reasonable first ninety days
-
Write down where personal data lives
Every system, spreadsheet, inbox and shared drive. This is uncomfortable and it is the only step that cannot be skipped, because every later obligation is scoped by this list.
-
Get a legal view on registration and whether you need a DPO
Thresholds and requirements are set by the Act and ODPC guidance and they are not a software question. Pay for this once, properly, and keep the written answer.
-
Set retention periods deliberately and turn enforcement on
Go through the categories, decide each period against your actual purposes, record the reasoning, and confirm the scheduled deletion is running. Defaults you never reviewed are not a decision.
-
Close the access question
Make MFA required rather than recommended, remove the shared logins, and review who can see payroll and staff records. Most exposure is here rather than in anything exotic.
-
Rehearse a subject access request and a breach
Pick a real employee, produce everything you hold about them, and time it. Then walk through a lost-laptop scenario and see who decides whether it is reportable. Both will be uncomfortable the first time, which is the point of doing it before it is real.
-
Reduce the number of copies
Every duplicate of the staff list is a separate obligation. Deleting the copies is unglamorous and it is the highest-value work on this list.
What AWRA OpsHub does today
- Per-user data export covering the personal data held across the system, queued and delivered by secure link, permission-restricted.
- Erasure that anonymises the person while preserving the audited actions, including rewriting their identity in the audit log, and audited as an event itself.
- Encrypted storage of bank details, mobile money numbers and statutory identity numbers.
- An audit log of actor, action, module, route, IP, user agent, session and affected record, with separate logging for document vault access and support impersonation.
- Configurable per-category retention with scheduled enforcement across roughly forty categories of log and operational data, with a dry-run preview, plus legal holds that can block the purge of a trashed record while a dispute is live.
- Organisation-wide MFA enforcement, IP restriction, device fingerprinting with lock and revoke, and session timeout.
- A security incident view grouping signals by category and severity, with a triage and resolution state.
- Scheduled account deletion with a thirty-day grace period before data is purged, so an accidental or contested deletion is recoverable.
- A published data processing addendum and compliance matrix rather than verbal assurances.
What it does not do
- No breach register and no notification workflow. No statutory clock, no template, no record of who was told and when. This is the most important gap on the page and it is a process you must build yourself.
- No DPIA tooling.
- No consent capture and no record of processing activities.
- No ODPC registration assistance — that is a legal and administrative task, not a product feature.
- We do not give legal advice on your obligations, and nothing here is legal advice.
Your obligations under the Data Protection Act 2019 are set by the Act and by ODPC guidance, and both change. Get your position — registration, lawful basis, retention periods, whether you need a data protection officer — in writing from a qualified adviser, and verify the current behaviour of any system with its provider before you rely on it. What is on this page is a description of software, not an opinion about your compliance.
Our take
Treat data protection as an operations problem with a legal deadline attached, rather than a legal problem with a software solution. The duties that matter most — registration, lawful basis, retention decisions, breach notification — are yours and stay yours. What a system can do is make the mechanical questions answerable: produce everything held about one person, erase them without destroying your records, delete what is past its period, and show who accessed what. Test those four before you need them. Then spend the rest of your effort reducing the number of places personal data lives, because that is where almost every failure actually originates.
See the access, audit and retention controls
Per-user export and erasure, an audit log that survives anonymisation, encrypted sensitive fields, configurable retention with scheduled enforcement, and organisation-wide MFA.
Explore security operationsFrequently asked questions
Does the Data Protection Act apply to a small Kenyan business?
If you hold personal data about people in Kenya — staff, customers, suppliers — the Act's principles apply to you regardless of size. What varies with size and the nature of your processing is whether you must register with the ODPC and whether you need a data protection officer, and those thresholds are set by the Act and ODPC guidance rather than by anything in your software. Get that specific question answered in writing by a qualified adviser and keep the answer.
Can buying the right software make us compliant?
No, and any vendor implying otherwise is describing something that cannot exist. Registration, lawful basis, privacy notices, retention decisions, DPO appointment and breach notification are organisational duties that no configuration screen discharges. What software can genuinely do is make the mechanical duties answerable — produce everything held about one person, erase them without destroying your business records, actually delete data past its retention period, and show who accessed what. That is a real and useful contribution, and it is not compliance.
What happens to our audit trail when we erase someone?
It has to survive, and this is the subtle part of erasure. Deleting an employee outright would also delete the approvals they gave and the stock movements they recorded, which are your business records and often legally required. So erasure replaces the personal identity — name, email, phone, photo, authentication secrets — and rewrites their name and email in the audit log, while the audited actions themselves remain. Ask any vendor to demonstrate exactly this, because an erasure that destroys your audit trail has simply swapped one compliance problem for another.
How long should we keep personal data?
Only as long as the purpose you collected it for requires, which is a decision about your business rather than a setting with a correct value. The product ships defaults across roughly forty categories — audit logs at 730 days, sessions at 30, notifications at 180 — and a scheduled job enforces whatever you set. But defaults you never reviewed are not a decision: go through the categories, choose each period against your actual purposes and any sector record-keeping rules, and write down the reasoning with a date on it.
Does the system handle breach notification to the ODPC?
No, and this is the largest gap on this page rather than a footnote. There is no breach register, no notification workflow and no tracking of the statutory clock. Security signals are surfaced by category and severity so you can investigate, but deciding whether an incident is reportable and notifying the ODPC and affected people within the timeframe the Act sets is a process you must own — with named people, a written playbook and at least one rehearsal before it is real.
Where is our data actually processed, and does that matter?
It matters, because transfers of personal data outside Kenya carry their own requirements under the Act. That makes hosting location and the identity of any sub-processors a question to answer in writing rather than in conversation — our positions are published in the data processing addendum and compliance matrix, and you should ask any provider for the equivalent document and send it to your adviser.
