Kenya's Cloud Policy 2025, explained for CIOs: the three data tiers and what you must do

Kenya's Cloud Policy 2025 sets a cloud-first mandate, three data tiers and CSP accreditation. A practical guide for CIOs in public entities and their suppliers.

By Shujaa Editorial Team, AWS Solutions Architects, Nairobi · · 6 min read

Government building in Nairobi with cloud infrastructure diagram overlay

Kenya’s Cloud Policy 2025 makes cloud the default for public entities, classifies government data into three tiers that dictate where it may be hosted, and requires cloud service providers serving government to be accredited by a Cloud Adoption Committee. If you run technology for a public entity, a parastatal or a supplier to either, you need a data classification, a migration plan and contracts with exit clauses. Here is what the policy says and what it means in practice.

What the policy is and why it exists

The Cloud Policy was gazetted in 2025 under the Ministry of Information, Communications and the Digital Economy. Its purpose is straightforward: move government services off ageing on-premises infrastructure, reduce duplicated spend across ministries and agencies, and do so without losing control of sensitive national data.

The policy introduces a cloud-first mandate. Public entities must consider cloud options before procuring new infrastructure, and must justify any decision to build or extend on-premises capacity. Implementation guidelines followed in June 2026, filling in the operational detail the policy itself left open.

For CIOs the headline obligations are:

  • Classify your data into one of three tiers.
  • Host each tier only where the policy allows.
  • Use only accredited cloud service providers for government workloads.
  • Submit a migration plan within the 12-month window the policy set.
  • Write contracts that include exit provisions and open data formats.

The three data tiers

The classification scheme is the heart of the policy. Everything else follows from it.

TierDefinition in practicePermitted hosting
Top SecretData whose disclosure would threaten national security or the operation of the stateGovernment cloud or private cloud physically located in Kenya
RestrictedSensitive data including much personal data, operational government data, financial and regulatory recordsPublic cloud located in Kenya
OpenData already public or intended for publication, with no confidentiality requirementPublic cloud, including regions outside Kenya

Two points trip up most organisations.

First, the Restricted tier requires public cloud located in Kenya. Until recently that was a difficult requirement to meet with a hyperscaler, because the nearest AWS Region is Africa (Cape Town). The agreement between the Konza Technopolis Development Authority (KoTDA) and AWS in August 2026 for an AWS Outpost at Konza changes the picture. It gives government a hybrid model where AWS services run on infrastructure physically within Kenya, managed from the Cape Town Region, with data remaining in the country. For Restricted workloads this is the architecture most public entities will end up designing around.

Second, classification is not a one-time exercise. A dataset can move tiers when it is aggregated, anonymised or combined with another dataset. Your classification process needs an owner and a review cadence, not just a spreadsheet.

Accreditation: what CSPs must prove

The policy establishes a Cloud Adoption Committee that accredits cloud service providers for government use. A provider must demonstrate conformance with ISO 27002:2022 (information security controls) and ISO 27017 (cloud-specific security controls), alongside the policy’s own requirements on data location, incident reporting and lawful access.

For a CIO this means two things. Your procurement must check the accreditation status of any CSP, and of any AWS Partner acting as a reseller or managed service provider on your behalf. And your own organisation must be able to evidence how the accredited provider’s controls map to your obligations, because the committee accredits the provider but the public entity remains accountable for the data.

AWS publishes its ISO 27017 and ISO 27002 alignment through AWS Artifact, which makes the evidence collection manageable. The harder work is the local layer: documenting how your deployment on AWS, or on an Outpost at Konza, satisfies the Kenyan requirements, which is where a partner with Well-Architected Partner Program status and public sector experience earns its fee.

The interaction with the Data Protection Act 2019

The Cloud Policy does not replace the Data Protection Act. The two operate together and a CIO needs both in view.

Regulation 26 of the Data Protection (General) Regulations lists categories of personal data that must be processed through a server or data centre located in Kenya. The list includes civil registration data, electoral data, public finance data, data on critical infrastructure, basic education data, and primary and secondary health data. If your organisation handles any of these, the Cloud Policy’s Restricted tier and Regulation 26 point in the same direction: the data stays in Kenya.

On 10 September 2026 the Office of the Data Protection Commissioner (ODPC) issued cross-border transfer guidance introducing Kenyan standard contractual clauses. This matters for the Open tier and for any Restricted workload with an approved cross-border component, for example a disaster recovery copy or a SaaS analytics tool hosted abroad. The clauses give you a recognised legal basis for the transfer, provided the data is not on the Regulation 26 list.

A workable rule of thumb for architecture teams:

  • Regulation 26 data: Kenya only, no exceptions, which in AWS terms means an Outpost in Kenya or a Kenyan data centre.
  • Other Restricted data: Kenya hosting by default; any cross-border flow needs a documented purpose, the ODPC clauses and a data protection impact assessment.
  • Open data: host where it makes operational sense, typically the Cape Town Region with Amazon CloudFront for delivery.

Contracts: exit clauses and open formats

The policy requires that contracts with cloud providers include exit provisions and use open data formats. In our experience this is the requirement most often ignored at signature and most regretted later.

An exit clause should state the notice period, the format in which data will be returned, the timeframe for return, the cost (if any) of egress, and the deletion certification you will receive. “Open formats” means your data must be recoverable without the provider’s proprietary tooling: CSV, Parquet, JSON, open database dumps, rather than a format only the vendor’s software can read.

On AWS this is achievable by design. Data in Amazon S3 in Parquet or CSV, databases on Amazon RDS with standard engines such as PostgreSQL, and infrastructure defined as code in AWS CloudFormation or Terraform are all portable. The point of the clause is to make sure your architecture choices keep them that way.

The 12-month migration plan

Public entities were given 12 months from the policy’s effective date to submit migration plans. Many submitted thin plans to meet the deadline. The June 2026 implementation guidelines expect something more substantial: an application inventory, a classification of each system’s data, a target hosting model per tier, a sequencing with dates, a cost estimate and a risk register.

If your submitted plan was thin, the sensible move now is to run a proper assessment. AWS funds migration assessments through its partner programmes, which we cover in Most enterprises pay full price for their AWS migration. They do not have to.. An assessment produces exactly the artefacts the guidelines ask for and sets up the subsequent migration for funding as well.

A practical sequence for the next six months

  1. Appoint a data classification owner and classify every system against the three tiers, cross-checked against the Regulation 26 list.
  2. Confirm the accreditation status of your existing and proposed cloud providers and partners.
  3. Review every existing cloud and SaaS contract for exit clauses and data format commitments. Remediate at renewal.
  4. Design the target architecture: Open tier in Cape Town, Restricted tier on in-country infrastructure such as the Konza Outpost, Top Secret on government cloud.
  5. Commission a funded migration assessment to produce the inventory, sequencing and cost model the guidelines expect.
  6. Put a governance rhythm in place: quarterly classification review, annual contract review, continuous compliance evidence through AWS Artifact and AWS Config.

What to do next

The Cloud Policy is not a compliance burden to be minimised. Handled properly, it is the mandate that finally lets a public sector CIO retire the server room, consolidate spend and build services on a modern platform. The sequencing above is realistic for a mid-sized agency with a committed sponsor.

Shujaa.ai is an AWS Advanced Tier Services Partner and AWS Public Sector Partner headquartered in Nairobi. We help public entities and their suppliers classify data, design compliant hybrid architectures and produce migration plans that satisfy the implementation guidelines. See our public sector practice.

Shujaa Editorial Team
AWS Solutions Architects, Nairobi. Shujaa.ai is an AWS Advanced Tier Services Partner headquartered in Nairobi.

Ready to be brave on cloud?

Book a 30-minute consultation with our experts. We will map your goal to the right approach, tell you whether an AWS program could help offset project costs, and tell you whether we are the right fit for it.