Kenya Data Protection Checklist for Websites and Mobile Apps
A practical checklist for Kenyan businesses collecting customer data through websites, mobile apps, e-commerce stores, booking systems, and digital platforms.
Orwan Consulting15 June 202610 min read
Businesses collect personal data every day through contact forms, account registrations, e-commerce checkouts, mobile apps, analytics tools, loyalty programmes, support chats, and payment integrations.
In Kenya, this information is governed by the Data Protection Act, 2019 and its supporting regulations. Compliance is not simply a privacy-policy exercise. It affects how a digital product is designed, what information it requests, who can access that information, how long it is retained, and how incidents are handled.
Important: This article provides practical technical and operational guidance. It is not legal advice. Organisations handling sensitive, high-risk, or large-scale personal data should obtain advice suited to their circumstances.
1. Identify every type of personal data you collect
Start with a data inventory. Review every form, database field, tracking script, integration, spreadsheet, and support process.
Common examples include:
Names, telephone numbers, email addresses, and physical addresses
National ID, passport, tax, employee, or customer identification numbers
Login credentials, device identifiers, IP addresses, and location information
Payment references, order histories, loyalty records, and customer preferences
Photographs, recordings, biometric information, and health information
Support conversations and free-text form submissions
Document where each item comes from, why it is needed, where it is stored, who can access it, who receives it, and when it should be deleted.
The Act requires personal data to be collected for explicit and legitimate purposes, limited to what is necessary, kept accurate, and retained no longer than necessary.
Checklist
We maintain an inventory of personal data collected by the website or app.
Every data field has a documented business purpose.
Optional fields are clearly distinguished from required fields.
We do not collect information merely because it may be useful later.
2. Choose and document a lawful basis
Consent is one lawful basis, but it is not the only possible basis. Processing may also be necessary for a contract, a legal obligation, vital interests, public interest, or another lawful ground provided by the Act.
Do not use consent automatically where the information is genuinely required to perform a contract. Equally, do not hide optional marketing consent inside acceptance of general terms.
Create a processing register that maps each activity to its purpose and lawful basis. Examples:
Activity
Typical purpose
Question to document
Contact form
Respond to an enquiry
Which fields are necessary to reply?
Checkout
Process and deliver an order
Which records must be retained for tax or accounting?
Newsletter
Send marketing messages
How was permission obtained and how can it be withdrawn?
Analytics
Measure website performance
Is personal data collected, and can collection be reduced?
Customer account
Provide an ongoing service
What happens when the account is closed?
3. Make consent specific, informed, and provable
Where consent is used, it should be a clear affirmative choice. The Act places the burden of proving consent on the controller or processor and gives the individual the right to withdraw it.
Good consent design means:
No pre-ticked marketing boxes
Separate choices for separate purposes
Plain language close to the point of collection
A record of what the user agreed to, when, and through which version of the notice
A withdrawal method that is as easy as giving consent
Fresh consent where information will be used for a materially different purpose
For email, SMS, WhatsApp, or other direct marketing, provide a clear opt-out method in every campaign and process opt-outs promptly.
Checklist
Marketing consent is separate from service terms.
Consent records include date, source, purpose, and notice version.
Users can unsubscribe or withdraw consent easily.
Withdrawing marketing consent does not block an unrelated paid service.
4. Show a clear privacy notice before collecting data
Section 29 of the Act requires organisations, as far as practicable, to inform people before collecting their personal data.
A useful privacy notice should explain:
The organisation collecting the information and how to contact it
What information is collected
Why it is collected and the relevant lawful basis
Whether providing it is mandatory or voluntary
Who receives it, including important categories of service providers
Whether it may be transferred outside Kenya and the safeguards used
How long it is retained or how the retention period is determined
The individual's rights and how to exercise them
How to complain to the organisation or the Office of the Data Protection Commissioner
The security approach in terms that are useful without exposing defensive details
Place short, contextual notices next to high-impact forms and link them to the full privacy policy. A footer link alone may not provide enough context at the moment of collection.
5. Collect the minimum information required
Data minimisation reduces compliance risk, development complexity, storage cost, and the impact of a breach.
Review each form:
Does a quotation form really need a national ID number?
Does a newsletter form need a date of birth?
Does a delivery app need continuous location access when it is not in use?
Can analytics operate with shorter retention or reduced identifiers?
Can support teams solve the issue without requesting screenshots containing unrelated information?
Default settings should favour privacy. Optional profile fields should remain optional, location permissions should be scoped to the feature, and public profiles should not expose information automatically.
6. Build access controls around job responsibilities
Not every employee, contractor, or administrator should see every customer record.
Implement:
Unique user accounts rather than shared administrator passwords
Role-based access control
Multi-factor authentication for administrative and vendor accounts
Strong session management and automatic expiry
Approval for high-risk exports, deletions, or permission changes
Audit logs for access to sensitive records and important administrative actions
A documented joiner, mover, and leaver process
Regular access reviews
Production data should not be copied into development or testing environments unless it is genuinely necessary and appropriately protected. Prefer realistic synthetic data.
7. Protect data in storage and transit
Security measures should match the sensitivity, scale, and risk of the processing.
For websites and mobile apps, the baseline normally includes:
HTTPS for all public and administrative traffic
Encryption for sensitive data at rest where appropriate
Secure password hashing
Secret and API-key management outside source code
Input validation and protection against common web vulnerabilities
Dependency and operating-system updates
Rate limiting and abuse monitoring
Secure file-upload rules
Logging that avoids passwords, tokens, payment data, and unnecessary personal information
Routine vulnerability testing and incident drills
The Act specifically points to measures such as identifying risks, maintaining safeguards, encryption or pseudonymisation, testing controls, and restoring availability after an incident.
8. Make backups secure and restorable
A backup is still personal data. It needs access controls, retention limits, encryption, and deletion procedures.
Use the 3-2-1 principle as a practical starting point: keep multiple copies, use more than one storage type, and maintain at least one appropriately isolated copy.
More importantly, test restoration. A backup strategy that has never been restored is an assumption, not a recovery capability.
Checklist
Backups are encrypted and access is restricted.
Backup retention matches documented business and legal needs.
Restore tests are performed and recorded.
Recovery objectives are defined for critical systems.
Deleted customer data is handled appropriately in backup lifecycle procedures.
9. Control vendors and third-party integrations
Cloud hosting, analytics, email delivery, customer support, payment services, crash reporting, advertising pixels, and push notifications may all process customer data.
Maintain a vendor register containing:
Service and business purpose
Data categories shared
Storage and processing locations
Security and privacy review date
Contract owner
Sub-processors
Retention and deletion arrangements
Incident-notification commitments
Kenyan law requires a controller using a processor to select a provider that gives sufficient guarantees and to enter into a written contract requiring the processor to act on documented instructions and meet relevant obligations.
Do not add a tracking pixel or software development kit only because it is convenient. Review what it collects, whether the purpose is necessary, and whether users have been informed.
10. Set retention periods and deletion rules
Keeping everything forever creates risk without creating reliable business value.
The General Regulations require controllers and processors to establish retention schedules with time limits, periodic review, and actions such as deletion, anonymisation, or pseudonymisation when the purpose has ended.
Create retention rules for:
Unsuccessful enquiries
Customer accounts
Orders, invoices, and accounting records
Marketing lists and opt-out records
Support tickets
Application logs
Uploaded documents
Backups
Former employee and contractor accounts
Retention periods should reflect legal obligations and genuine operational needs rather than a generic number copied from another privacy policy.
11. Provide a process for data-subject requests
Individuals have rights concerning their personal data, including access, objection, correction, deletion in applicable circumstances, restriction, and portability.
Publish a contact channel and create an internal workflow to:
Receive the request.
Verify identity proportionately.
Locate information across production systems, vendors, exports, and archives.
Review lawful limitations.
Respond within the applicable period.
Record the outcome.
Staff who receive customer communications should know how to recognise a privacy request and route it correctly.
12. Assess high-risk features before launch
A data protection impact assessment may be required where processing is likely to create a high risk to people's rights and freedoms.
Trigger a privacy review when introducing features such as:
Biometrics or facial recognition
Health or financial profiling
Large-scale location tracking
Children's services
Automated decisions with significant effects
Large-scale sensitive-data processing
New data sharing or international transfer arrangements
AI systems trained on or making decisions about customer information
Privacy review should happen during product design, not after launch. The Act requires data protection by design and by default.
13. Prepare a breach response plan
A personal-data breach may involve loss, destruction, alteration, unauthorised disclosure, or unauthorised access.
Your response plan should define:
Who receives and triages alerts
How systems and evidence are preserved
How affected data and people are identified
Who assesses the risk of harm
Who communicates with customers, vendors, insurers, and regulators
How corrective actions are tracked
Where unauthorised access creates a real risk of harm, the Act requires the controller to notify the Data Commissioner without delay and within 72 hours of becoming aware of the breach. Affected individuals may also need to be informed within a reasonably practical period.
14. Check whether ODPC registration is required
Registration requirements depend on factors including organisational size and the type of processing performed.
The Registration Regulations provide an exemption test for some organisations below both specified revenue and employee thresholds, but the exemption does not remove the obligation to comply with the substantive data-protection requirements. It also does not apply to certain categories of processing listed in the Regulations.
Do not assume that being a small company automatically removes registration requirements. Review your activities against the current ODPC rules.
Final launch checklist
Before launching or materially updating a website or mobile app, confirm:
Personal-data inventory completed
Purpose and lawful basis documented
Unnecessary fields removed
Privacy notices shown at collection points
Consent and withdrawal mechanisms tested
User rights workflow documented
Role-based access and MFA enabled
Encryption, logging, patching, and monitoring reviewed
Backup restoration tested
Vendor register and processor contracts reviewed
Retention and deletion schedule approved
High-risk features assessed
Incident response and 72-hour escalation procedure tested
Orwan Consulting designs websites, mobile apps, e-commerce platforms, POS systems, and business software with privacy and security requirements considered from the planning stage. Talk to our team about your project.
