Digital Health and SaMD in Kenya: PPB Registration and Data Protection

Content verification date: October 30, 2026

1. Key takeaways

• Software is expressly written into the Kenyan medical device definition; software as a medical device (SaMD) is a device in Kenya and must follow the PPB registration route.
• The Health Act, No. 21 of 2017, Part XV, Sections 103–105 govern e-Health, electronic legislation and health information systems; Section 2 defines e-Health as the integrated use of electronic communication and information technology in the health sector, including telemedicine.
• The Data Protection Act, No. 24 of 2019, was assented November 8, 2019 and effective November 25, 2019; it established the Office of the Data Protection Commissioner and contains dedicated processing rules for health-related data, which is sensitive personal data.
• Cross-border transfer and localization requirements sit in Sections 48–50 of the Data Protection Act (conditions for transferring personal data outside Kenya, safeguards before transfer, and processing through data servers or data centres within Kenya).
• The registration duty of data controllers and data processors sits in Sections 18–24; data protection impact assessment in Section 31; notification and communication of personal data breaches in Section 43.

2. Legal basis

3. Expert insights

Insight 1: Software devices must pass three gates in Kenya

The first is the device-definition gate — software is written into the definition, so SaMD is a device. The second is the PPB registration gate — registration or listing must be completed according to the risk class, with the software, design verification and validation, and risk management modules submitted in the CSDT. The third is the data compliance gate — any product processing personal health data falls under the Data Protection Act, No. 24 of 2019. GRZAN’s note: a common oversight among companies, including those from the Chinese mainland, is to clear only the first two gates and treat data compliance as an IT issue rather than a registration issue, only to be asked for compliance proof by customers or partners at deployment.

Insight 2: Health-related data is sensitive personal data, raising the processing threshold

Chapter V of the Data Protection Act (Sections 44–47) governs sensitive personal data, with Section 46 addressed to personal data related to health. GRZAN’s reading: medical records, imaging, laboratory results and genetic information processed by medical software will almost inevitably fall within sensitive data, where the requirements for a lawful processing basis, consent mechanisms and security safeguards are higher than for ordinary personal data. When designing a product’s data flows, companies should set default configurations to the sensitive-data standard, corresponding to Section 41 on data protection by design and by default.

Insight 3: Cross-border transfer is a hard constraint on architecture, not a supplementary clause

Sections 48–50 govern the conditions for transferring personal data outside Kenya, the safeguards required before transfer, and processing through data servers or data centres within Kenya. GRZAN’s judgment: this is a substantive constraint for device companies operating cloud SaaS architectures, overseas centralized AI model training, or remote operations from abroad. Architecture decisions should be assessed before the registration submission, because once the deployment architecture is written into the dossier, later changes may trigger PPB variation notification duties.

Insight 4: Digital health has been built into the regulator’s organizational design

The draft KHPTA Bill lists a Digital Health and Technologies Committee among its scientific advisory committees (Fourth Schedule to the Bill, Senate discussion draft — practical estimate); in addition, a digital health agency is already participating in the construction of the national traceability and certification system (public reporting — practical estimate). GRZAN’s judgment: digital health in Kenya is being upgraded from a subcategory of devices to an independent regulatory line, and software device companies should expect more specialized review requirements and clearer registration positions.

4. Practical recommendations

1. Bring data compliance into the scope of the registration project. Determine the role under the Data Protection Act (controller or processor) and assess registration obligations at project initiation.
2. Design health data to the sensitive-data standard. Default configurations should satisfy Section 41 on data protection by design and by default.
3. Move architecture decisions forward. Finalize cloud deployment, cross-border transfer and remote operations plans before submission, avoiding later variation notifications.
4. Complete a data protection impact assessment. Where large-scale health data processing is involved, conduct the assessment under Section 31 and file it.
5. Build a breach response mechanism. Establish notification and communication processes for personal data breaches under Section 43.
6. Track developments in dedicated digital health review. Follow KHPTA legislation and the publication of digital-health-related guidelines.

5. Verification checklist

• □ Has it been confirmed that the software product is a medical device under Kenyan law?
• □ Have PPB risk classification and the registration route been completed and confirmed?
• □ Are the software, design verification and validation, and risk management modules of the CSDT complete?
• □ Has the controller/processor role determination and registration assessment under the Data Protection Act been completed (Sections 18–24)?
• □ Is health data designed to the sensitive personal data standard (Sections 44–47)?
• □ Has the cross-border transfer plan been assessed against Sections 48–50?
• □ Has a data protection impact assessment been conducted (Section 31) and a breach response mechanism built (Section 43)?
• □ Is the deployment architecture finalized and consistent with the dossier?

Regulatory information verified as of October 30, 2026.

In African markets, the GRZAN regulatory team focuses on jurisdictions including Kenya, Nigeria, South Africa and Egypt and maintains a verification mechanism built on primary regulatory sources: every regulatory conclusion published externally is based solely on official gazettes, the original text of agency guidelines and public legal databases, with the verification date stated; figures, timelines and amounts that cannot be located in official sources are marked as practical estimates, with no assumptions made.

GRZAN services cover: market access strategy and risk classification; preparation and review of registration dossiers (CSDT / STED / CTD formats); selection and management of Local Authorized Representatives (LAR); quality management system and GMP / GSDP compliance support; post-market vigilance, change management and recall response; import clearance and PVoC coordination; regulatory intelligence subscriptions and corporate compliance ledgers.

For a Kenya market access plan tailored to your product, contact the GRZAN regulatory team at info@grzanglobal.com.