In one paragraph.
The Data Protection Act, 2019 (Act No. 24 of 2019) gives effect to Article 31(c) and (d) of the Kenyan Constitution - the right not to have one's privacy infringed. It establishes the Office of the Data Protection Commissioner (ODPC) as the supervisory authority, defines the obligations of data controllers and processors, codifies the rights of data subjects, and sets the penalty ceiling at KES 5 million or 1% of annual turnover, whichever is lower.
The Act took effect on 25 November 2019. The operating detail lives in three regulations gazetted in 2021: the General Regulations, the Registration Regulations, and the Complaints Handling & Enforcement Regulations. If you only read one part of the statute, read Part IV - that's where the duties on you as a controller or processor sit.
If your organisation decides why and how personal data is processed, you are a controller. If you process data on someone else's instructions, you are a processor. Most enterprises are both - depending on the workflow.
Who must register with the ODPC.
Under the Registration Regulations, you must register if you have an annual turnover above KES 5 million or more than 10 employees. Below the threshold, you are still on the hook for the Act's substantive obligations - registration is just one of them, and the easiest one to evidence.
The threshold exemption disappears entirely for certain processing activities, regardless of your size: canvassing political opinions, processing children's data, health data, criminal records, biometric data, video surveillance in a public space, direct marketing, gambling, telecoms, financial services, and credit reference. If you do any of those, you register - full stop.
Registration runs for two years and must be renewed. The certificate is per-entity, not per-product. We've seen groups assume that one registration covers every subsidiary - it doesn't.
The six lawful bases - and the one most teams over-use.
Section 30 says you can only process personal data on one of six lawful bases. They are not interchangeable. Pick the wrong one and your defence collapses on the first day of an ODPC complaint.
The one teams over-use is consent. It feels safe - there's a checkbox, it's auditable - but consent must be revocable, and a workflow that breaks when the user revokes consent isn't built on consent. It's built on contract or legitimate interests. Naming the basis correctly upfront saves you the rebuild later.
Sensitive personal data.
Section 44 raises the bar for a defined set of categories: race, health status, ethnic origin, conscience, belief, genetic data, biometric data, property details, marital status, family details, sex, and sexual orientation. Processing these requires either explicit consent or one of the narrow Section 45 derogations.
Biometric data is where most modern platforms run into trouble - fingerprint logins, face match for onboarding, voice prints. The lawful basis isn't "we needed something stronger than a password". The lawful basis is explicit consent, or a clear statutory permission, and the data subject can still withdraw consent. Build the fall-back authentication path before you ship the biometric one.
Cross-border transfer and data localisation.
Sections 48 and 49 say you can transfer personal data out of Kenya only if you can demonstrate that the recipient jurisdiction provides an adequate level of protection, or you have put appropriate safeguards in place - typically a data processing agreement with model clauses, plus the standard technical controls.
Then there's localisation. Regulation 39 of the General Regulations introduces the concept of "data of strategic interest" - certain categories that may be required to be processed and stored within Kenya. The list has expanded over time and now reaches into financial services, telecoms, and government workloads. If you are running on AWS or Azure outside an in-country region, this is the regulation that will eventually find you.
Practical move: maintain a transfer register. Per system, list the data categories, the destination country, the safeguard you're relying on, and the contract reference. When the regulator asks - and increasingly they do - you produce one page, not a panicked spreadsheet exercise.
The records you'll be asked for.
Three documents do most of the work in a regulator interaction. Have them ready before you need them.
The 72-hour window.
Section 43 requires notification to the ODPC within 72 hours of becoming aware of a personal data breach where feasible, and to the affected data subjects in any case likely to result in real risk to them.
Seventy-two hours is short. By the time legal, security, and the executive sponsor have all weighed in, you may already be late. The teams that get this right have a pre-written breach runbook, a named decision-maker, and a holding-statement template signed off by counsel - not a meeting on day two about who calls the regulator.
What enforcement looks like in practice.
For its first two years the ODPC was largely in standing-up mode. From late 2023 onwards, the enforcement notices started to land. The published determinations have followed a clear pattern: unsolicited direct marketing, processing without a lawful basis, processing of children's data without parental consent, and refusal to honour a data subject's request.
The penalties have ranged from administrative fines in the high six figures through to the statutory ceiling. The faster route to a fine is not a sophisticated breach - it's a complaint from a data subject who didn't get a clear, timely response.
A workable response process - acknowledge in 7 days, substantive response in 30 - does more to reduce regulatory risk than any amount of perimeter security.
A 90-day action list.
Not the textbook list. The list that, in our experience, moves the needle for a mid-sized enterprise that has been "broadly compliant" but never formally tested.
- 01 Confirm ODPC registration status for every operating entity. Renewals can lapse silently. Check the cert.
- 02 Refresh your ROPA. If it lives in someone's drafts folder from 2022, it isn't a ROPA.
- 03 Map every cross-border data flow. One row per system. Destination, safeguard, contract reference.
- 04 Audit lawful bases. If "consent" appears against every processing line, it's wrong somewhere. Re-pick.
- 05 Stand up a breach runbook. Named decision-maker, holding statement pre-approved, ODPC notification template in the same folder as the incident bridge.
- 06 Test the data subject request path. Pretend you're a customer asking for your data back. Time how long it takes to land somewhere that can act on it. Fix the gap.
- 07 Review vendor DPAs. Especially the ones signed before 2021. Most will need a refresh against the current regulations.
- 08 Brief the board. One page. The penalty ceiling, the live exposures, the 90-day plan to close them. Annually thereafter.
- Data Protection Act, 2019 (Act No. 24 of 2019)
- Data Protection (General) Regulations, 2021
- Data Protection (Registration of Data Controllers and Data Processors) Regulations, 2021
- Data Protection (Complaints Handling and Enforcement Procedures) Regulations, 2021
- Office of the Data Protection Commissioner - published determinations and enforcement notices
This piece is a practitioner's read of the Act and its regulations as they apply to operating businesses. It is not legal advice. For a position specific to your organisation, work with counsel and your registered DPO.