When Does Your Organisation Need a DPIA Under the Kenya DPA 2019?

A Data Protection Impact Assessment (DPIA) is not bureaucratic paperwork. It is a structured, documented exercise that forces your organisation to think through the privacy risks of a processing activity before those risks materialise - and under section 31 of the Kenya Data Protection Act 2019, it is a legal obligation for high-risk processing.

This guide explains when a DPIA is required, what it must contain, and what happens when the residual risk is still too high after you complete one.

What Section 31 Actually Says

Section 31(1) of the Kenya DPA 2019 requires a data controller to carry out a data protection impact assessment where a type of processing is "likely to result in a high risk to the rights and freedoms of a natural person."

The Act does not enumerate every processing activity that triggers this obligation. Unlike the GDPR, where supervisory authorities publish lists of processing types that always require a DPIA, the ODPC has not yet published a comparable mandatory list. Kenyan controllers must therefore apply a risk-based assessment to determine whether any given processing activity crosses the high-risk threshold.

Practical rule of thumb: If you would be uncomfortable explaining the processing activity to an affected data subject - because of the volume of data, the sensitivity of the data, or the potential consequences - that discomfort is a signal to conduct a DPIA.

What Makes Processing "High Risk"?

In the absence of ODPC-specific guidance, the following are recognised indicators of high risk. The more that apply, the more clearly a DPIA is required:

• Large-scale or systematic processing - a large number of data subjects, or systematic monitoring through CCTV, employee monitoring systems, or location tracking
• Sensitive personal data as defined in s.2 - race, health status, ethnic social origin, conscience or belief, genetic or biometric data, property details, marital status, family details, or sex and sexual orientation (processing conditions in ss.44-47)
• Data relating to children under section 33, or data that could enable identity theft
• Automated decision-making with significant effects - credit scoring, recruitment screening, insurance underwriting, or fraud detection
• Systematic profiling or evaluation of individuals
• Cross-border transfers of personal data under section 48
• Innovative technology where the privacy implications are not yet well understood
• Processing data from vulnerable individuals - patients, benefit recipients, or employees in dependent relationships

Even where a single factor is present, a documented screening assessment is good practice. If the conclusion is that a full DPIA is not required, record that conclusion and the reasoning.

What a DPIA Must Contain

Section 31(2) specifies the required content. Each DPIA must document:

1. A description of the processing - what data is processed, for what purpose, by what means, and by whom
2. An assessment of necessity and proportionality - why this processing is necessary, and whether a less intrusive approach would achieve the same purpose
3. A risk assessment - the nature, likelihood, and severity of risks to data subjects' rights and freedoms
4. Risk mitigation measures - the technical and organisational controls that address identified risks, and the residual risk after those measures are applied

A thorough DPIA typically addresses more than this minimum. Consider also documenting the legal basis for processing under section 30, data flows (where data comes from, where it goes, who has access at each stage), how data subject rights requests will be handled for this specific processing activity, and any consultation conducted with affected data subjects or their representatives.

The Six-Step DPIA Process

Step 1: Screen the processing activity. Determine whether the proposed processing is likely to be high risk. Document the screening decision - including if the conclusion is that a full DPIA is not required.

Step 2: Describe the processing. Document the full scope: purposes, data types, data subjects, recipients, retention periods, and technical infrastructure.

Step 3: Assess necessity and proportionality. Is the processing necessary for the stated purpose? Could a less privacy-invasive approach achieve the same outcome? Is the lawful basis appropriate?

Step 4: Identify and assess risks. For each identified risk, describe the specific threat to data subjects, rate the likelihood of that risk materialising (high, medium, or low), and rate the severity of the impact if it does. Produce an overall risk rating for each.

Step 5: Identify and apply mitigations. For each identified risk, document the control or measure that will reduce it - encryption, access controls, anonymisation, contractual safeguards, staff training. Assess the residual risk after each measure.

Step 6: Record, approve, and review. The DPIA should be formally approved before the processing begins. It should be reviewed whenever the processing changes materially, and at a minimum annually for ongoing high-risk activities.

When Must You Consult the ODPC?

Section 31(3) creates a mandatory consultation obligation: where the DPIA indicates that the processing would result in a high residual risk to data subjects, and the controller cannot mitigate that risk with reasonable measures, the controller must consult the ODPC before commencing the processing.

This is a hard stop - not a recommendation. The processing cannot begin until the ODPC has been consulted and the consultation is resolved.

Under section 31(5), the consultation submission must be made at least 60 days before the processing begins - so plan the consultation into your project timeline, not as an afterthought. In response, the ODPC may:

• Approve the processing, with or without conditions
• Prohibit the processing entirely
• Request further information before issuing advice

Document the submission date and every ODPC response. A controller that demonstrates they consulted - and implemented the ODPC's recommendations - is in a materially stronger position than one that simply proceeded.

Who Should Own the DPIA?

The data controller is legally responsible for completing the DPIA under section 31. In practice, this means:

• The project or system owner leads the DPIA for their specific processing activity
• The Data Protection Officer (DPO), where one has been designated under section 24, advises on the DPIA and monitors compliance with the process
• Legal and IT contribute to legal basis analysis and technical risk assessment respectively
• Senior management approves the DPIA and accepts any residual risk before the processing begins

The DPO's role is advisory - the DPO does not own the DPIA, and the controller cannot transfer the legal accountability to the DPO by having them sign it off.

Common DPIA Mistakes

Conducting the DPIA after the fact. A DPIA completed after a system is already live is not a DPIA - it is a retrospective audit. The legal obligation is to assess risk before processing begins. Schedule the DPIA as a gate in your project delivery process.

Treating it as a form-filling exercise. A DPIA that ticks boxes without genuinely engaging with the risks is unlikely to withstand ODPC scrutiny. The value is in the thinking, not the document.

Assessing risk without the right people in the room. A compliance officer alone cannot fully assess the technical risks of a new data system. The process should bring together IT, legal, the business team, and - where feasible - representatives of affected data subjects.

Not updating it when things change. A DPIA conducted for a system that has materially changed is no longer accurate. High-risk processing should be reviewed at least annually, and whenever the processing, technology, or legal context changes.

Confusing "low likelihood" with "acceptable risk." A data breach affecting thousands of patients is high severity even if its likelihood is low. Risk = likelihood × severity. Do not dismiss high-severity risks simply because they seem unlikely.

DPIA Requirements at a Glance

A DPIA done well is an operational asset. It surfaces privacy risks before they become breaches, forces product teams to make deliberate design choices, and gives the ODPC clear evidence of your accountability posture. A DPIA done badly - or not at all - is a liability.