CBB cyber security rules: test your mobile banking app on every release, and for the twice-yearly test.
The CBB Rulebook's Operational Risk Management module asks conventional banks to assess apps, external systems and third-party connections, and to run penetration tests of systems, applications and network devices at least twice a year, with grey box and black box coverage. The e-banking chapter sets strong customer authentication rules, and the PDPL governs customer data. Ostorlab tests your app and the APIs behind it, behind login, on every release.
- Tests the app and the APIs it calls, including third-party connections, on the build your customers download
- Logs in with your test accounts and checks strong customer authentication, one-time codes and step-up flows
- 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
- Conventional bank licensees in Bahrain, including branches of foreign banks, under CBB Rulebook Volume 1
- Legal basis
- CBB Directive in the Operational Risk Management module, issued under Article 38 of the Central Bank of Bahrain and Financial Institutions Law 2006; PDPL is Law No. 30 of 2018
- Focus
- Technical assessments, penetration testing twice a year, e-banking authentication, continuity and personal data
- Main reference
- CBB Rulebook Volume 1, OM module: OM-5.5 Cyber Security Risk Management, updated May 2026
The CBB texts behind your mobile channel
The cyber security section sits inside the Operational Risk Management module, alongside the e-banking and business continuity chapters. The dates below are for the texts cited on this page.
- 12 July 2018
Personal Data Protection Law
Law No. 30 of 2018 is promulgated. It requires technical and organisational measures for personal data, confidentiality, a data protection guardian and rules for transfers outside the Kingdom, and comes into force in 2019.
- January 2020
Revised OM module
The CBB revises the whole Operational Risk Management module for alignment with the Basel Committee principles. The board oversight, secure authentication and other systems and controls rules for e-banking and electronic funds transfer are in this structure.
- July 2021
New cyber security section
OM-5.5 Cyber Security Risk Management is added as a new enhanced section, together with Appendix C, the NIST Cybersecurity Framework-based control guidelines. Penetration testing is set at least twice a year.
- April 2022
Incident reporting amended
The rules on reporting cyber security incidents to the CBB are amended: contact the CBB within one hour, Section A of the incident report within two hours, and Section B within 10 calendar days.
- 5 March 2026
Payment services consultation
The consultation on a proposed Payment Service Requirements Module closes. It is a proposal and not in force; the e-banking authentication rules in OM-3 apply in the meantime.
- May 2026
OM module update
The CBB updates the whole module, including OM-5.5, to align with the new Financial Crime module. The paragraph on the board cyber security committee (OM-5.5.9) is amended.
- Every year
Continuity testing
Business continuity plans must be tested at least annually, including alternate sites, vendor recovery services and the recovery of vital records.
The CBB rules, 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. Quotations are from the English CBB Rulebook.
- CBB Rulebook Volume 1, OM-5.5.25 and OM-5.5.26
Assess apps, external systems and third-party connections
What the text says
Conduct regular technical assessments to identify potential security vulnerabilities in systems, applications and network devices. The assessments must be comprehensive and cover internal technology, external technology and connections with third parties. Preferably, assessments of internal technology are conducted monthly, and assessments of external public-facing services and systems weekly or more frequently. External technology refers to public-facing technology such as websites, apps and external servers; connections with third parties include any API or other connections with fintech companies, technology providers and outsourcing service providers.
What it means for your mobile app
The text names apps in its definition of external technology, so the mobile app and the APIs it calls fall inside the assessment scope, and public-facing systems carry the tightest cadence.
How Ostorlab helps
Mobile Agentic Deep Scan tests the store build and the APIs behind it on every release, with a working exploit you can replay for each AI-agent finding. It follows the app into third-party connections by testing the services the app and its SDKs call.
What stays with you
The assessment programme, scans of internal servers and network devices, and the risk treatment plan for residual risks.
- CBB Rulebook Volume 1, OM-5.5.28 and OM-5.5.61
Penetration test at least twice a year
What the text says
All licensees must perform penetration testing of their systems, applications and network devices to verify the robustness of security controls at least twice a year. The tests must simulate real world cyber attacks, follow a risk-based internationally recognised methodology such as NIST or OWASP, include both grey box and black box testing, be conducted by qualified and experienced security professionals who are certified in providing penetration testing services, be performed by internal and external independent third parties which should be changed at least every two years, and run on the production environment or on non-production exact replicas. The report and the mitigation steps must be kept for five years and provided to the CBB within two months following the end of the month in which the testing took place.
What it means for your mobile app
Twice a year is the floor, not the ceiling. Mobile releases ship far more often than that, and the app and the APIs it calls are named in the scope.
How Ostorlab helps
Ostorlab runs on every release between the twice-yearly tests, on the build customers download, and covers logged-in grey box style testing with your test accounts. It gives you an exploit, or request and response evidence, for each finding that needs to go into the report.
What stays with you
Choosing and rotating the independent testers, the formal methodology, the report and the submission to the CBB.
- CBB Rulebook Volume 1, OM-5.5.29 and OM-5.5.30
Red teaming when the CBB requires it
What the text says
The CBB may require additional red teaming exercises to be performed as needed. A red team is a group of ethical hackers with varying backgrounds that tests the organisation's blue team response activity; it may attack cyber, social and physical fronts, and the goal is to test detection and response capabilities rather than to find as many vulnerabilities as possible. Where licensees have been required to conduct a red teaming exercise, the results must be provided to the CBB within one month of completion, together with a comprehensive plan to address any observed weaknesses.
What it means for your mobile app
Red teaming is an institution-wide exercise, not an app test. It goes better when known app and API issues are already closed.
How Ostorlab helps
Ostorlab does not run red teaming and does not replace it. It helps you close known app and API issues before the exercise and retest the app and API items of the remediation plan afterwards.
What stays with you
Scoping and running the exercise, the social and physical fronts, and the report to the CBB within one month.
- CBB Rulebook Volume 1, OM-5.5.18(d), (h) and (i)
Test rigorously during development and after deployment
What the text says
Preventive measures must include rigorous security testing at the software development stage as well as after deployment to limit the number of vulnerabilities, and the creation of a list of whitelisted applications and application components, such as libraries and configuration files, that are authorised to be present or active on the organisation's systems. Mobile device management solutions and BYOD security policies must secure all mobile devices with any access to bank systems, applications and networks, through measures such as encryption, remote wipe and password enforcement.
What it means for your mobile app
Every app release is a change to the bank's external technology. The text asks for testing both before deployment and after, on the build customers actually use.
How Ostorlab helps
Ostorlab runs automated scans from your CI/CD pipeline on every build and monitors store releases without manual triggers. Mobile SAST works on the APK, AAB or IPA, with no source code needed. The SCA inventory is the authorised component list, evidence first.
What stays with you
Secure development policy, MDM and BYOD controls, and the authorised component list itself.
- CBB Rulebook Volume 1, OM-5.5.15(d), OM-5.5.27 and OM-5.5.4(e)
Manage vulnerabilities and patches with deadlines
What the text says
Have vulnerability and patch management processes, including remediation processes, so that identified vulnerabilities are addressed and security patches are applied within a timeframe commensurate with the risks each vulnerability poses. The cyber security policy must cover vulnerability management, secure application development and secure change management, and the board should receive the results of penetration testing exercises in its cyber security reporting.
Source:CBB Rulebook Volume 1, OM-5.5.15(d), OM-5.5.27 and OM-5.5.4(e)
What it means for your mobile app
The libraries and SDKs inside your app are software you ship. Each one needs a known version, a severity when a vulnerability appears, and a fix deadline you can prove.
How Ostorlab helps
SCA fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Findings are rated critical, high, medium or low, tracked as tickets in the platform or in Jira and ServiceNow, and retested once the fix ships.
What stays with you
Patching servers and infrastructure, vendor maintenance contracts, and risk acceptance decisions.
- CBB Rulebook Volume 1, OM-3.2.1, OM-3.2.2, OM-3.2.4 and OM-3.2.6
Use strong customer authentication for e-banking and EFTS
What the text says
Licensees must take appropriate measures to authenticate the identity and authorisation of customers, and use predefined transaction authentication methods that promote non-repudiation and establish accountability for transactions, with detailed procedures to identify the person originating electronic funds transfer transactions and for call backs where appropriate. The strong customer authentication process must ensure that no information on any of its elements can be derived from the disclosure of the authentication code, that a new code cannot be generated from knowledge of any other code previously generated, and that the code cannot be forged. Customer authentication must use the three elements of knowledge, possession and inherence.
Source:CBB Rulebook Volume 1, OM-3.2.1, OM-3.2.2, OM-3.2.4 and OM-3.2.6
What it means for your mobile app
The app is where the factors are collected, but enforcement has to sit on the server, including when the app or an attacker skips a step.
How Ostorlab helps
Authenticated testing covers login and logout, token refresh, timeouts, session invalidation and strong customer authentication, including step-up flows and how attackers try to manipulate them, together with the API calls behind them.
What stays with you
Choosing authentication methods and thresholds, and the call back procedures for electronic funds transfers.
- CBB Rulebook Volume 1, OM-3.1.2(b), (e) and (f); OM-3.3.1 to OM-3.3.6
Test your APIs and control access to e-banking systems
What the text says
Policies and procedures for e-banking and electronic funds transfer must cover the testing of application program interfaces, authentication of users, protection of customer data confidentiality consistent with the Personal Data Protection Law, and enhanced fraud monitoring of movements in customers' accounts using tools and measures such as limits on value, volume and velocity. Licensees must also ensure segregation of duties, proper authorisation controls and access privileges, data integrity, clear audit trails and log retention for e-banking and EFTS systems, databases and applications.
Source:CBB Rulebook Volume 1, OM-3.1.2(b), (e) and (f); OM-3.3.1 to OM-3.3.6
What it means for your mobile app
The APIs behind the app carry the same data as the app. The text asks for them to be tested and for access to be controlled, with the fraud limits enforced on the server.
How Ostorlab helps
Ostorlab intercepts the app's traffic, even with TLS pinning, and tests the APIs for broken authorization (BOLA, BFLA, IDOR), misuse of tokens and sessions, and abuse such as enumeration, replay and automation, with request and response evidence for each finding.
What stays with you
Fraud monitoring rules and limits, server patching, and the audit trail and log retention.
- CBB Rulebook Volume 1, OM-4.2.1, OM-4.5.4, OM-4.9.2, OM-3.3.9 and OM-3.3.10
Test business continuity for the mobile channel
What the text says
The business continuity plan must address data back-up and recovery, continuation of critical systems and activities, alternate communication arrangements, and prompt customer access to funds in the event of a disruption. Licensees must establish recovery time objectives, recovery point objectives and the maximum tolerable period of disruption for critical functions, approved by senior management, and must test their business continuity plans at least annually, including activation of alternate sites, recovery services provided by vendors and the recovery of vital records. E-banking systems must have effective capacity, continuity and contingency planning, and incident response plans that cover internal and external attacks.
Source:CBB Rulebook Volume 1, OM-4.2.1, OM-4.5.4, OM-4.9.2, OM-3.3.9 and OM-3.3.10
What it means for your mobile app
The app and its APIs are part of the critical service customers use to reach their funds. Their behaviour when a dependency fails is testable.
How Ostorlab helps
Ostorlab tests the app and its APIs for behaviours that break availability and data integrity, including error handling, session behaviour and business logic limits, on staging or production-like environments, with evidence you can add to the continuity plan review.
What stays with you
The business continuity plan itself, alternate sites, back-ups, the RTO and RPO approvals, and the annual test.
- Personal Data Protection Law (Law No. 30 of 2018), Articles 8, 9, 12 and 13
Protect personal data under the PDPL
What the text says
The Data Controller must implement appropriate technical and organisational measures to protect personal data against accidental or unauthorised destruction, accidental loss, alteration or disclosure, and against unauthorised access or any other unauthorised forms of processing, taking into account the latest technological security measures, the cost and the risks involved. The measures must be recorded and accessible to the relevant parties. The controller must choose a processor that provides sufficient safeguards and bind the processing to a written contract with equivalent security and confidentiality obligations. Personal data must not be disclosed without consent, and transfers outside the Kingdom are prohibited unless the destination provides adequate protection, the Authority authorises the transfer, or one of the law's exemptions applies.
Source:Personal Data Protection Law (Law No. 30 of 2018), Articles 8, 9, 12 and 13
What it means for your mobile app
The app stores and transmits personal data, and its SDKs often send it to third-party backends. Those flows need the same technical and organisational measures and the same transfer discipline.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, checks transport protections, and maps which third-party backends the app and its SDKs exchange data with.
What stays with you
The data protection programme, the data protection guardian, the processing records, and transfer authorisations.
- CBB Rulebook Volume 1, OM-5.5.57 and OM-5.5.58
Report serious cyber incidents to the CBB within one hour
What the text says
On occurrence or detection of a cyber security incident, whether internal or external, that compromises customer information or disrupts critical services affecting operations, licensees must contact the CBB immediately, within one hour, and submit Section A of the Cyber Security Incident Report within two hours. Section B follows within 10 calendar days of the occurrence, with the full root cause analysis, the impact on business operations and customers, and all measures taken to stop the attack and prevent recurrence, plus a weekly progress update until the incident is fully resolved.
What it means for your mobile app
Detection to notification is a one-hour race. Knowing exactly what the attacker could do in your app and APIs is what the root cause analysis section of the report needs.
How Ostorlab helps
Ostorlab does not report incidents to the CBB and does not act as your SOC. It gives you exploit and request and response evidence for your app and API findings, which supports the root cause analysis in the report.
What stays with you
The incident response process, the one-hour call to the CBB, the report sections and the weekly updates.
Summary of public CBB texts, checked on 27 September 2026. The Operational Risk Management module was last updated in May 2026. This page is not legal advice.
CBB rules, control by control
The controls the CBB 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 |
|---|---|---|
| Technical assessments of apps, external systems and third-party connectionsOM-5.5.25, 5.5.26 | AI-agent pentest of the app and its APIs, behind login, on the build you ship, including the services the app and its SDKs call. Details | A working exploit you can replay for each AI-agent finding, and a coverage heatmap |
| Penetration testing at least twice a year, grey box and black boxOM-5.5.28 | AI-agent pentest of the app and its APIs, behind login, together with analysis of the interactions between the app, its SDKs and the backend. Details | A working exploit or a validated request for each finding in the penetration testing report |
| Security testing at the development stage and after deploymentOM-5.5.18(d) | Mobile SAST and DAST in CI/CD on every build, and monitoring of store releases. Details | Scan results per build and per store release |
| Authorised application components and librariesOM-5.5.18(h) | 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 |
| Vulnerability and patch deadlinesOM-5.5.27 | Fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Details | Mapped vulnerabilities with upgrade or replace recommendations, and closure tracked across releases |
| Strong customer authentication and transaction authenticationOM-3.2.4, 3.2.6 | Logs in with one-time codes and tests the enforcement of customer authentication, step-up flows and the API calls behind them. Details | Findings on login and step-up flows, with reproduction steps |
| API testing and authorisation controlsOM-3.1.2(b), OM-3.3.1, 3.3.2 | 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 |
| Customer data confidentiality in the app and in transitPDPL Art. 8, 9; OM-3.3.6 | 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 |
| Credentials and keys in the app packageOM-3.3.2; PDPL Art. 8 | Finds API keys, tokens and credentials in the app package and validates whether they work. Details | Validated secrets, with the permissions and services they expose |
| Recovery preparation and incident evidenceOM-4.9.2; OM-5.5.57 | Retests after each fix, so the state of the app and APIs is documented before a continuity test or an incident post mortem. | Ticket history and retest results you can attach to the continuity review or incident report |
Ostorlab tests controls in the app and its APIs. SOC monitoring, incident reporting to the CBB, red teaming, business continuity, back-ups and recovery, governance and physical security stay with your teams.
CBB controls to test in your mobile app
A practical list for security and operational risk teams, based on the OM module and the Personal Data Protection Law.
Assessment scope
Put the mobile app, its APIs and third-party connections in the scope of your technical assessments, with the tighter cadence the text gives to public-facing systems.
Twice-yearly penetration test
Plan two penetration tests a year with grey box and black box coverage, certified testers, and a fresh independent provider at least every two years.
Report to the CBB
Keep each penetration testing report and its mitigation steps for five years, and submit the report within two months after the month of the test.
CI/CD and store builds
Run automated security testing on every build and scan the published store release, not only the version you tested last quarter.
Components and deadlines
Keep a versioned list of the SDKs and libraries in each release, and set remediation deadlines by severity.
Authentication
Verify strong customer authentication and transaction authentication on the server, including one-time codes, step-up flows and the three elements of knowledge, possession and inherence.
Data on the device
Check the app package for keys and credentials, look for personal data in storage, caches, logs and screenshots, and review transfers outside the Kingdom against the PDPL.
Incident and continuity rehearsal
Rehearse the one-hour CBB call and the incident report, keep the incident log, and test the business continuity plan at least annually.
A suggested list, not a CBB 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.
- CBB Rulebook Volume 1: Conventional Banks, OM Operational Risk ManagementCentral Bank of Bahrain, Part A Business Standards. The OM module was revised in January 2020 and last updated in May 2026. It contains the e-banking, business continuity and cyber security chapters for conventional bank licensees
- OM-5.5 Cyber Security Risk ManagementCBB Rulebook Volume 1. Added as a new enhanced section in July 2021. Technical assessments (OM-5.5.25, OM-5.5.26), vulnerability and patch management (OM-5.5.27), penetration testing at least twice a year (OM-5.5.28), red teaming (OM-5.5.29, OM-5.5.30), incident reporting (OM-5.5.57, OM-5.5.58) and the five-year retention and two-month submission of the penetration testing report (OM-5.5.61)
- OM-3 Electronic Money and Electronic Banking ActivitiesCBB Rulebook Volume 1. Board oversight, application program interface testing, data confidentiality consistent with the PDPL and fraud monitoring (OM-3.1.2); secure authentication including strong customer authentication and the three authentication elements (OM-3.2); segregation of duties, access privileges, audit trails and continuity for e-banking and electronic funds transfer systems (OM-3.3)
- OM-4 Business Continuity ManagementCBB Rulebook Volume 1. Business continuity plan contents (OM-4.2.1), recovery time objectives, recovery point objectives and maximum tolerable period of disruption (OM-4.5.4), and testing of the business continuity plan at least annually (OM-4.9.2)
- Appendix C: Cyber Security Control GuidelinesCBB Rulebook Volume 1. Added in July 2021. Control guidelines based on the NIST Cybersecurity Framework, grouped into Identify, Protect, Detect, Respond and Recover, used as a reference for the cyber security strategy and policy
- Personal Data Protection Law (Law No. 30 of 2018)Kingdom of Bahrain, promulgated on 12 July 2018, in force since 2019. Security of processing (Article 8), confidentiality (Article 9), the data protection guardian (Article 10) and transfers outside the Kingdom (Articles 12 and 13). The English text published by the Personal Data Protection Authority is a translation; the Arabic text prevails
- CBB consultations: Proposed Payment Service Requirements ModuleCentral Bank of Bahrain, consultation closed on 5 March 2026. A proposal, not in force, covering a new framework for payment services. The e-banking authentication rules in the OM module apply in the meantime
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.
Assess your mobile banking app the way the CBB 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.