Kenya Data Protection Checklist for Websites and Mobile Apps

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:

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:

1. Receive the request.
2. Verify identity proportionately.
3. Locate information across production systems, vendors, exports, and archives.
4. Review lawful limitations.
5. Respond within the applicable period.
6. 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
• ODPC registration position reviewed

Official references

• Office of the Data Protection Commissioner: Data Protection Laws
• Kenya Data Protection Act, 2019 (official ODPC PDF)
• Data Protection (General) Regulations, 2021
• Data Protection (Registration of Data Controllers and Data Processors) Regulations, 2021

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.