---
title: >-
  Record calls legally in Kenya: DPA notification, lawful basis, and retention
  that enforces itself
description: >-
  What Kenya's Data Protection Act requires before you record a call:
  notification wording, lawful bases per use case, and self-enforcing retention.
summary: >-
  Kenya treats voice as personal data. Notify at collection, pick a lawful
  basis, honour refusals — the ODPC has awarded KES 700,000 — and run a written
  retention schedule that actually deletes.
date: 2026-08-04T00:00:00.000Z
type: blog
---


## Summary

Call recording in Kenya is not governed by the one-party/two-party consent rules that dominate US-centric advice. A recorded voice is personal data under the Data Protection Act, 2019: recording a call is processing, which needs a lawful basis under section 30 and notification at the point of collection under section 29 — and an explicit refusal must be honoured, a lesson one company learned at a cost of KES 700,000. There is no fixed statutory retention period either; the law requires a documented retention schedule and deletion when the purpose lapses. This guide covers the preamble wording, the right lawful basis for each use case, and how to make the deletion half of your policy run itself.

## Forget one-party consent — in Kenya a recording is personal data

Search for call-recording rules and most of what you find explains US state law: one-party states, two-party states, whether you count as a party to your own call. None of it applies here. Kenya has no wiretap-style consent statute for business calls (as of July 2026). What Kenya has instead is the [Data Protection Act, 2019](https://new.kenyalaw.org/akn/ke/act/2019/24/eng@2022-12-31).

A voice recording identifies a living person — the Act's section 2 definition of personal data reaches identifiers like voice — so pressing record is processing personal data. That triggers two duties:

- **Notify at collection (section 29).** At or before the moment recording starts, tell the person that you are recording, why, who else will receive the data, and that they have rights under section 26 — including the right to object and to ask for deletion.
- **Have a lawful basis (section 30).** Consent is one basis, not the only one. Processing is also lawful where it is necessary to perform a contract, to meet a legal obligation, or for the controller's "legitimate interests" — unless the processing is unwarranted given the harm to the data subject's rights.

That last clause is why the practical rule is notification-plus-objection rather than consent-for-everything. A support line can record for quality assurance under legitimate interests if it tells callers up front. But when a caller says no, the balancing test collapses: continuing is very hard to defend.

Enforcement is not theoretical. The ODPC can levy administrative fines of up to KES 5 million or 1% of preceding-year annual turnover, whichever is lower (section 63), plus compensation orders on top — and it has already fined lenders millions over data misuse in collections (Whitepath, KES 5 million in 2023; Mulla Pride, KES 2.975 million in 2023, with a court challenge dismissed in 2025).

## The KES 700,000 refusal

The precedent every recording flow should be designed around is *Alston v Liquid Telecommunications Kenya Ltd* (ODPC Complaint No. 1125 of 2025, determined in February 2026). An HR call was recorded despite the employee's explicit refusal; the recording was then retained and shared with a sister company for use in arbitration. The ODPC found unlawful processing and awarded [KES 700,000 in compensation](https://www.capitalfm.co.ke/news/2026/02/odpc-call-recording-unlawful-processing-liquid-telecom/), plus an enforcement notice.

Three lessons for anyone building call flows:

1. **Notice is not enough when someone says no.** An objection on the call must change what your system does on that call.
2. **Every downstream use is its own processing.** Sharing the recording with a sister company needed its own lawful basis; it didn't get one.
3. **Retention compounds the violation.** Keeping the recording after the refusal was part of what the ODPC sanctioned.

Recording is not banned in Kenya. Recording someone who has said no — or without telling them — has already cost a company KES 700,000.

## The preamble: what to say before the beep

Section 29, translated into IVR terms, means the call opens with a short notice covering the fact of recording, the purpose, and a way out. The full recipient list and the consequences of refusal can live in your privacy notice — the ODPC's 2025 guidance notes on processing of recorded media (written for publishers, but the closest thing to official wording guidance) point the notification duty at an accessible privacy policy. Wording that works on a Kenyan line:

- **Support QA:** "This call may be recorded for quality assurance and training. To continue without recording, press 9."
- **Bilingual QA:** "Simu hii inaweza kurekodiwa ili kuboresha huduma. Kuendelea bila kurekodiwa, bonyeza tisa."
- **Collections:** "This call is recorded to keep an accurate record of your account and any payment arrangement we agree. Simu hii inarekodiwa kwa kumbukumbu za akaunti yako."

Here is the preamble as a [voice actions](/developers/concepts/voice-actions) document — the JSON your `voice_callback_url` returns when the call is answered:

```json
{
  "actions": [
    {
      "getDigits": {
        "timeout": 6,
        "numDigits": 1,
        "nested": [
          {
            "say": {
              "text": "This call may be recorded for quality assurance and training. Simu hii inaweza kurekodiwa ili kuboresha huduma. To continue without recording, press 9.",
              "language": "en-KE"
            }
          }
        ]
      }
    },
    {
      "dial": {
        "number": "+254720000100",
        "timeout": 30,
        "record": "record-from-answer"
      }
    }
  ]
}
```

Actions run top to bottom: if the caller presses nothing within the timeout, the flow falls through to the recorded `dial`. If they do press a key, the platform POSTs back to the same `voice_callback_url` with the `Digits` field populated — `getDigits` has no follow-up URL — and your handler branches.

The branch documents are short enough to build with the `sauti` chain from the Node SDK instead of hand-writing the envelope — same JSON on the wire, but the verb options are typed:

```bash
npm install @sautikit/node@0.2.0
```

> 
> 
> `@sautikit/node` is in preview — pin the version; the API may change before 1.0.
> 
> 

```js
import express from "express";
import { sauti } from "@sautikit/node";

const app = express();
app.use(express.json()); // voice callbacks arrive as JSON

const AGENT_LINE = "+254720000100";

app.post("/voice", (req, res) => {
  const digits = req.body.Digits || "";

  if (!digits) {
    // First hit (call answered): play the notice and listen for an objection.
    return res.json(preambleActions); // the actions document above
  }

  if (digits === "9") {
    // Explicit objection: honour it. Same service, no record flag — and log it.
    logObjection({ sessionId: req.body.sessionId, at: new Date().toISOString() });
    return res.json(
      sauti
        .say("Understood. This call will not be recorded.", { language: "en-KE" })
        .dial({ number: AGENT_LINE, timeout: 30 }),
    );
  }

  // Any other key: no objection raised — proceed as notified.
  return res.json(sauti.dial({ number: AGENT_LINE, timeout: 30, record: "record-from-answer" }));
});
```

The chain serializes itself, so `res.json(chain)` emits the `{ actions: [...] }` envelope directly — no `.build()` call needed. Builder timeouts are in seconds, as in the JSON above.

Log every objection with the session ID and a timestamp. If a complaint ever lands, that log is your evidence the refusal was honoured — the mirror image of what went wrong in the Liquid Telecom case.

## Pick the lawful basis per use case

The right section 30 basis differs by why you record, and getting it wrong is not cosmetic:

| Use case | Lawful basis | What you must do |
|---|---|---|
| Support QA and training | Legitimate interests (s.30(1)(b)(vii)) | Notify at call start; keep a documented legitimate-interest assessment; honour objections |
| Collections and dispute evidence | Contract performance (s.30(1)(b)(i)), backed by legitimate interests | Notify; tie recordings to the account; delete when the dispute window closes |
| Marketing and sales calls | Consent | Prior opt-in before automated marketing calls; honour opt-outs fast |

**Support QA** rests comfortably on legitimate interests — but the ODPC's 2025 guidance expects the interest to be "real and present," documented, and reassessed periodically. A one-page legitimate-interest assessment naming the purpose, the balancing consideration, and the review date is cheap insurance.

**Collections** should not rest on consent at all: a borrower in arrears can withdraw consent precisely when you need the record most. Recording to document the account and any payment arrangement sits on the loan contract and your legitimate interest in dispute evidence — a position consistent with the ODPC's guidance note for digital credit providers. You still notify, and you still honour objections. The wider conduct rules for collection calls are covered in our [debt reminder guide](/blog/debt-reminder-robocall-mpesa-kenya).

**Marketing** is the strictest lane, and the call itself is regulated before the recording ever is: automated calls without human intervention for direct marketing require prior consent under the KICA (Consumer Protection) Regulations, 2010 (Reg 17 — automated direct marketing is opt-in), and section 37 of the DPA requires express consent for commercial use of personal data. The recording rides on that same consent, and a verbal opt-out given on the call must be honoured — processing for direct marketing must stop within 7 days of the request (Data Protection (General) Regulations, 2021, Reg 18(3)).

## Retention: no statute hands you a number

The DPA sets no fixed retention period for call recordings. It sets something harder: section 25(g) says personal data may be kept in identifiable form "no longer than is necessary" for the purpose it was collected, and Regulation 19 of the [General Regulations, 2021](https://new.kenyalaw.org/akn/ke/act/ln/2021/263/eng@2022-12-31) requires every controller to maintain a **written retention schedule** — with time limits, periodic review, and erasure, deletion, anonymisation, or pseudonymisation once the purpose lapses. The schedule must state the purpose, the period, an audit provision, and what happens after audit.

Two statutes give you defensible anchors for specific classes:

| Recording class | Purpose | Defensible window | Anchor |
|---|---|---|---|
| Support QA | Coaching and quality scoring | Days to weeks | Purpose lapses when the review cycle ends |
| Dispute evidence | Proof of what was agreed | Life of the account plus the claim window | Contract claims are statute-barred after 6 years (Limitation of Actions Act, Cap 22, s.4(1)(a)) |
| AML-relevant records | Statutory record-keeping | 7+ years for reporting institutions | POCAMLA s.46 — whether recordings themselves are "transaction records" is interpretive; confirm with counsel |

The trap is not writing the schedule — it's enforcing it. Plenty of teams have a policy that says "QA recordings: 30 days" while the storage bucket quietly keeps everything since launch. Under Regulation 19 that gap is not an oversight; it's non-compliance you documented yourself. And Liquid Telecom shows the sharp end: retention after an objection became part of the violation.

## A retention policy that enforces itself

This is the part Sautikit takes off your plate. Recording retention is bound to your workspace's storage tier: every tier carries a fixed retention window, and recordings past the window are deleted automatically — no cron job of yours, no cleanup script that someone forgets to redeploy. Windows run from 24 hours on the included tier to 30 days on the largest paid tier (as of July 2026 — current tiers, sizes, and prices are on [/pricing](/pricing)). Pick the tier whose window matches your written schedule, cite it in the schedule's enforcement clause, and the deletion executes itself.

Deletion is also verifiable. Once a recording is pruned, `GET /v1/calls/{id}/recording` returns `410` with the error code `calls.recording_expired` — a machine-checkable answer to "is it actually gone?" that you can sample in an audit. The SDK wraps that endpoint as `client.calls.recording()` and raises a typed error rather than handing you a status code to inspect:

```js
import { SautikitClient, SautikitError } from "@sautikit/node";

const client = new SautikitClient({ apiKey: process.env.SAUTIKIT_API_KEY });

// Audit sample: pick recordings that should be past the window and prove they are gone.
for (const callId of sampleOfExpiredCalls) {
  try {
    const recording = await client.calls.recording(callId);
    console.warn("still retained past the schedule:", callId, recording);
  } catch (err) {
    if (!(err instanceof SautikitError)) throw err;
    // 410 calls.recording_expired past the window — the deletion is real.
    console.log("expired as scheduled:", callId, err.message);
  }
}
```

Recording itself costs KES 0.50 per recorded minute (as of 2026-06-30; see [/pricing](/pricing) for current rates).

For the classes that genuinely need years — a disputed account heading for court, AML records at a reporting institution — export those specific recordings to a store you control before the window closes ([record and stream to S3](/developers/guides/record-and-stream-to-s3) covers the pattern) and let everything else expire. Long retention should be the documented exception per recording class, never the default for the whole bucket.

Access control rounds it out. Fetching a recording returns a presigned URL that expires after 15 minutes — audio never sits behind a permanent link, and every fetch is an authenticated API call you can attribute. API keys carry scopes, and `recordings.read` is its own scope, separate from `calls.create` and `recordings.delete`: mint your QA dashboard a key that declares exactly the access it needs rather than a wildcard key. The same discipline carries into agent workflows — the Sautikit MCP server's `get_call_recording` tool wraps the same API under the same key scopes, so an AI assistant pulling call audio is as governed as any other client (see [/mcp](/mcp)).

## Ship checklist

- [ ] A recording notice at the start of every recorded flow, bilingual where your callers are
- [ ] An objection path that actually skips the `record` flag — and logs the objection with session ID and timestamp
- [ ] A documented lawful basis per recording class, with a legitimate-interest assessment where that's the basis
- [ ] A written retention schedule per Regulation 19: purpose, period, review, deletion action
- [ ] A storage tier whose retention window matches the schedule
- [ ] Deliberate export for long-retention classes; automatic expiry for everything else
- [ ] Prior opt-in consent captured before any automated marketing call

*This article is general information for teams building on Sautikit, not legal advice — for decisions that carry regulatory exposure, engage a Kenyan data-protection practitioner.*

## Get started

1. [Create a Sautikit workspace](/) and claim a phone number.
2. Top up over **M-Pesa**: KES billing, no card.
3. Add the recording preamble above to your `voice_callback_url` handler, then match your storage tier to your retention schedule.

**[Start with Sautikit →](/)**  ·  **[See pricing →](/pricing)**  ·  **[Need SMS, WhatsApp & an agent desk? Helloduty →](https://helloduty.com)**

## Further reading

- [Ship compliant voice in Kenya: CAK, DPA 2019, lawful intercept](/blog/voice-regulation-kenya)
- [Voice actions reference](/developers/concepts/voice-actions) and the [record verb](/developers/voice-actions/record)
- [Call model and recording lifecycle](/developers/concepts/calls)
- [Record and stream to S3](/developers/guides/record-and-stream-to-s3)