Kenya's Data Protection Act Is an Engineering Spec: What Sections 25, 31, 41 and 43 Demand From Your Code

Karani GeoffreyJuly 12, 20269 min read

Every Kenyan developer has sat in the meeting where someone says "we need to be DPA compliant" and hands the problem to a lawyer. The lawyer produces a privacy policy, everyone relaxes, and nothing changes in the codebase. That is not compliance. That is decoration.

My thesis is simple: the Data Protection Act, No. 24 of 2019 is mostly an engineering specification wearing legal clothing. Read it as a developer and you find requirements about schemas, retention jobs, access logs, encryption, export endpoints, and incident timelines. Almost every obligation lands on someone who writes code. Here is what the Act actually says, section by section, and what you have to build.

First: do you even have to register?

Section 18 says no person shall act as a data controller or data processor unless registered with the Data Commissioner, and delegates the thresholds to the Commissioner. Those thresholds live in the Data Protection (Registration of Data Controllers and Data Processors) Regulations, 2021.

The practical rule: you are exempt from mandatory registration if your annual turnover is below KES 5 million and you have fewer than ten employees. The word "and" is doing heavy lifting - miss either condition and you are in. That exemption also does not apply if you operate in one of the listed sectors, which include financial services, health administration and patient care, education, telecommunications, transport including online hailing, hospitality, and security or crime prevention. A four-person health-tech startup in Kilimani is not exempt.

Registration goes through the ODPC portal, fees are tiered by size, and the certificate runs for 24 months with renewal expected before expiry. Check the current fee schedule on odpc.go.ke rather than trusting any blog, including this one, for the exact figure.

Exemption from registration is not exemption from the Act. Every obligation below applies whether or not you hold a certificate.

Section 25: the principles are a schema review

Section 25 requires that personal data be processed lawfully and transparently, collected for explicit and specified purposes, and be "adequate, relevant, limited to what is necessary." That last phrase is data minimisation, and it is a design decision made in a migration file.

Run this exercise on your own database this week. For every column holding personal data, answer three questions: what purpose does it serve, who reads it, and when does it get deleted. Columns that fail all three are liability with no upside.

-- Find the personal data you forgot you were collecting
SELECT table_name, column_name, data_type
FROM information_schema.columns
WHERE table_schema = 'erp_prod'
  AND (column_name REGEXP 'phone|mobile|msisdn|email|id_no|national_id|kra|dob|passport'
       OR column_name LIKE '%address%')
ORDER BY table_name;

Typical findings: national ID numbers copied into a free-text notes field, full M-Pesa callback payloads stored forever in a raw JSON log table, and CVs with dates of birth in an uploads folder from a 2021 hiring round. All three are section 25 problems.

Section 25(h) also states personal data shall not be transferred outside Kenya without adequate safeguards or the data subject's consent. Read that again if your production database sits on a VPS in Frankfurt or Virginia.

Section 26: rights are API endpoints

A data subject has the right to be informed, to access their data, to object to processing, and to correction or deletion of false or misleading data. In engineering terms you owe three capabilities, and you owe them within a reasonable time.

Export. Given a customer identifier, produce everything you hold about that person in a readable format. If your answer today is "I would write a bunch of ad hoc SQL," write it once now and save it as a script.
Correction. An authenticated path for the person or your staff to fix wrong data, with an audit trail of who changed what.
Objection and deletion. A flag your processing jobs actually respect. A marketing opt-out that your SMS blast ignores is worse than no opt-out, because it is now evidence.

# A subject access request should be one command, not an archaeology project
def export_subject_data(customer_id: str) -> dict:
    return {
        "profile": db.one("SELECT * FROM customers WHERE id = %s", customer_id),
        "orders": db.all("SELECT * FROM orders WHERE customer_id = %s", customer_id),
        "messages": db.all("SELECT * FROM sms_log WHERE customer_id = %s", customer_id),
        "consents": db.all("SELECT * FROM consents WHERE customer_id = %s", customer_id),
        "access_events": db.all(
            "SELECT actor, action, occurred_at FROM audit_log "
            "WHERE subject_id = %s ORDER BY occurred_at DESC", customer_id),
    }

Section 31: DPIA, and the sixty-day clock

Where a processing operation is likely to result in high risk to the rights and freedoms of a data subject, section 31 requires a data protection impact assessment before processing. It must describe the operations and purposes, assess necessity and proportionality, assess risks, and set out the measures and safeguards. Section 31(3) requires consulting the Data Commissioner if the assessment shows high risk, and section 31(5) says impact assessment reports shall be submitted sixty days prior to the processing of data.

That sixty-day figure surprises product teams. If you are launching credit scoring, biometric attendance, driver location tracking, or anything touching health data, the DPIA is not a document you write during the launch sprint. Put it in the roadmap two months early.

Sections 41 and 42: security by design, in writing

Section 41 requires "appropriate technical and organisational measures" designed to implement the principles and integrate safeguards, both when you choose how to process and while you process. Subsection 41(4) is unusually specific for a statute and reads like a control list:

identify reasonably foreseeable internal and external risks to personal data in your possession;
establish and maintain safeguards against those risks;
pseudonymisation and encryption of personal data;
ability to restore availability and access to personal data in a timely manner after a physical or technical incident;
verify that the safeguards are effectively implemented;
keep the safeguards continually updated.

Note item four. Your backup restore drill is a statutory expectation, not a nice-to-have. And item five means you need evidence of verification: a dated note that you ran the restore and it worked, that you scanned your ports, that you reviewed access.

Section 42 adds that where you use a data processor, you must choose one giving sufficient guarantees and enter a written contract requiring the processor to act only on your instructions. In practice that means your hosting provider, your SMS gateway, your accountant's bureau, and your offshore developer all need a data processing agreement. Section 42(3) is the sting: a processor who processes outside your instructions is deemed a controller for that processing, and carries controller liability.

Section 43: the 72-hour rule, and the encryption safe harbour

This is the section that will define your worst week. Where personal data has been accessed or acquired by an unauthorised person and there is a real risk of harm, the controller shall notify the Data Commissioner without delay and within 72 hours of becoming aware, and communicate to the affected data subject in writing within a reasonably practical period. Late notification must be accompanied by reasons for the delay.

Two details engineers should memorise:

Section 43(3): a data processor who becomes aware of a breach must notify the controller without delay and, where reasonably practicable, within 48 hours. If you build software for other companies, that clock is yours.
Section 43(6): communication to the data subject is not required where appropriate security safeguards, "which may include encryption of affected personal data," were implemented. Encryption at rest is not just good practice; it can be the difference between a quiet regulator filing and notifying forty thousand customers.

Section 43(5) tells you exactly what the notification must contain: the nature of the breach, measures taken or intended, recommendations for the data subject, the identity of the unauthorised person where applicable, and contact details for your DPO or other contact point. Build that as a template today.

Sections 48 to 50: where your server lives matters

Section 48 permits transfer of personal data out of Kenya where you have given the Data Commissioner proof of appropriate safeguards, or where the transfer is necessary for contract performance, public interest, legal claims, vital interests, or compelling legitimate interests. Section 49 goes further for sensitive personal data: transfer out of Kenya requires the data subject's consent and confirmation of appropriate safeguards. Section 50 lets the Cabinet Secretary prescribe categories of processing that must happen on a server or data centre located in Kenya.

So the honest answer for a Kenyan SME running health, financial, or biometric data on a European VPS is: you need a documented lawful basis, documented safeguards, and for sensitive data, consent. If you cannot produce that document, moving to a local or regional data centre is often the cheaper fix.

What it costs to get this wrong

Section 62 lets the Data Commissioner issue penalty notices, weighing the gravity of the failure, whether you were negligent, what you did to mitigate, your technical and organisational measures, your cooperation, and whether you self-reported. Section 63 caps the administrative fine at five million shillings or one per cent of the preceding financial year's annual turnover, whichever is lower. Section 65 gives data subjects a separate right to compensation for damage, which expressly includes distress, not just financial loss. Section 73's general penalty for offences reaches a fine up to three million shillings or up to ten years imprisonment, or both.

The ODPC is not theoretical about this. It has issued penalty notices to a digital lender, a school, a lounge, a phone brand and a serviced-office operator, ranging from a few hundred thousand shillings up to the five million ceiling, plus a growing pile of compensation orders. The common thread is not sophisticated hacking. It is processing without consent, ignoring opt-outs, and being unable to show what safeguards existed.

Your engineering to-do list

Run the schema query above and delete personal data columns nobody can justify.
Write and commit a retention job with per-table retention periods. Make it log what it deleted.
Add an audit_log table capturing actor, action, subject, and timestamp for every read and write of sensitive records.
Build the subject access export as a script, not a promise.
Turn on encryption at rest for database and backups. Section 43(6) is worth the afternoon.
Sign data processing agreements with every vendor that touches customer data.
Write the breach notification template using the section 43(5) fields, and pin the ODPC reporting page in your incident runbook.
Check the registration threshold against your turnover, headcount, and sector. If you are in, register.

Do those eight and you are ahead of most companies in the country, including large ones. Compliance stops being a document and becomes a property of the system, where it belonged all along.

Engineering guidance, not legal advice. For registration decisions and high-risk DPIAs, involve a Kenyan data protection advocate.

#Data Protection Act#ODPC#compliance#Kenya#data privacy#engineering