A staff member emails a customer list to the wrong address. A laptop with client files is stolen from a car. Your vendor's cloud server has been hacked, and your client data is part of the leak. A former employee still has login access and continues to log in.
In that moment, Kenyan law starts a clock. And most businesses don't even know it's running.
Under Kenya's data protection framework, organisations that suffer a personal data breach may have just 72 hours to notify the regulator. This guide covers exactly what the law demands, how to respond, and how to be ready before it happens.
What Counts as a Personal Data Breach?
The definition is broader than most businesses assume. A breach is any incident resulting in the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.
That covers far more than hacking:
- Human error: emails and attachments sent to wrong recipients, misconfigured databases, files uploaded publicly
- Lost or stolen devices: laptops, phones, flash drives containing customer or employee data
- Insider misuse: unauthorised access by current or former employees
- Cyber incidents: ransomware, phishing, business email compromise, credential theft
- Vendor breaches: your processor or cloud provider is compromised, exposing your data.
Note the last category carefully: a breach at your vendor is still your breach as the data controller. Contracts must require processors to notify you immediately, and most don't until it's too late.
The 72-Hour Rule: Notify the ODPC
The Data Protection (General) Regulations require a data controller to notify the Office of the Data Protection Commissioner within 72 hours of becoming aware of a personal data breach where the breach is likely to result in a risk to the rights and freedoms of data subjects.
Key points in that sentence:
- The clock runs from the moment you become aware, not from when the breach occurred, which is why slow internal detection creates liability even before any notification.
- The trigger is likelihood of risk to individuals, not proven harm. If exposure could plausibly harm the people affected, notify
- "Aware" means the organisation, not just one junior employee, has knowledge; another reason breach reporting must be mandatory and protected internally.
Notifying the Data Subjects
Where the breach is likely to result in a high risk to the affected individuals' identity numbers, financial data, health records, children's data, or credentials, you must also communicate the breach to the affected data subjects without undue delay.
That communication should describe, in plain language:
- The nature of the breach and the categories of data affected.
- The likely consequences for the individuals
- The measures taken or proposed what you've done, what they should do (change passwords, watch accounts)
- Contact details for more information
Trying to bury a breach to protect reputation is almost always the worst strategy: discovery later multiplies regulatory penalties, destroys the trust you tried to protect, and reads as consciousness of fault.
Your Practical Breach Response Plan
Organisations that handle breaches well follow a disciplined sequence:
1. Contain
Isolate affected systems, deactivate compromised accounts, recover lost devices, block the exfiltration path. Speed here limits the notification obligation and the harm.
2. Assess
- What data was affected, and whose?
- How many data subjects?
- How sensitive is the data?
- What is the realistic risk of harm?
This assessment drives whether and how you notify. Document your reasoning — regulators ask for it.
3. Document
Record everything: the incident, the timeline, the decisions, the notifications. A breach register is itself a compliance requirement, and thorough records are your best defence when the ODPC calls.
4. Notify
- File the ODPC notification within 72 hours where the risk threshold is met.
- Communicate to affected data subjects where the high-risk threshold is met.
- Involve your advocates early; notification wording is legally significant.
5. Remediate and Support
Fix the vulnerability, support affected individuals (credit monitoring for financial breaches, password resets for credential leaks), and answer their questions honestly.
6. Review
Conduct a post-incident review. Every breach is data about your weaknesses; treat it that way.
The Penalties — and the Personal Exposure
The Data Protection Act provides for administrative fines of up to KSh 5 million or 1% of annual turnover, whichever is lower, per infringement. Beyond fines:
- Officer liability: company officers who consent to or connive in an offence, or whose negligence enables it, can bear personal criminal liability; directors can no longer assume compliance is "an IT issue"
- Compensation claims: data subjects who suffer damage can sue for compensation
- Reputational and commercial damage: corporate clients and banks increasingly audit vendors' breach histories; a mishandled breach costs contracts long after the fine is paid
Prevention: The Breach You Never Have to Report
- Access controls: least-privilege access, strong authentication, prompt offboarding of departed staff (the ex-employee login is a classic)
- Encryption of devices, databases, and backups; a lost encrypted laptop is often not a notifiable breach at all.
- Vendor contracts: processors contractually bound to immediate breach notification and adequate security.
- Staff training: most breaches start with a person, not a machine: phishing awareness, verification of payment instructions, careful handling of attachments.
- Testing tabletop breach exercises so the 72-hour clock never finds you improvising
Frequently Asked Questions
Q1. Do I have to report every breach?
A. Not every incident requires notification; only those likely to result in risk to data subjects (ODPC) or high risk (data subjects). But every breach must be assessed and documented.
Q2. What if I don't know exactly what was taken within 72 hours?
A. Notify with what you know, and update as the picture clarifies. The law expects timely notification, not perfection.
Q3. What if the breach was our vendor's fault?
A. As controller, the notification obligation is yours. Your recourse against the vendor is contractual, which is why processor contracts matter so much.
Q4. Can individuals sue us after a breach?
A. Yes, the Act provides for compensation where damage results from a breach of its provisions.
Q5. What should we do first: contain or notify?
A. Contain first, but start the clock assessment immediately. Both matter; neither excuses delay in the other.
The Bottom Line
Seventy-two hours is not much time when you're discovering an incident for the first time. Organisations with a written breach response plan who know who decides, who notifies, and who calls the lawyers survive breaches with their reputations intact. Those without one improvise, usually badly, at regulator speed.
Need a breach response plan, help with an active incident, or ODPC notification support? Contact Anyega Osiemo & Co. Advocates before the clock starts.
Disclaimer: This article is general legal information, not legal advice. For guidance on your specific situation, book a consultation with our advocates.
