CBK cybersecurity guidance: test your mobile banking app and the APIs behind it.
The Central Bank of Kenya's 2017 Guidance Note on Cybersecurity asks banks to carry out an independent cyber threat test at least once a year, and puts threat and vulnerability assessments and comprehensive penetration tests in the internal and external audit scope. Its 2019 guideline for payment service providers sets quarterly vulnerability scans and annual penetration testing. The Data Protection Act 2019 requires safeguards by design and by default. Ostorlab tests your app and the APIs behind it, behind login, on every release.
- Tests the mobile app and the APIs it calls, on the build your customers download
- Tests login, one-time codes, step-up checks and session handling with your test accounts
- Lists the SDKs and native libraries in each release and maps them to known vulnerabilities
- Proves each finding with a replayable exploit or request and response evidence
- Who it applies to
- Banks licensed under the Banking Act, and payment service providers authorised under the National Payment System Act, 2011
- Key date
- Guidance Note on Cybersecurity issued in August 2017; payment service provider guideline in July 2019; CBK is updating the 2017 guidance
- Focus
- Independent cyber threat testing, vulnerability assessment and penetration testing, third-party risk and data protection
- Main reference
- CBK Guidance Note on Cybersecurity for the Banking Sector, August 2017
The CBK texts behind your mobile channel
The 2017 banking guidance, the payment service provider guideline and the National Payment System rules sit alongside the Data Protection Act. The dates below are for the texts and developments cited on this page.
- 2011 and 2014
National Payment System Act and Regulations
The National Payment System Act, No. 39 of 2011 gives CBK oversight of the payment system and the power to issue directives and guidelines. The 2014 Regulations add operational, audit trail, reporting and annual system security audit duties for payment service providers.
- January 2013
Risk Management Guidelines
CBK issues the risk management guidelines. Section 7 covers ICT risk, including vulnerability scanners and penetration testing as the tools for identifying vulnerabilities, and the information security programme.
- August 2017
Guidance Note on Cybersecurity
CBK issues the Guidance Note on Cybersecurity for the Banking Sector under section 33(4) of the Banking Act. It requires an independent cyber threat test at least once a year, includes threat and vulnerability assessments and comprehensive penetration tests in audit scope, and requires significant incidents to be reported to CBK within 24 hours.
- July 2019
Payment service provider guideline
CBK issues the Guideline on Cybersecurity for Payment Service Providers. It sets quarterly vulnerability scans of critical cyber assets, annual penetration testing and bi-annual vulnerability assessments, with 90 days to comply.
- March 2025
Adoption survey
CBK surveys how banks adopted the 2017 Guidance Note. All respondents said they conduct vulnerability assessment and penetration testing, at annual, quarterly or monthly intervals, and 92 percent had IT auditors in their internal audit teams. The report is published in June 2025.
- 22 September 2025
Banking sector SOC
CBK announces the Banking Sector Cyber Security Operations Centre, run under its Cyber Fusion Unit, and starts aligning the 2017 and 2019 cybersecurity guidelines with the 2024 regulations on critical information infrastructure. Institutions must keep complying with both sets of requirements and report incidents to the centre.
- 22 September 2026
Guidance under review
The 2025 Bank Supervision Annual Report says CBK has embarked on updating the 2017 Guidance Note. Banks surveyed asked for API security, artificial intelligence, cloud computing and mobile money fraud controls to be covered.
- September 2026
Draft texts for comment
CBK publishes revised draft Prudential Guidelines, Risk Management Guidelines and Guidance Notes for comment on 10 September 2026, and the National Treasury and CBK publish the draft National Payment System Policy and Bill 2026 on 21 September 2026. These are drafts, not yet in force.
The CBK texts, applied to your mobile app
For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team.
- Guidance Note on Cybersecurity for the Banking Sector, August 2017, section 3.2
Run an independent cyber threat test at least once a year
What the text says
Institutions should engage external consultants with sufficient cybersecurity expertise to assist in understanding their cyber threat landscape, and should carry out an independent cyber threat test at least once a year. External auditors should conduct independent threat and vulnerability assessments and comprehensive penetration tests as part of the IT audit scope, and report annually to the board and to the Central Bank of Kenya on the findings.
Source:Guidance Note on Cybersecurity for the Banking Sector, August 2017, section 3.2
What it means for your mobile app
The yearly test is a minimum, not a ceiling. The app and the APIs it calls are part of the systems in scope, and every store release is a change to them.
How Ostorlab helps
An AI-agent pentest tests the app and its APIs behind login, on the build you ship, with a working exploit you can replay for each AI-agent finding. It can run on every release, between the yearly tests.
What stays with you
Choosing the external consultants, the audit scope, and the annual report to the board and CBK.
- Guidance Note on Cybersecurity for the Banking Sector, section 3.2 (internal audit and risk management functions)
Keep threat and vulnerability testing in the audit scope
What the text says
Internal audit should include qualified ICT auditors, in house or outsourced. Their scope includes continuously reviewing and reporting on cyber risks and controls of the ICT systems and related third-party connections, assessing the design and effectiveness of the cybersecurity framework, conducting regular independent threat and vulnerability assessments, conducting comprehensive penetration tests, and reporting the findings to the board. Risk management should maintain a cyber risk register and a comprehensive inventory of IT assets classified by business criticality, and conduct red team exercises.
What it means for your mobile app
The audit scope names third-party connections. For a mobile banking app, that means the app, the SDKs inside it and the APIs it calls, not only the core banking system.
How Ostorlab helps
Mobile DAST runs the app and its flows and returns findings with decompiled source context, traffic, stack traces and screenshots, so the audit team has evidence it can work with.
What stays with you
The audit plan, the red team exercise, and the findings reported to the board.
- Guideline on Cybersecurity for Payment Service Providers, July 2019, sections 3.2.5 and 4.0
Meet the payment service provider testing cadence
What the text says
The 2019 Guideline on Cybersecurity for Payment Service Providers requires a cybersecurity programme with continuous monitoring and periodic penetration testing and vulnerability assessments. In the absence of effective continuous monitoring, providers should conduct quarterly vulnerability scans of all critical cyber assets, annual penetration testing covering at least the critical cyber assets determined for that year based on the risk assessment, and bi-annual vulnerability assessments. Providers had 90 days from the effective date of the guideline to comply.
Source:Guideline on Cybersecurity for Payment Service Providers, July 2019, sections 3.2.5 and 4.0
What it means for your mobile app
If your institution or group runs a payment service, the cadence is quarterly scans, an annual penetration test and bi-annual assessments. The mobile channel and the APIs behind it are critical cyber assets.
How Ostorlab helps
Ostorlab runs from your CI/CD pipeline on every build and can scan store releases without manual triggers, so quarterly testing or better is a schedule, not a project.
What stays with you
Deciding what counts as a critical cyber asset, continuous monitoring, and the risk assessment behind the annual scope.
- National Payment System Regulations, 2014, regulations 27 and 29
Secure the payment service and keep the audit trail
What the text says
Payment service providers must establish adequate operational arrangements for their services, including measures to ensure the safety, security and operational reliability of the service and contingency arrangements. They must use systems that provide an accurate and fully accessible audit trail of transactions from origin to finality, keep records of every electronic transfer for at least seven years, report incidents of fraud and material service interruptions or major security breaches to the Central Bank of Kenya every month, and submit a system security audit report by a reputable independent audit firm every year.
Source:National Payment System Regulations, 2014, regulations 27 and 29
What it means for your mobile app
The audit trail, the seven-year record and the monthly report are the provider's obligations. The app and its APIs are where transactions start, so their behaviour is part of the evidence.
How Ostorlab helps
Ostorlab tests the app and its APIs and keeps request and response evidence for each finding, ready to attach to the annual system security audit and the remediation record.
What stays with you
Record keeping, the monthly reports to CBK, and appointing the independent audit firm.
- Guidance Note on Cybersecurity for the Banking Sector, sections 2.4 and 3.1
Deploy strong authentication for customer data and transactions
What the text says
Senior management should oversee the deployment of strong authentication measures to protect customer data, transactions and systems. The Guidance Note lists poor authentication controls among the sources of cyber risk, and expects the CISO to ensure the institution maintains a current enterprise-wide knowledge base of its users, devices and applications, including software and hardware asset inventory and network maps.
Source:Guidance Note on Cybersecurity for the Banking Sector, sections 2.4 and 3.1
What it means for your mobile app
The second factor has to be enforced by the server on key operations, not only drawn by the app. One-time codes, timeouts and step-up checks are behaviours you can test.
How Ostorlab helps
Authenticated testing covers login and logout, token refresh, timeouts, session invalidation and MFA enforcement, including step-up flows, with your test accounts.
What stays with you
Choosing the authentication methods, delivering one-time codes, and supporting customers who are locked out.
- Guidance Note on Cybersecurity, section 3.3; Prudential Guidelines, CBK/PG/16 on Outsourcing, sections 4.1.4 and 4.5
Manage third parties and outsourcing
What the text says
Institutions should ensure that their third parties comply with legal and regulatory frameworks and international best practice. They should have adequate governance of outsourcing agreements, including due diligence on prospective service providers, documented agreements and adequate monitoring of service delivery; select vendors based on compliance and risk assessments; require service providers to comply with applicable legal and regulatory frameworks; monitor them for changes in their business and cyber posture; and have service level agreements with robust provisions on security, service availability, performance metrics and penalties. Under Prudential Guideline CBK/PG/16, material outsourcing requires approval from the Central Bank of Kenya, and the provision of mobile financial services channels or technology is given as an example of material outsourcing.
What it means for your mobile app
The SDKs in your app and the backends they call are third parties. Their security posture belongs in your due diligence and monitoring, and some outsourcing needs CBK approval before it starts.
How Ostorlab helps
SCA and SBOM list the SDKs and native libraries in each release with their versions, and network analysis shows which backends the app and its SDKs talk to.
What stays with you
Due diligence, contracts, CBK approvals, and exit plans.
- Risk Management Guidelines, January 2013, sections 7.3.4, 7.4 and 7.5
Run an ICT risk framework and test with the right tools
What the text says
The Risk Management Guidelines require an ICT risk management framework with board oversight, an ICT risk policy, and an information security programme that promotes awareness and reports the evaluation of information security to the board. For identifying vulnerabilities, the guidelines name vulnerability scanners, which compare a system or its responses to a database of flaw signatures, and penetration testing, an attempt by human security analysts to exercise threats against a system, including operational vulnerabilities such as social engineering. Risks are assessed, measured, mitigated and documented.
Source:Risk Management Guidelines, January 2013, sections 7.3.4, 7.4 and 7.5
What it means for your mobile app
Scanners and penetration tests are the two named tools for finding vulnerabilities. A mobile app needs both: analysis of the build and dynamic testing of the running app and its APIs.
How Ostorlab helps
Mobile SAST analyses the APK, AAB or IPA with taint analysis across the app and its embedded SDKs, and Mobile DAST runs the app. Both run in CI/CD on every build.
What stays with you
The ICT risk policy, board reporting, and the wider information security programme.
- Data Protection Act, 2019, sections 41 and 42; Data Protection (General) Regulations, 2021, regulation 32
Protect personal data by design or by default
What the text says
The Data Protection Act 2019 requires every data controller or data processor to implement appropriate technical and organisational measures designed to implement the data protection principles effectively and to integrate necessary safeguards into the processing, both when the means of processing are determined and at the time of processing. By default, only personal data necessary for each specific purpose should be processed. Measures to consider include identifying internal and external risks to personal data, maintaining safeguards against them, pseudonymisation and encryption, restoring availability after an incident, verifying that the safeguards work, and updating them for new risks or deficiencies. Where processing involves transmission over a network, the controller must have regard to the state of technology, the cost of measures, the special risks and the nature of the data. The General Regulations list the elements of the integrity, confidentiality and availability principle, including assessing risks against the security of personal data, audit trails and event monitoring, and regularly reviewing and testing software to uncover vulnerabilities of the systems supporting the processing.
What it means for your mobile app
The app is where personal data is collected, stored and sent. Design choices such as what is cached, how it is encrypted and what is logged are part of the measures the Act asks for.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, checks transport protections, and finds API keys, tokens and credentials in the app package and validates whether they work.
What stays with you
Data protection impact assessments, consent, retention rules, and breach handling.
- Guidance Note on Cybersecurity, Part IV; Data Protection Act 2019, section 43; National Payment System Regulations, 2014, regulation 29(2)
Report incidents and keep the record
What the text says
The Guidance Note requires institutions to notify the Central Bank of Kenya within 24 hours of any cybersecurity incident that could have a significant and adverse impact on the institution's ability to provide adequate services to its customers, its reputation or its financial condition, and to submit a quarterly report on incidents and how they were handled. The Data Protection Act requires a data controller to notify the Data Commissioner without delay and within 72 hours of becoming aware of unauthorised access or acquisition of personal data with a real risk of harm to the data subject, and to communicate with the data subject in writing; a data processor must notify the controller without delay and, where reasonably practicable, within 48 hours. Payment service providers also report material service interruptions and major security breaches to CBK every month.
What it means for your mobile app
Incident reporting is yours, but the clock starts when the incident is detected. Testing helps you find and fix issues before they become reportable events.
How Ostorlab helps
Ostorlab provides the technical evidence and reproduction steps for each finding, and retests after the fix, so the record is complete when you report.
What stays with you
Detection, the 24-hour, 72-hour and monthly reports, and communication with customers.
Summary of public CBK and ODPC texts, checked on 27 September 2026. Draft texts under consultation are not treated as requirements on this page. This page is not legal advice.
CBK rules, control by control
The controls the CBK and ODPC texts point to, how Ostorlab tests them in your app and its APIs, and the evidence you can keep.
| Control | How Ostorlab helps | Evidence you keep |
|---|---|---|
| Independent cyber threat test, at least once a yearGuidance Note 3.2 | AI-agent pentest of the app and its APIs, behind login, on the build you ship. Details | A working exploit you can replay for each AI-agent finding, and a coverage heatmap |
| Threat and vulnerability assessments and comprehensive penetration testsGuidance Note 3.2 | Mobile DAST runs the build and exercises the flows, with findings mapped to decompiled context, traffic, stack traces and screenshots. Details | Findings with decompiled source context, traffic, stack traces and screenshots |
| Quarterly scans, annual penetration test and bi-annual assessments for payment service providersPSP Guideline 3.2.5 | Intercepts traffic even with TLS pinning and tests authorization, token misuse and abuse such as enumeration and replay. Details | Request and response evidence for each API finding, and scan results per cycle |
| Safety, security and operational reliability of the payment serviceNPS Regulations, regulation 27 | Tests the app and API flows that make up the customer-facing service, including failure and error handling. | Test evidence you can attach to the annual system security audit report |
| Audit trail, records and reportingNPS Regulations, regulation 29 | Groups findings into tickets in the platform or in Jira and ServiceNow, and retests after the fix. | Ticket history and retest result for each finding |
| Strong authentication for customer data and transactionsGuidance Note 3.1(b)(v) | Logs in with one-time codes and tests MFA enforcement and step-up flows, and the API calls behind them. Details | Findings on login and step-up flows, with reproduction steps |
| Third-party and outsourcing riskGuidance Note 3.3; CBK/PG/16 | Lists the SDKs and native libraries in each release with their versions, and shows which backends the app and its SDKs talk to. Details | Component identity, version and location in the app bundle, per release |
| ICT risk framework and vulnerability identificationRisk Management Guidelines 7.3.4 | Mobile SAST analyses the binary with taint analysis across the app and its embedded SDKs. Details | Findings with decompiled source context, per build |
| Personal data on the device and in transitData Protection Act, section 41 | Looks for tokens and personal data in storage, caches, logs and screenshots, and checks transport protections. Details | File system evidence showing what was written, where and when |
| Reviewing and testing software to uncover vulnerabilitiesDP General Regulations 32(k) | Binary-based static analysis of APK, AAB and IPA files, in CI/CD on every build. Details | Scan results per build, with decompiled source context |
Ostorlab tests controls in the app and its APIs. SOC monitoring, incident detection and the reports to CBK, the Data Commissioner or the BS-SOC, business continuity and recovery, the annual system security audit opinion, governance and physical security stay with your teams.
CBK controls to test in your mobile app
A practical list for security and audit teams, based on the 2017 Guidance Note, the payment service provider guideline and the Data Protection Act 2019.
Yearly independent test
Put the mobile app and the APIs it calls in the scope of the annual independent cyber threat test, and test between audits on every release.
Audit and risk scope
Include the app and its third-party connections in the internal audit scope: threat and vulnerability assessments, comprehensive penetration tests, and evidence for the board.
Payment service cadence
If your group runs a payment service, plan quarterly vulnerability scans, an annual penetration test and bi-annual vulnerability assessments for critical cyber assets.
Authentication and sessions
Test login, one-time codes, step-up checks, timeouts and session invalidation, with the checks enforced on the server.
Third parties and SDKs
Keep a versioned list of the SDKs and backends in each release, and check whether an outsourcing arrangement needs CBK approval before it starts.
Data on the device
Look for tokens and personal data in storage, caches, logs and screenshots, and in the app package itself.
Data protection by design
Work through sections 41 and 42 for the app: what is collected, what is cached, how it is encrypted, and how you verify the safeguards.
Report and retest
Know the 24-hour CBK and 72-hour Data Commissioner clocks, keep the technical evidence, and retest after the fix.
A suggested list, not a CBK template. This is not legal advice.
The capabilities behind this page
Each one has its own page with the details.
- Mobile Agentic Deep ScanAI agents pentest the store build on every release, with a working exploit you can replay for each AI-agent finding.Learn more
- Authenticated testingTest login, one-time codes and step-up flows with your test accounts.Learn more
- API and backend testingIntercept app traffic even with TLS pinning, then test the APIs and backends behind accounts and payments.Learn more
- Mobile SASTBinary-based static analysis of APK, AAB and IPA files, with taint analysis across the app and its embedded SDKs.Learn more
- SCA and SBOMFind vulnerable dependencies, including statically compiled native libraries, and track their closure release after release.Learn more
- Mobile Shielding ScanTest root and jailbreak detection, anti-tampering and pinning at runtime, and see which protections held and which were bypassed.Learn more
- Bring your own AI keyRun AI-agent scans on your own AI provider key with a spend cap per scan, so usage follows your internal policies.Learn more
- On-premises scanningScan staging apps, APIs and repositories behind your firewall or VPN, on infrastructure you control.Learn more
Trusted by banks and fintechs, including
Sources
The official texts this page is based on, checked on 27 September 2026.
- National Payment System Act, No. 39 of 2011, and National Payment System Regulations, 2014The Act gives the Central Bank of Kenya oversight of the national payment system and the power to issue directives and guidelines. The 2014 Regulations require payment service providers to keep services safe, secure and reliable (regulation 27), maintain an audit trail and keep records for at least seven years (regulation 29(1)), report material service interruptions and major security breaches every month (regulation 29(2)(c)), and file an annual system security audit report by a reputable independent audit firm (regulation 29(3)(c))
- Risk Management Guidelines, January 2013Central Bank of Kenya. Section 7 covers ICT risk: board and senior management responsibilities, the ICT risk management framework, vulnerability identification with vulnerability scanners and penetration testing (7.3.4), risk assessment and mitigation (7.4), and the information security programme (7.5)
- Prudential Guidelines, 2013, including the Guideline on Outsourcing (CBK/PG/16)Central Bank of Kenya. CBK/PG/16 requires approval from CBK for material outsourcing, gives the provision of mobile financial services channels or technology as an example of material activity (4.1.4), and sets due diligence, monitoring and contract expectations. The institution remains responsible for outsourced activities (4.2)
- Guidance Note on Cybersecurity for the Banking Sector, August 2017Central Bank of Kenya, issued under section 33(4) of the Banking Act and applying to all institutions licensed under the Banking Act. Governance, an independent cyber threat test at least once a year, internal and external audit testing including comprehensive penetration tests, outsourcing, and incident reporting within 24 hours (sections 3.1 to 3.4 and Part IV)
- Guideline on Cybersecurity for Payment Service Providers, July 2019Central Bank of Kenya, issued under section 31(2)(b) of the National Payment System Act, 2011 and applying to payment service providers authorised under that Act. Quarterly vulnerability scans, annual penetration testing and bi-annual vulnerability assessments (3.2.5), outsourcing notifications 30 days in advance (3.4.2), and a 90-day transitional period (4.0)
- Data Protection Act, 2019Republic of Kenya, Act No. 24 of 2019, from the Office of the Data Protection Commissioner. Data protection by design or by default and the measures it requires (sections 41 and 42), breach notification within 72 hours (section 43), and the conditions for transferring personal data out of Kenya (sections 48 to 50)
- Data Protection (General) Regulations, 2021Office of the Data Protection Commissioner. The elements of data protection by design or by default, including assessing risks against the security of personal data, audit trails and event monitoring, and regularly reviewing and testing software to uncover vulnerabilities of the systems supporting the processing (regulation 32)
- Press release: Establishment of the Banking Sector Cyber Security Operations Centre (BS-SOC)Central Bank of Kenya, 22 September 2025. CBK says it has started aligning the 2017 and 2019 cybersecurity guidelines with the 2024 regulations on critical information infrastructure, that institutions must keep complying with both sets of requirements, and that cybersecurity incidents must be reported to the BS-SOC within the timelines in those regulations
Frequently asked questions
Straight answers on coverage, setup, and how results reach your team.
Can't find your answer? Book a demo or contact us.
Test your mobile banking app the way the CBK describes it
Start with a free scan of your app from the store, or book a demo to run logged-in tests of your app and APIs with our team.