Valid Consent Under the Kenya DPA 2019: What Section 32 Requires

Consent is the most visible lawful basis for processing personal data - and the most commonly misapplied. Organisations routinely claim consent as their legal basis when the conditions for valid consent are not met. The result is processing that appears compliant but is, in law, unlawful.

Section 32 of the Kenya Data Protection Act 2019 sets out the conditions that make consent valid. This guide explains each condition, what they mean in practice, and when consent is not the right legal basis to use.

A Common Point of Confusion

Before getting into section 32, a point that causes persistent confusion: consent conditions are in section 32, not section 30.

Section 30 covers lawful processing generally - it lists the legal bases (consent, contract, legal obligation, vital interests, public interest, legitimate interests). Section 30 establishes that consent is a valid basis, but it does not set the conditions for valid consent.

Section 32 is where the conditions for consent are actually defined. When assessing whether you have valid consent, section 32 is the provision to apply.

The Conditions for Valid Consent

Section 32(1) places the burden of proof on the data controller: where processing is based on consent, you must be able to prove that the data subject consented - and that the consent was express, unequivocal, free, specific, and informed. In practice these statutory conditions group into four tests.

Freely given. Consent is only valid if the data subject had a genuine choice. An individual who faces a disadvantage for refusing consent - or who has no real alternative - has not freely given their consent.

This rules out:

• Bundled consent - conditioning a service or contract on consent to unrelated processing. Section 32(4) makes this explicit: consent is not freely given where performance of a contract is made conditional on consent to processing that is not necessary for that contract. "By signing up, you agree to receive marketing emails" is not valid consent for marketing if the service is not genuinely dependent on it.
• Power imbalance - employer-employee consent is inherently suspect. Where refusal to consent could affect employment, the consent is unlikely to be freely given. Employers should identify a different legal basis for most employee data processing.
• Penalty for refusal - if declining consent results in a reduced service, degraded experience, or any other negative consequence, the consent is not freely given.

The test for freely given consent is simple: Could the individual have said no, without meaningful consequence? If the answer is no, the consent is not freely given.

Specific. Consent must be given for a specific purpose - not a blanket authorisation for all possible uses of personal data. Separate consent is required for each distinct purpose. Consent for a newsletter does not extend to profiling, third-party sharing, or research. The purpose must be described with enough specificity that a data subject understands what they are consenting to - "we may use your data for business purposes" is not specific enough. Where you add a new processing purpose after consent has been obtained, you need fresh consent for the new purpose.

Informed. For consent to be informed, the data subject must understand what they are agreeing to before they agree. At the point of consent, you must communicate:

• The identity of the data controller
• The purpose or purposes of the processing
• The types of personal data that will be collected
• Any sharing with third parties
• The right to withdraw consent, and how to do so
• Any automated decision-making or profiling involved

Plain language is a legal requirement, not a stylistic preference. Consent language buried in a privacy policy that uses legal terminology is unlikely to produce informed consent.

Express and unequivocal. Consent must be indicated by a clear affirmative act - a statement, a tick box, or a physical action that unambiguously signals agreement.

This rules out:

• Pre-ticked boxes - a box that is ticked by default, which the data subject must un-tick to refuse, is not consent. Inaction is not consent.
• Inferred consent - proceeding with processing on the basis that the individual did not object is not consent. The individual must actively signal agreement.
• "By continuing to use this website, you consent..." - passive use of a service is not an unambiguous act of consent for specific processing purposes.

Recording and Managing Consent

Because section 32(1) places the burden of proof on the controller, a consent request buried in general terms and conditions - without separation or prominence - leaves you unable to prove that consent was express and informed. Keep the consent ask clearly separated from other terms.

Valid consent records must show:

• Who consented (name or identifier)
• What they consented to (the specific purpose)
• When they consented (date and time)
• How they consented (the mechanism - e.g., form submission, checkbox, verbal confirmation)
• What information was presented to them at the time of consent

Without these records, you cannot demonstrate that valid consent was obtained. In a data subject access request, an ODPC audit, or a complaint investigation, an assertion that consent was obtained is not evidence of it.

Withdrawing Consent

Section 32(2) provides that a data subject may withdraw consent at any time. Withdrawal must be as easy as giving consent. If consent was given via a single checkbox, withdrawal should be achievable via a similarly simple mechanism - not buried in a settings menu, not requiring a written letter, not dependent on speaking to a customer service agent.

On withdrawal, the controller must stop the processing for which consent was the legal basis. Under section 32(3), withdrawal does not affect the lawfulness of processing that occurred before withdrawal - but you must stop processing going forward, and delete the data if no other legal basis applies.

Important: Withdrawal of consent triggers an erasure obligation unless another legal basis justifies continued retention. Map your consent-based processing carefully so you know exactly what must stop and what, if anything, may continue under a different basis.

Consent and Children - Section 33

Section 33 addresses processing of personal data relating to children. Where processing is based on consent and the data subject is a minor (under 18 under general Kenyan law), consent must be given or authorised by a parent or guardian.

Organisations processing data of children - schools, health services, digital platforms, gaming applications - must:

• Have a mechanism for verifying that the data subject is not a minor before relying on individual consent
• Obtain parental or guardian consent where processing involves a child
• Not require children to provide more data than necessary to access a service

The Kenya DPA 2019 does not specify an age below which parental consent is always required and above which child consent alone may suffice. In the absence of specific ODPC guidance, treating under-18 as the threshold for parental consent is the conservative and defensible approach.

When Consent Is the Wrong Legal Basis

Consent is often chosen because it feels safe - a data subject has agreed, so how can it be wrong? But consent is a high-maintenance legal basis. It can be withdrawn at any time, it requires ongoing records, it must be specific per purpose, and it places the burden of proof on the controller.

Use a different legal basis where:

• Processing is necessary for a contract with the data subject (section 30) - processing is necessary means consent is redundant and misleading
• Processing is required by law (section 30) - legal obligation is a more stable basis than consent, and you cannot rely on consent for processing the law mandates
• The power relationship makes free consent implausible - employer-employee processing, or any context where refusal has practical consequences
• The processing is genuinely in the vital interests of the data subject (section 30) - emergency health processing does not require consent and should not pretend to
• Legitimate interests are a better fit - where the processing is expected by the data subject, proportionate to the purpose, and the interests are not overridden by their rights

Relying on consent where another legal basis applies is not harmless. It means you are processing under a legal basis that can be withdrawn at any time, creates unnecessary DSR obligations, and may actually weaken rather than strengthen your compliance position.

Consent Validity at a Glance

Consent, done properly, is a genuine expression of data subject autonomy and a foundation for a trust-based relationship with your users and customers. Done improperly - or used as a substitute for thinking through the right legal basis - it is a compliance liability.