Home / Blog / GRC & Compliance

Data Residency and Cross-Border Data Transfers Under the Kenya Data Protection Act: A Compliance Playbook

Data Residency and Cross-Border Data Transfers Under the Kenya Data Protection Act: A Compliance Playbook

Every Kenyan bank running Microsoft 365, every insurer using Salesforce, and every fintech deployed on AWS Ireland is conducting a cross-border data transfer — whether their compliance team has documented it or not. The Office of the Data Protection Commissioner (ODPC) has made clear through its enforcement notices that data residency and transfer legality are not theoretical concerns. They are audit triggers.

This playbook explains how to lawfully transfer personal data outside Kenya under the Kenya Data Protection Act (DPA) 2019 while continuing to use the global SaaS and cloud providers your business depends on.

What the Kenya Data Protection Act Actually Requires

Section 48 of the DPA and the Data Protection (General) Regulations 2021 govern cross-border transfers. In plain terms: you can transfer personal data outside Kenya only if one of the following applies.

  • The destination country provides adequate protection comparable to the Kenyan DPA.
  • You have appropriate safeguards in place (contractual clauses, binding corporate rules, certifications).
  • The data subject has given explicit consent after being informed of the risks.
  • The transfer is necessary for contract performance, public interest, legal claims, or vital interests.
  • For sensitive personal data or strategic categories (health, financial), additional conditions apply — including confirmation that the transfer is based on one of the above grounds and, in some cases, ODPC notification.

Certain categories of data — particularly those processed for national security, public revenue, or health services — must be processed and stored on servers located in Kenya under the Data Protection (General) Regulations. This is where data residency becomes non-negotiable.

Critical takeaway: The DPA does not ban cross-border transfers. It bans *undocumented* and *unjustified* ones. Your compliance posture is defined by the paperwork behind each transfer, not the transfer itself.

Step 1: Build a Data Transfer Register

You cannot protect what you have not mapped. Before you negotiate a single clause with Microsoft or AWS, produce a data transfer register that captures:

  • What personal data is leaving Kenya (categories, volumes, sensitivity)
  • Which SaaS or cloud provider is processing it
  • The destination country and region (e.g., AWS eu-west-1 in Ireland, Azure West Europe in Netherlands)
  • The lawful basis for the transfer under Section 48
  • The safeguards in place (Standard Contractual Clauses, Data Processing Addendum, certifications like ISO 27001 or ISO 27701)

Most enterprises we work with discover 30–50 undocumented SaaS tools handling personal data during this exercise. Shadow IT is your biggest transfer risk. Data Mapping and DPIA Services

Step 2: Match Each Transfer to a Lawful Mechanism

For each entry in your register, apply one of the following mechanisms.

Adequacy — Use With Caution

The ODPC has not yet published a formal adequacy list. Do not assume the EU, UK, or US qualifies as adequate simply because they have their own frameworks. Until adequacy decisions are gazetted, treat this mechanism as unavailable and rely on safeguards.

Standard Contractual Clauses and DPAs

This is the workhorse mechanism. Global providers including Microsoft, AWS, Google Cloud, and Salesforce publish Data Processing Addenda that incorporate SCC-equivalent terms. Sign them. Store them. Reference them in your transfer register. Confirm the DPA explicitly addresses Kenyan DPA obligations — not only GDPR.

Useful for narrow cases (marketing, optional features), but a poor foundation for enterprise SaaS. Consent can be withdrawn, forcing you to repatriate data.

Contractual Necessity

Applies where the transfer is necessary to perform a contract with the data subject — for example, processing an international payment. Document the necessity test.

Step 3: Address Residency Requirements Head-On

If you handle health records, tax data, or other regulated categories, work with your cloud provider to route these workloads to in-country or in-region infrastructure. Options include:

  • Microsoft Azure and AWS Local Zones — expanding across Africa, though full Kenyan residency remains limited
  • Regional hyperscaler presence — AWS Cape Town and Azure South Africa regions offer improved data locality for the EAC
  • Kenyan data centres — iColo, Africa Data Centres, and Safaricom's facilities provide domestic hosting for regulated workloads
  • Hybrid architecture — keep regulated data on-premises or in-country while running non-regulated workloads in global regions

Step 4: Operationalise Ongoing Compliance

Cross-border compliance is not a one-time project. Build these controls into your GRC programme:

  • Vendor onboarding checkpoint requiring DPA review before contract signature
  • Annual review of your transfer register
  • DPIA triggers for any new high-risk transfer or new SaaS category
  • Breach notification playbooks that account for multi-jurisdictional obligations
  • Board-level reporting on transfer risk exposure
Expert tip: When the ODPC opens an inquiry, the first document they ask for is your Record of Processing Activities. If cross-border transfers are not clearly logged with lawful basis, expect enforcement to escalate quickly.

The Bottom Line

You do not have to abandon Microsoft 365 or migrate everything to a Nairobi data centre to comply with the Kenya Data Protection Act. You need a defensible framework: a complete transfer register, a lawful mechanism for each transfer, residency solutions for regulated data, and continuous governance.

Want to know where your organisation stands? SecureZaidi offers a structured gap assessment to get you started.