Kenya Data Protection Act: Rules for Processing Biometric Data

Deleting a selfie does not prove that a biometric identity system has forgotten the person. A cropped face, an embedding, a liveness video, a comparison score, a device log and a manual-review screenshot can each sit in a different system or with a different processor. Under Kenya's data-protection rules, the question to ask is whether your organisation can trace every biometric-derived object from collection to deletion and justify why each one exists. “Do we store photos?” covers only a small part of that.

Kenya's Data Protection Act defines biometric data as personal data resulting from specific technical processing based on physical, physiological or behavioural characterisation, including examples such as fingerprints, DNA analysis, retinal scanning and voice recognition. It expressly includes biometric data within sensitive personal data. The Office of the Data Protection Commissioner also publishes dedicated guidance on biometric data, DPIAs, consent and cross-border transfers. To comply, you have to apply these rules to the actual data path. A paragraph in the privacy policy does not do it.

In brief

• Classify raw captures, biometric templates and derived results separately, because each carries its own risks and purposes.

• Establish both the general lawful basis and the additional condition required for sensitive personal data.

• Complete a DPIA before high-risk biometric processing, while design choices can still change.

• Make the controller able to prove processor instructions, transfer safeguards, retention and deletion across every copy.

Start with data lineage, not a vendor questionnaire

capture
→ quality and liveness artefacts
→ face template or embedding
→ comparison and threshold result
→ business decision
→ logs, review material and backups
→ deletion or defensible retention

For each object, record the purpose, controller, processor, storage location, access roles, recipient, retention trigger and deletion method. “Biometric data: 30 days” fails as a schedule if the model input disappears while the template, case screenshot and backup stay behind. Reporting institutions also have to reconcile this object-level schedule with the POCAMLA Regulations, which require specified customer-identification and transaction records to be retained for at least seven years. That rule does not mean every raw biometric artefact must be kept. Map which evidence belongs to the mandatory record and delete the biometric copies that fall outside it.

Biometric processing needs two legal answers

You need a lawful basis for processing personal data, and on top of that a condition that permits processing sensitive personal data. Consent can be relevant in some flows. Labelling a checkbox “explicit” does not fix a relationship where the person has no real choice. If you rely on another legal condition, document it and its scope; do not collect token consent as a fallback.

Purpose limitation has practical consequences too. A face captured to bind a customer to an ID document should not quietly turn into training data, a marketing profile or a general watchlist entry, and any new use needs its own compatibility and legal assessment. A separate rule applies when sensitive biometric data are transferred outside Kenya: the Data Protection Act requires the data subject's consent and confirmation of appropriate safeguards. Having a domestic processing basis does not remove that transfer condition.

When a DPIA changes the product

Section 31 of the Data Protection Act requires a data-protection impact assessment where processing is likely to result in high risk to a data subject's rights and freedoms, and requires the report to be submitted to the Data Commissioner sixty days before processing. The Act frames the assessment around the nature, scope, context and purposes of the processing. The more specific examples (biometric identification at scale, systematic monitoring, automated denial of access, combinations of sensitive datasets) come from the ODPC's operational guidance; the statute itself does not list them.

A DPIA is only worth doing if it changes controls. It should describe:

• the decision affected and harm if the system is wrong;

• necessity and proportionality of biometrics versus less intrusive means;

• false-match, false-non-match and presentation-attack risks;

• children, people with disabilities and groups exposed to unequal error rates;

• injection, template compromise and insider misuse;

• processor, subprocessor and cross-border dependencies;

• human-review and contest routes;

• residual risk, approval owner and re-assessment triggers.

If you run the DPIA after the SDK and contracts are fixed, it becomes paperwork. Run it before procurement and revisit it whenever the model, purpose, dataset, hosting country or decision consequence changes.

Controller and processor boundaries must be testable

A cloud biometric vendor may process images, create templates, return scores and keep technical logs, while the customer decides purpose, threshold and consequence. What each party actually controls matters more than the labels in the contract.

Biometric.Vision Security describes encryption, access auditing and cloud or on-premise deployment. These controls help with compliance. They do not choose the customer's lawful basis, retention period or threshold, and neither does a certificate or a deployment option.

Cross-border transfer is a data-flow question

Teams often ask where the primary database sits and leave it there. Data can also leave through support access, telemetry, content-delivery logs, model troubleshooting or a subprocessor. Map remote access and onward transfers, then apply the Kenyan transfer requirements and ODPC guidance to each route.

Hosting locally can reduce exposure. It does not by itself make processing lawful. And an authorised transfer gives you no reason to collect biometric features you do not need.

Retention should follow events, not convenience

Use separate clocks for separate objects:

• failed or abandoned captures;

• successful onboarding evidence;

• biometric templates used for later authentication;

• fraud-investigation holds;

• model-quality samples, if separately lawful;

• security and transaction logs;

• backups and disaster-recovery copies.

The trigger can be session closure, account termination, the end of a dispute or the expiry of a legal record-keeping duty. Give each exception an owner and a release condition. Check that deletion works across the primary system, review tools, object storage and the processor's environment.

An expert pre-launch review

• Can the team enumerate every biometric-derived object, not only raw images?

• Is each object necessary for a named purpose and tied to the correct legal condition?

• Did the DPIA change at least one design or control where risk required it?

• Are accuracy and PAD claims bounded by thresholds, populations and tested attack types?

• Can a person obtain meaningful information, challenge an adverse outcome and use an accessible alternative?

• Can the controller prove processor deletion and identify every transfer route?

Under Kenya's Data Protection Act, what you are accountable for is the chain from purpose to capture, decision, review and deletion. Having an AI model that produces a match is only one link in it. Before launch, walk one test customer through that chain and confirm each step leaves a record you could show the ODPC.