Kenya's Data Protection Act, Retention & Deletion: A Practical Reading
Kenya's Data Protection Act put obligations on ordinary businesses that most of them have never mapped to the systems they actually run. A practical reading for operations teams — what personal data you are holding without thinking about it, what retention really means in software, and where the honest boundary of any product sits. Not legal advice.
Most Kenyan businesses read the Data Protection Act as something for banks, hospitals and technology companies. Then somebody lists what is actually held in their systems — employee national ID numbers, staff bank details, next-of-kin contacts, customer phone numbers, delivery addresses, photographs on attendance records, GPS coordinates on asset checkouts — and the conversation changes.
You do not need to be a data business to be a data controller. You need to be an employer with payroll, or a retailer with customer records. That is nearly everyone.
What this article is and is not
This is an operational reading written to help you ask the right questions of your systems and your adviser. It is not legal advice, it states no thresholds, deadlines or penalty figures, and obligations change. Confirm your specific position with the Office of the Data Protection Commissioner and a qualified adviser.
Start with an inventory, not a policy
The instinct is to write a privacy policy. The useful first step is duller and far more revealing: list what personal data your operations actually hold, where it sits, and why you have it. Most organizations are surprised twice — once by how much there is, and once by how much of it nobody can justify.
| Where it hides | What is in there | The question worth asking |
|---|---|---|
| Employee records | National ID and statutory numbers, bank details, contracts, next of kin | Who, exactly, can open these — and is that list smaller than "HR and anyone with HR access"? |
| Payroll | Salaries, deductions, payslips going back years | Are old payslips kept because you need them, or because nothing ever deletes? |
| Attendance | Times, sites, verification evidence, sometimes photographs and location | Was the location capture a decision, or a default that was left on? |
| Customer records | Names, phone numbers, addresses, purchase history | Do you still need the contact details of someone who bought once in 2021? |
| Support tickets | Whatever a customer typed, which is frequently more than you asked for | Are these read by more people than the customer would expect? |
| Documents | Scanned IDs, certificates, signed contracts in the vault | Is there an access log, and has anyone ever looked at it? |
| Backups and exports | A spreadsheet of everything, sitting in somebody's email | This is usually the real exposure, and it is never in the inventory. |
The largest personal-data risk in most Kenyan SMEs is not the system. It is the export of the system that somebody emailed to themselves in 2023 and still has.
Four principles that translate into system settings
The Act is broader than this, but four of its principles map directly onto things you can act on inside an operations system this week — which makes them the practical place to start.
-
Collect only what you need
Every optional field you add is data you must then protect, justify and eventually dispose of. Custom fields make it very easy to collect more than you need; the discipline is to ask what decision each field supports before adding it.
-
Limit who can see it
Access control is a data-protection measure, not just a security one. Sensitive fields and sensitive exports being separate permissions is the mechanism; whether you use it is your decision. See roles and permissions.
-
Keep it only as long as you need it
This is the one nearly everyone fails, because keeping things forever requires no action. Retention has to be chosen, configured and then actually run.
-
Be able to show what happened to it
Who accessed a document, when access was granted, when data was exported. Accountability is a principle in its own right, and an audit trail is the evidence of it — see the audit trail.
What "retention" actually means in a system
Here is where the honest detail matters, because "we support data retention policies" is a sentence that hides a great deal. Retention automation in most operational systems — ours included — is aimed at operational and log data, not at your business records.
The four kinds of data, and how each one is actually disposed of
Logs and telemetry
Activity logs, audit logs, email logs, sessions, notifications, scan events, report runs and exports. Each has a retention period in days and an action, runs on a schedule, and can be previewed before it deletes anything. Defaults are sensible rather than aggressive — audit logs are kept substantially longer than session records, for example.
Business records you delete
Records you remove go to trash, with lifecycle events, purge reporting and legal holds that can stop a specific record or scope from being purged while a dispute or investigation is live. Disposal is a workflow you drive, not a timer.
Business records you keep
Customers, employees, invoices, tickets. There is no rule that quietly deletes a customer who has been inactive for five years. Deciding that inactive customer contact details should go is a policy decision you make and then execute.
Everything outside the system
Exports on laptops, spreadsheets in email, WhatsApp groups where staff share client numbers, the photocopy of an ID in a drawer. No software controls any of this, and it is where most real exposure lives.
Read the third row twice. Many organizations assume a retention setting somewhere is quietly ageing out old personal data. It is not — it is ageing out logs.
Data-subject requests: the part that is a process, not a button
When someone asks what you hold about them, or asks you to delete it, the answer has to come out of a business process. Software can help with parts of it, and it is worth being precise about which parts.
For user accounts — the people who log in to your system — there is a data export and an erasure path, each recorded as an administrative action. For everybody else whose data you hold — customers, employees, suppliers, ticket submitters — assembling a response means going module by module, and deleting means judging what you are legally required to keep against what the request asks you to remove. An invoice to a customer is not simply erasable; a marketing contact usually is.
- Decide in advance who owns the response, because the clock starts when the request arrives, not when it reaches the right desk.
- Write down which modules hold personal data, so assembling a response is a checklist rather than an investigation each time.
- Distinguish between records you are obliged to retain and records you merely have. That distinction is the substance of most responses.
- Log what you did, including what you refused and why. The reasoning is as important as the action.
- Take advice before erasing anything with financial or statutory significance. Retention obligations and erasure requests genuinely conflict, and that conflict has a legally correct answer that is not "delete it".
Where the data physically lives
Residency comes up in nearly every serious procurement conversation, and it deserves a direct answer rather than reassurance. Ask any vendor where the database sits, where backups sit, which sub-processors touch the data, and what happens to all of it if you leave. Those are four separate questions and vendors routinely answer the first while implying the others.
Our answer: the sub-processors we use are published, an organization can request deletion of its data, and deletion requests are handled as a tracked lifecycle with an impact preview rather than an irreversible click. If your sector, your donor or your board imposes a specific residency requirement, raise it during evaluation — it is an infrastructure question with a real answer, not a feature to be discovered later.
The exit half of that — no-cost export at termination, how long a provider keeps your data afterwards, and who remains liable for it in the meantime — is worked through in exit terms, export and who stays liable. And if what you actually need to settle is which of these duties are yours rather than your provider's, that boundary is the subject of controller or processor?.
What we do and do not do
What AWRA OpsHub does today
- Configurable retention policies per data type, with a period in days, an action, an active flag and a scheduled run — covering activity and audit logs, email and notification logs, sessions, scan data, report runs and exports.
- A dry-run preview, so you can see what a policy would remove before it removes anything.
- Trash with lifecycle events, purge reporting and legal holds that can freeze a record or scope while a dispute is live.
- Per-user data export and erasure for account holders, recorded as administrative actions.
- Access logging on document vault files, separate from record-level audit logging.
- Permission-gated sensitive fields and sensitive report exports, plus organization-level deletion requests with an impact preview.
What it does not do
- No automatic ageing-out of business records. Customers, employees, invoices and tickets are kept until you decide otherwise. Retention automation covers logs and operational data.
- No consent management. There is no register of who consented to what, when, or for which purpose — if consent tracking matters in your context, that is a process and possibly another tool.
- No one-click data-subject response for non-users. Assembling and fulfilling a request about a customer or employee is a manual, module-by-module process.
- Not a compliance certification. Configuring these settings does not make an organization compliant with the Act — compliance is a legal assessment of your whole operation, and a system is one input to it.
The last line is the one to take to your board. A vendor that tells you their product makes you compliant with the Data Protection Act is describing something no software can deliver.
Our take
Spend an afternoon listing where personal data actually sits in your operation — including the exports outside the system — then set retention periods deliberately, tighten who can see sensitive fields, and name one person who owns data-subject requests. That is a real week of progress. Treat the legal assessment as a separate exercise with a qualified adviser, and confirm anything specific with the Office of the Data Protection Commissioner.
See compliance evidence packs
Retention policies with dry-run previews, legal holds on trashed records, document access logs and audit evidence you can hand to a reviewer.
Explore compliance evidenceFrequently asked questions
Does our small business really fall under the Data Protection Act?
If you employ people you hold identity numbers, bank details and next-of-kin contacts; if you sell to named customers you hold contact details. Both are personal data, and the obligations attach to what you hold rather than to your size or sector. What varies with size and sector is what a proportionate response looks like — which is exactly the question to put to a qualified adviser, along with anything specific to registration or notification, which we deliberately do not state here.
Does configuring retention policies make us compliant?
No. Retention settings address one principle — not keeping data longer than you need it — and only for the data types they cover, which in practice means logs and operational records rather than your customer and employee master data. Compliance is a legal assessment of your whole operation: what you collect, why, who you share it with, how you secure it, and how you respond to requests. A well-configured system is evidence in that assessment, not the answer to it.
A customer has asked us to delete everything we hold about them. Can we?
Partly, and the judgement matters more than the mechanics. Marketing contact details are usually straightforward. Transaction records with financial and tax significance are usually subject to retention obligations that sit alongside the erasure request — and those obligations do not disappear because a request was made. Assemble what you hold module by module, separate what you must keep from what you merely have, act on the second category, and document your reasoning for the first. Take advice before deleting anything with statutory significance.
Which retention periods should we choose?
Start from why you would ever need the data again, not from a round number. Audit and security logs justify a long period because investigations and disputes reach back years — the defaults reflect that. Session records, scan events and job logs justify weeks. The mistake is applying one number across everything, which either deletes evidence you needed or keeps telemetry nobody will ever open. Use the dry-run preview before activating a policy, and revisit the periods when your auditor or your obligations change.
What is the single highest-risk place personal data sits in most businesses?
The exports. A spreadsheet of the full customer list, or a payroll report, emailed to a personal address and then living on a laptop, a phone and a mail server indefinitely — outside every permission, every log and every retention policy you configured. That is why export permissions are worth restricting, why sensitive exports are a separate grant, and why reviewing who exported what should be one of your standing monthly audit-log questions.
