CBK Rules Explained

Yes. The Central Bank of Kenya's Guideline on Cybersecurity for Payment Service Providers (July 2019) requires every PSP to run continuous monitoring and periodic penetration testing. Where monitoring is not effective, section 3.2.5 sets a floor: quarterly vulnerability scans of critical cyber assets, an annual penetration test, and bi-annual vulnerability assessments.

That is the snippet answer. The useful answer is in the detail, because most Kenyan payment firms read the rule as "one pentest a year" and stop there. The guideline asks for more than that, it asks for it continuously, and it expects you to prove it.

Contents

• What does the CBK guideline actually require?
• Who does the guideline apply to?
• The three testing obligations, one by one
• What changes if you have continuous monitoring?
• How do you prove compliance to the CBK?
• Which other Kenyan rules sit next to this one?
• Common mistakes we see
• FAQ

What does the CBK guideline actually require?

The CBK guideline requires each payment service provider to include monitoring and testing in its cybersecurity program, built from its own risk assessment. Section 3.2.5 says the testing "shall include continuous monitoring and periodic Penetration Testing and Vulnerability Assessments". Periodic penetration testing is therefore required whatever else you have in place.

The guideline then sets a minimum schedule for PSPs without effective continuous monitoring. In its own words, a PSP "shall conduct":

(i) quarterly vulnerability scans of all critical cyber assets;
(ii) annual Penetration Testing of the PSP that cover, at a minimum, the critical cyber assets as determined each given year based on the Risk Assessment; and
(iii) bi-annual vulnerability assessments, including any systematic scans or reviews of Information Systems reasonably designed to identify publicly known cybersecurity vulnerabilities…

Two other clauses widen the picture, and both are easy to miss:

• Section 3.2.2(ii) says systems, policies, procedures and controls "should be reviewed, audited and tested annually for critical cyber assets and once every two years for other assets and after significant changes".
• Section 3.5.3 asks external auditors to "conduct comprehensive penetration tests" and to report annually to the PSP's board and to the CBK.

So the CBK expects testing on a calendar, testing after change, and an independent view that reaches the regulator.

Who does the guideline apply to?

Section 1.3 is short: the guideline applies to all payment service providers authorized under the National Payment System Act, 2011. Mobile money operators, payment gateways, aggregators, remittance and e-money businesses licensed under that Act are in scope.

Commercial banks licensed under the Banking Act follow the CBK's separate Guidance Note on Cybersecurity (August 2017). The PSP guideline says so explicitly when it sets the policy submission deadline in Part IV.

Operators of systemically important and system-wide important payment systems (SIPS and SWIPS) carry extra duties under section 3.3, including a CISO who reports to the board, and a 2-hour incident notification window instead of 24 hours.

The three testing obligations, one by one

Each obligation answers a different question. Treat them as layers, not substitutes.

Obligation	Frequency	What it covers	What it proves
Vulnerability scan	Quarterly	All critical cyber assets	Known weaknesses are being looked for
Vulnerability assessment	Bi-annual	Information systems, based on the risk assessment	Scan results have been reviewed and prioritized
Penetration test	Annual	At minimum, the critical cyber assets named in that year's risk assessment	An attacker cannot do what the scan only suggests

Figure 1. A minimum CBK testing year for a PSP without effective continuous monitoring. The retest is not named in the guideline, but without it you cannot show that a finding was closed.

Quarterly vulnerability scans

A scan is automated discovery: known vulnerabilities, missing patches, exposed services. The guideline asks for it on all critical cyber assets, which section 1.4.9 defines as the "programmable electronic devices and communication networks including Hardware, Software and Data that are essential to the reliable operations of critical assets". In a payment business that is the switch, the core ledger, the customer and agent apps, the APIs partners call, and the cloud accounts underneath them.

Bi-annual vulnerability assessments

An assessment is a scan plus judgement. Someone reviews the results against the risk assessment, removes false positives and decides what gets fixed first. The guideline does not define "bi-annual". We read it as twice a year, which matches how it pairs with quarterly scans. If your auditor reads it as every two years, settle the definition in writing before the year starts.

The annual penetration test

A penetration test tries to exploit what the scan finds, inside an agreed scope, and reports what an attacker could actually achieve. The CBK scope is a floor: the critical cyber assets identified in that year's risk assessment. If your risk assessment changed because you launched a new API or moved to a new cloud region, the pentest scope changes with it.

What changes if you have continuous monitoring?

The fixed schedule applies "in the absence of an effective continuous monitoring, or other systems to detect, on an ongoing basis, changes in information systems that may create or indicate vulnerabilities". Effective continuous monitoring lets you replace the fixed calendar with a risk-based one. It does not remove periodic penetration testing, which section 3.2.5 still requires.

Figure 2. Continuous monitoring changes how often you test. It never removes the penetration test.

"Effective" is the word to defend. A dashboard that nobody reads is not monitoring. In our experience an auditor accepts continuous monitoring when you can show three things:

1. Coverage. Every critical cyber asset is in the monitoring inventory, and new assets join it automatically.
2. Detection of change. New endpoints, dependencies, open ports and permission changes raise an event within days, not quarters.
3. Action. Each event has an owner, a decision and a closure record, and the high-severity ones are verified as fixed.

If you cannot produce those three on request, run the fixed schedule. It is the cheaper argument to win.

How do you prove compliance to the CBK?

Compliance with section 3.2.5 is proven by records, not by the test itself. Keep a dated evidence pack for each testing cycle that links the risk assessment, the scope, the people who tested, the findings, the fixes and the retest. If one link is missing, the cycle is hard to defend.

Figure 3. The evidence chain. A gap anywhere breaks the story you tell the auditor.

A complete pack for one year holds:

• The risk assessment that named the critical cyber assets for that year.
• The written scope and rules of engagement for each test, signed before testing began.
• Tester credentials. Section 3.5.2 asks internal audit to "oversee the regular penetration tests and vulnerability scans", so record who tested and how they qualify.
• The report, with reproducible evidence for every finding: the request, the response, the impact. A severity label alone is not a finding.
• The remediation log: owner, fix date and change reference for each finding.
• Retest evidence showing each fix holds.
• The annual external audit report that went to the board and the CBK under section 3.5.3.

Part IV adds two reporting duties that draw on the same records: notify the CBK within 24 hours of a significant cybersecurity incident (2 hours for SIPS and SWIPS), and send a quarterly incident report in the Annex III format.

Which other Kenyan rules sit next to this one?

A Kenyan PSP answers to the CBK for cybersecurity and to the Office of the Data Protection Commissioner (ODPC) for personal data. The two regimes overlap on testing evidence and incident handling but have different clocks.

Figure 4. Two regulators, two clocks. Build one incident process that meets the faster one.

• Registration. Financial services providers must register with the ODPC regardless of turnover or headcount, according to the ODPC's registration FAQ. The general exemption only covers entities with turnover below KES 5 million and fewer than 10 employees, and it does not apply to financial services. Registration fees run from KES 4,000 to KES 40,000 by size, and a certificate is valid for 24 months.
• Breach notification. Section 43 of the Data Protection Act, 2019 requires notice to the Data Commissioner within 72 hours of becoming aware of a breach that poses a real risk to data subjects.
• Incident notification. The CBK expects notice within 24 hours of a significant incident. If one event triggers both rules, the CBK clock runs out first.

Common mistakes we see

1. Treating the annual pentest as the whole obligation. It is one of three layers, and the scans and assessments are the ones that show the CBK you watch the gap between tests.
2. A scope that ignores the risk assessment. The minimum pentest scope is set by that year's risk assessment. A copy of last year's scope fails the moment the business changes.
3. No retest. A report full of findings and no proof they were fixed tells the auditor you found problems and kept them.
4. Claiming continuous monitoring without the records. If you cannot show coverage, detection and action, you are on the fixed schedule whether you like it or not.
5. Testing nothing after a significant change. Section 3.2.2(ii) asks for testing after significant changes. A new partner API launched in March should not wait for next January's test.

How SecureGraph helps

SecureGraph runs scoped, authorized testing against your web applications and APIs continuously, verifies every finding before it reaches a report, and keeps the evidence chain above in one place, including the retest. It does not replace the independent external test the CBK expects from your auditors. It makes sure that test finds less, and that you can show what happened in the other 50 weeks. See how we handle data on our trust page, or talk to us about a CBK testing calendar.

Register now on SecureGraph: platform.phantixlabs.com/register

FAQ

Does the CBK require penetration testing every year?

Yes. Section 3.2.5 of the CBK guideline requires annual penetration testing covering, at minimum, the critical cyber assets in that year's risk assessment, for any PSP without effective continuous monitoring. PSPs with continuous monitoring must still run periodic penetration tests.

How often must a Kenyan PSP run vulnerability scans?

Quarterly, on all critical cyber assets, unless the PSP has effective continuous monitoring that detects changes on an ongoing basis. Vulnerability assessments, which review and prioritize scan results, are required bi-annually.

Do commercial banks follow this guideline?

No. Commercial banks licensed under the Banking Act follow the CBK's Guidance Note on Cybersecurity of August 2017. The PSP guideline applies to payment service providers authorized under the National Payment System Act, 2011.

How fast must a PSP report a cyber incident to the CBK?

Within 24 hours for a cybersecurity incident that could significantly affect services, reputation or financial condition, followed by a full report. SIPS and SWIPS operators have 2 hours. PSPs also send a quarterly incident report.

Is an automated scan enough to meet the pentest requirement?

No. The guideline lists scans and penetration tests as separate obligations. A scan lists possible weaknesses; a penetration test shows which ones an attacker can actually exploit.

---

Last reviewed: 1 November 2026. This post summarizes the CBK guideline of July 2019 and the ODPC's published guidance as read on that date. It is not legal advice; confirm your obligations with the CBK, your auditors or counsel.