Kenya is one of the most mobile-money-dependent financial markets in the world, and one of the most digitally exposed. M-Pesa reshaped how an entire country moves money, fintechs built an industry on top of it, banks integrated with it, and SACCOs followed customers onto mobile channels. Every one of those rails is software, and the integrations between them are where money and data leak. Penetration testing is how a regulated institution finds those weaknesses before someone else does.
This guide is a broad look at penetration testing in Kenya: the regulatory drivers, the parts of the Kenyan environment that carry the most risk, what real testing looks like versus scanning, and how to choose a provider. If you are specifically a CBK-supervised bank, our CBK cybersecurity guide for Kenyan banks covers the CBK Guidance Note in detail; this post is the wider view across fintech, mobile money, SACCOs and the rest of the regulated sector. It is buyer education first. Where it describes how IMIZI Cyber works, that is to show what a credible engagement looks like.
The regulatory picture in Kenya
Three regimes drive security testing expectations for Kenyan institutions.
The Central Bank of Kenya (CBK) supervises banks, microfinance banks, payment service providers and digital credit providers. Its Guidance Note on Cybersecurity for the Banking Sector, with a parallel guideline for payment service providers, sets the baseline: board ownership of cyber risk, a designated security function, documented risk assessment, and independent assessment of critical systems reported to the board. We cover the CBK guidance, including how it compares to Rwanda's BNR regulation, in the dedicated CBK guide. For the purposes of this broader post, the key point is that CBK expects regular, independent testing of critical systems from the institutions it supervises.
The Data Protection Act 2019, enforced by the Office of the Data Protection Commissioner (ODPC), applies far more widely than CBK supervision. Any organisation that processes personal data (a bank, a fintech, a SACCO, a telco) is a data controller or processor and must implement appropriate technical and organisational measures to secure that data and report certain breaches. Penetration testing is the most direct evidence that those measures actually hold against an attacker rather than existing only on paper.
PCI DSS applies to any institution handling cardholder data and explicitly requires penetration testing, internal and external, at least annually and after significant change.
The practical reading: whether you are regulated by CBK, hold personal data under the Data Protection Act, or touch card data under PCI DSS, regular independent penetration testing is an expectation, and most Kenyan financial institutions sit under more than one of these at once.
Why the Kenyan environment carries specific risk
A generic engagement misses where Kenyan institutions actually get hit. The risk concentrates in a few places.
Mobile money is the centre of gravity
Kenya does not have mobile money as a feature; mobile money is the financial system. Banks integrate with it, fintechs build products on top of it, and SACCOs disburse and collect through it. That makes the integration between a wallet, a fintech platform and a core ledger one of the highest-value attack surfaces in the country. The risks are business-logic risks, the kind a scanner never finds: float manipulation, velocity-check bypasses, SIM-swap-assisted takeover, and gaps in the channel between systems. Our mobile money security testing guide goes into these flaws in depth. Any Kenyan engagement that leaves the mobile money channel out of scope is incomplete by definition.
Fintech and digital credit
Kenya's fintech sector ships fast, integrates heavily, and holds sensitive financial and personal data. Digital credit providers in particular pull in identity, transaction and contact data and make automated lending decisions through APIs. Fast shipping means new endpoints and new flows reach production before anyone reviews their authorisation logic, which is exactly where manual testing earns its keep.
SACCOs
SACCOs are easy to overlook and increasingly exposed. They hold member funds and personal data, they run mobile apps and member portals, and they integrate with banks and mobile money. They are data controllers under the Data Protection Act, and deposit-taking SACCOs carry additional oversight. Their digital channels carry the same risks as a small bank, but they are tested far less often. A SACCO mobile app with broken object-level authorisation exposes every member's balance just as surely as a bank app does.
SIM swap and the authentication chain
Because so much authentication in Kenya runs through the mobile number, SIM swap remains a persistent route to account takeover, bypassing SMS-based controls. Testing has to consider the authentication chain end to end, not just the application in isolation, because the weakest link is often the channel rather than the code.
Real penetration testing versus scanning
This distinction decides whether an engagement is worth anything.
A vulnerability scan runs an automated tool against your systems and matches them against a database of known issues. Scans are useful for hygiene and for catching missing patches at scale. They are also full of false positives, they cannot understand your business logic, and they prove nothing about exploitability. A scan tells you a port is open. It does not tell you that a member can read another member's account by changing a number in a request, or that a velocity check in the mobile money channel can be bypassed.
A penetration test is manual and evidence-led. A tester reasons about how your specific systems were built, chains individual weaknesses into a real attack path, and demonstrates impact: account takeover, unauthorised fund movement, exposure of data the user should never see. The deliverable is a set of findings, each with reproduction steps, proof it works, the business impact, and a remediation that fits your environment, not a tool dump.
The flaws that actually cause losses in Kenyan financial systems (a business-logic gap in a mobile money flow, broken authorisation in a fintech API, a SACCO portal that trusts a client-supplied identifier) are precisely what a scanner cannot find and a manual tester is paid to find.
The methodology that holds up to a regulator
IMIZI Cyber's testing is manual, evidence-led, and aligned to the same expectations Kenyan institutions answer to. A credible engagement looks roughly like this:
- Scoping and authorisation. Agree the systems in scope, including the channels that usually get dropped: mobile apps, mobile money integrations and partner APIs. Establish rules of engagement and written authorisation before anything is touched.
- Reconnaissance and mapping. Enumerate the real attack surface, including endpoints and flows that are not in the documentation.
- Manual exploitation. Test authentication and authorisation on every endpoint, business logic in payment, transfer and lending flows, input handling, and the trust boundaries between integrated systems. Chain weaknesses to demonstrate real impact.
- Evidence capture. Document each finding with reproduction steps and proof, so it is not a matter of opinion.
- Reporting. Deliver findings rated by real business risk, written so a technical team can fix them and a board or regulator can understand them. This is the BNR-aligned, evidence-led reporting standard we apply across every engagement, and it maps cleanly onto CBK and Data Protection Act expectations.
- Retest. Verify that remediations actually close the findings.
The methodology matters because every claim in the report is backed by proof, which is what a board can act on and a regulator will accept.
How to choose a provider operating across Africa
Penetration testing is a market with a wide quality range, and the badge on the website is not the differentiator. When evaluating any provider, including us, look for:
- Manual testing, not a rebadged scan. Ask directly how much of the engagement is hands-on and how the provider finds business-logic flaws. A vague answer means a scan.
- Recognised competence benchmarks. OSCP is the widely recognised benchmark for proving hands-on exploitation skill; CREST is a recognised assessor accreditation in many markets. Treat these as general benchmarks for evaluating any provider, not a substitute for asking what they actually do.
- Mobile money and financial systems experience. In Kenya specifically, a tester who understands the mobile money channel, fintech integrations and SACCO platforms will find issues a generalist walks straight past.
- Evidence-led reporting. Ask to see a sample report structure. You want reproduction steps, proof, business-risk ratings and clear remediation, not a tool export.
- A firm, not a freelancer. Continuity, accountability, retesting and a report that stands behind a regulatory conversation come from an established firm with a defined methodology.
How we can help
IMIZI Cyber is an offensive security firm based in Kigali, working with banks, fintechs, SACCOs, payment service providers, telecoms and other regulated institutions across Africa, Kenya included. Our testing covers web applications, APIs, mobile apps and mobile money integrations, network infrastructure and cloud, delivered as manual, evidence-led engagements. Our work is grounded in recognised offensive-security methodology, BNR-aligned engagement experience, and reporting a board and a regulator can both act on. We test it, and we write the report.
For broader context on offensive security across the continent, see our penetration testing in Africa overview. For CBK-specific banking requirements, see our CBK cybersecurity guide. If you operate beyond Kenya, our guides to penetration testing in Nigeria, penetration testing in Ghana, and penetration testing in South Africa cover the regulators and risks in each market. For our methodology and deliverables, see our penetration testing and security assessments service pages, and our about page for how engagements run. To scope an assessment for your Kenyan institution, contact us.