The Central Bank of Bahrain requires every licensed financial institution that delivers services through digital or internet channels to perform penetration testing at least twice a year — in June and December — using qualified, certified, independent testers who must be changed at least every two years. The report for the June test is due to the CBB by 30 September; the report for the December test is due by 31 March. Each report must list the vulnerabilities found, the passed and failed tests, and the mitigation steps taken, and must be retained for five years. This is one of the most prescriptive penetration testing mandates in the Gulf — and the twice-yearly cadence is the single detail institutions most often get wrong. The exact paragraph depends on your licence: banks fall under OM-5.5, insurers under RM-9, investment firms under RM-9, and payment and ancillary providers under GR-12.2.
// 01 What does the CBB actually require for penetration testing?
The CBB requires licensees to perform penetration testing of their systems, applications and network devices at least twice a year, conducted each year in June and December, by qualified and independent testers, with the results reported to the CBB. The obligation is explicit rather than implied. Most compliance regimes leave the cadence to you — PCI DSS mandates testing but not the month; ISO 27001 makes it the expected evidence for Annex A 8.8 without naming it. The CBB fixes the frequency, the testing months, the reporting deadlines, the rotation period and the report contents, and then asks to see the outcome twice a year.
The phrasing is consistent across the Rulebook. In the module for payment and ancillary providers, GR-12.2.3 states that licensees "must perform penetration testing of their systems, applications, and network devices to verify the robustness of the security controls in place at least twice a year," and that "these tests must be conducted each year in June and December." The banking and investment modules carry the same twice-yearly requirement. If you have been running a single annual test, you have been meeting roughly half of the CBB's expectation.
// 02 Which CBB Rulebook paragraph applies to you?
The requirement does not sit in one place. The CBB rolled its cyber-security rules out volume by volume between 2019 and 2021, so the module name and paragraph numbers differ by licensee type even though the substance is aligned. Find your category below and cite that reference in your own compliance documentation — an assessor notices when you quote the paragraph that actually governs you.
| Licensee category | Module & section | Testing / reporting paragraphs |
|---|---|---|
| Conventional banks (Volume 1) | OM-5.5 Cyber Security Risk Management | Testing OM-5.5.28 · Reporting OM-5.5.54 |
| Islamic banks (Volume 2) | OM-5.5 (parallel text) | Testing OM-5.5.28 · Reporting OM-5.5.54 |
| Insurance licensees (Volume 3) | RM-9 Cyber Security Risk | Testing RM-9.1.15 · Reporting RM-9.1.16 |
| Investment business firms (Volume 4) | RM-9 Cyber Security Risk Management | Testing RM-9.1.28 · Reporting RM-9.1.60 |
| Payment & ancillary service providers (Volume 5) | GR-12.2 Cyber Security Risk Management | Testing GR-12.2.3 · Reporting GR-12.2.4 |
The common gating condition across every volume is the delivery of services through digital or internet channels. Category 1 and 2 investment firms are in scope, as are Category 3 firms that give financial advice digitally. A licensee with no digital service delivery may fall outside the requirement — but in 2026 that is an increasingly rare position, and the safer assumption for any customer-facing institution is that it applies.
// 03 When must testing happen, and when are the reports due?
Testing happens in June and December, and each cycle has its own submission deadline: the June test is reported by 30 September, and the December test is reported by 31 March. Read those pairs together and the real constraint is clear — you have roughly one quarter after each test to remediate what was found, document mitigation, and submit. That quarter is not slack; for any institution with a meaningful estate, a critical finding late in a testing month is a genuine race against the deadline.
Because there are two cycles, the CBB penetration testing obligation is a year-round programme, not a single annual event. The reporting paragraph for payment and ancillary providers, GR-12.2.4, sets it out directly: reports "must be submitted to CBB before 30th September for the tests as at 30th June and 31st March for the tests as at 31st December." The banking and investment modules carry the same two deadlines.
| Cycle | Test month | Report due | Sensible booking window |
|---|---|---|---|
| First half | June | Before 30 September | Scope and procure in Q1 (Feb–Mar) |
| Second half | December | Before 31 March | Scope and procure in Q3–Q4 (Sep–Oct) |
Superseded 31 August dates
Earlier, still-downloadable versions of the modules used a two-month reporting window — 31 August for the June test, 28 February for the December test. Those are superseded. The current cross-volume deadlines are 30 September and 31 March. If a template or a prior report cites 31 August, it is quoting an outdated version.
Treating June as the whole obligation
Many institutions plan around the June test and its September deadline and forget the December cycle entirely, then scramble in Q1. Both tests are mandatory. Put both cycles on the compliance calendar at the start of the year.
// 04 Why does the CBB make you change testing providers?
The independent third-party tester must be changed at least every two years. For payment and ancillary providers the Rulebook makes this mandatory — GR-12.2.3(d) requires tests to "be performed by external, independent third parties which must be changed at least every two years." For banks and investment firms the equivalent paragraphs use "should" rather than "must," and refer to internal and external independent third parties. Either way, the same tester returning indefinitely is not the intent.
The purpose is methodological, not commercial. Testers develop habits: a firm returning to the same environment year after year tends to re-run its previous test plan, confirm that old issues stay closed, and stop probing the areas it has already decided are fine. Rotation forces a fresh threat model over the same estate, and in practice a first engagement by a new provider on a mature environment almost always surfaces something the incumbent had stopped looking at. The operational implication is simple: track your rotation year on the compliance calendar so a required change does not surprise you in a testing month, when you would be selecting on availability rather than capability.
// 05 What must the report to the CBB contain, and how long must you keep it?
Each report must set out the vulnerabilities identified, a full list of passed and failed tests, and the steps taken to mitigate the risks identified — and the licensee must retain the report and its remediation record for five years. The structural mistake institutions make is submitting the tester's raw technical report unchanged. A penetration test report is written for engineers who need to reproduce and fix issues; the CBB submission is a supervisory document that must demonstrate control. The second is assembled from the first.
1 — Scope statement: What was tested, expressed as systems and business functions rather than IP ranges alone, and anything material that was excluded with the documented reason.
2 — Tester credentials and independence: Who performed the work, their certifications, confirmation of independence from the systems tested, and the rotation position — which cycle this provider is in.
3 — Test matrix (passed / failed): Each test performed against its result. This is the explicit pass/fail record the Rulebook asks for, and it is the section most often missing from submissions.
4 — Vulnerabilities with severity: Each finding with a severity rating and business-risk context, not CVSS alone.
5 — Mitigation steps: For every failure, what was done, when, and how closure was verified. Retest evidence carries substantially more weight than a remediation assertion.
6 — Open items with dated plans: Anything unresolved at submission, with an owner and a closure date. Omission reads far worse to a supervisor than disclosure.
// 06 What methodology and tester qualifications does the CBB expect?
The Rulebook is specific about how the test is run. It requires an internationally recognised risk-based methodology "such as NIST and OWASP," both Grey Box and Black Box testing, and work "conducted by qualified and experienced security professionals who are certified in providing penetration testing services." Testing must be performed by independent third parties changed at least every two years, and run against the production environment or a non-production exact replica.
Independence deserves emphasis. Internal security teams are frequently capable of excellent work, but a test of systems your own team designed, deployed and maintains does not satisfy an independence expectation regardless of technical quality. Where institutions run internal testing programmes, those sit alongside the required independent test rather than replacing it. When evaluating providers, the questions worth asking are which named individuals will perform the work and what they are certified in; whether the methodology maps to NIST SP 800-115, the OWASP Testing Guide or PTES; whether both Grey Box and Black Box perspectives are covered; whether retesting is included (and priced in — see our penetration testing cost guide); and whether the provider has produced CBB submissions before. Our own approach is set out in the network penetration testing and web application testing methodologies.
// 07 What comes up most often in Bahrain financial-sector testing?
Across financial-sector engagements in the Gulf, the recurring issues cluster in a small number of predictable places. None are exotic; they persist because they sit in the seams between teams.
Broken object-level authorisation in customer-facing APIs
Mobile and internet banking back-ends that authenticate the user correctly but fail to verify that the requested account or transaction belongs to them. Scanners rarely catch it because every request returns a valid, well-formed response.
Corporate network reachable from payment infrastructure
Segmentation designed correctly at build, then eroded by years of firewall exceptions for monitoring, backup and vendor access that were never withdrawn.
Vendor integrations with excessive standing privilege
Service accounts issued to integration partners with broad permissions and no expiry, often predating the current security team and rarely reviewed.
Production data in test environments
Unmasked customer records in UAT for realistic testing. A finding in its own right, and separately a personal-data exposure under Bahrain's Personal Data Protection Law.
The last one is worth flagging to legal as well as security: using live customer data in a test environment can be a data-protection issue independent of whether anyone exploits it.
// 08 Frequently asked questions
Does the CBB require penetration testing?
Yes. Licensed institutions that deliver services through digital or internet channels must perform penetration testing at least twice a year, in June and December, and report the results to the CBB. The obligation is stated directly in the relevant module for each licensee category.
How often does the CBB require penetration testing?
At least twice a year. The Rulebook requires tests to be conducted each year in June and December — stronger than the annual testing many other frameworks expect, and the point institutions most often get wrong.
When are CBB penetration testing reports due?
The June test is reported before 30 September; the December test is reported before 31 March. Older superseded versions cited 31 August — the current deadline is 30 September.
How often must we change penetration testing provider?
At least every two years. For payment and ancillary providers this is mandatory ("must"); for banks and investment firms it is expressed as "should." The intent is to avoid the methodological blind spots that develop when one tester repeats the same plan.
What must the report contain?
The vulnerabilities identified, a full list of passed and failed tests, and the mitigation steps taken. The report and its remediation record must be retained for five years.
What methodology is required?
An internationally recognised risk-based methodology such as NIST or OWASP, covering both Grey Box and Black Box testing, run against production or an exact replica by certified, independent professionals.
// 09 Sources
- CBB Rulebook, Volume 5 (Specialised Licensees), Ancillary Service Providers — General Requirements Module, GR-12.2.3 (penetration testing) and GR-12.2.4 (reporting) — Central Bank of Bahrain, July 2021. Verified against the CBB-hosted module PDF.
- CBB Rulebook, Volume 1 (Conventional Banks), Operational Risk Module, OM-5.5 "Cyber Security Risk Management" — testing OM-5.5.28, reporting OM-5.5.54.
- CBB Rulebook, Volume 3 (Insurance), Risk Management Module, RM-9 "Cyber Security Risk" — testing RM-9.1.15, reporting RM-9.1.16 (introduced April 2019).
- CBB Rulebook, Volume 4 (Investment Business), Risk Management Module, RM-9 — testing RM-9.1.28, reporting RM-9.1.60.
- CBB Appendix — Cyber Security Control Guidelines (NIST-based), October 2024.
- Methodology references cited in the Rulebook: NIST SP 800-115, OWASP Testing Guide, PTES.
Paragraph references reflect the CBB Rulebook as published on cbb.gov.bh. The Rulebook is periodically amended; confirm the live paragraph on the CBB / Thomson Reuters Rulebook portal for your specific licence before relying on it for a submission.