Security testing rules in Bahrain.

Module OM is a CBB Directive issued under Article 38 of the CBB Law 2006. The testing paragraphs use ‘must’.

“This Module contains the CBB's Directive, as amended from time to time, relating to Operational Risk Management and is issued under the powers available to the CBB under Article 38 of the Central Bank of Bahrain and Financial Institutions Law 2006 ('CBB Law').”

OM-A.1.3; OM-5.5.28

Bahraini conventional bank licensees and branches of foreign bank licensees. OM-5.5.28 says ‘All licensees’. Volume 2 applies the same text to Islamic bank licensees.

“Bahraini conventional bank licensees must comply with all requirements included in this Module.”

OM-B.1.1; OM-B.1.3; OM-5.5.28

Penetration testing at least twice a year. Red teaming only when CBB requires it. The reporting example in OM-5.5.61 assumes June and December tests.

“All 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.”

OM-5.5.28; OM-5.5.29; OM-5.5.61

Tests must simulate real world attacks, but no rule ties penetration test or red team scenarios to threat intelligence. Threat intelligence ‘should’ update cyber incident scenario tests, and banks ‘should’ subscribe to a threat intelligence service (OM-5.5.20).

“Licensees should regularly use threat intelligence to update the scenarios so that they remain current and relevant.”

OM-5.5.37; OM-5.5.20; OM-5.5.28

Testers must be qualified, experienced and certified in penetration testing. Independent testers should be changed at least every two years. No certification body or scheme (such as CREST) is named.

“(c) Be conducted by qualified and experienced security professionals who are certified in providing penetration testing services; (d) Be performed by internal and external independent third parties which should be changed at least every two years”

OM-5.5.28(c), (d)

The text names ‘internal and external independent third parties’ and does not define ‘internal’. Read literally, both internal and external testers take part, subject to independence and two-year rotation. The CBB rule for payment and other ancillary service providers (Vol. 5, GR-12.2.3(d)) instead says ‘external, independent third parties’.

“(d) Be performed by internal and external independent third parties which should be changed at least every two years”

OM-5.5.28(d)

A red team required by CBB may attack people. OM-5.5.55 also gives testing employee reactions to simulated attacks as an example of training.

“The red team may attack 3 fronts: cyber, social (attack on people's behavior) and physical (attack on an organization's physical facility and or 3rd party premises).”

OM-5.5.29; OM-5.5.55

A red team required by CBB may attack the bank’s physical facility.

“The red team may attack 3 fronts: cyber, social (attack on people's behavior) and physical (attack on an organization's physical facility and or 3rd party premises).”

OM-5.5.29

Vulnerability assessments must cover connections with third parties, defined as API or other connections with fintechs, technology providers and outsourcing providers (OM-5.5.26). A red team may attack third-party premises (OM-5.5.29). The penetration test rule itself does not name third parties. No pooled tests.

“The vulnerability assessments must be comprehensive and cover internal technology, external technology, and connections with third parties.”

OM-5.5.25; OM-5.5.26; OM-5.5.29

Appendix C lists a baseline configuration for ‘information technology/industrial control systems’ as a control. No testing provision covers OT.

Retail banks must hold PCI-DSS certification (OM-5.1.1) and cards must be EMV compliant (OM-5.2.1). The testing paragraphs do not name payment systems, SWIFT or card infrastructure.

Threat assessments must consider cloud attack vectors (OM-5.5.22(b)) and cloud outsourcing needs CBB notification (OM-2.1.7(ii)). No testing provision covers cloud or SaaS.

Branches of foreign banks may rely on head office or regional office functions with CBB approval and a gap analysis. Nothing addresses multi-jurisdiction tests or recognition of tests run abroad.

“Branches of foreign bank licensees must be governed under a framework of cyber security risk management policies which ensure that an adequate level of oversight is exercised by the regional office or head office.”

OM-5.5.6; OM-B.1.3; OM-B.1.5; OM-B.1.6

OM-5.5.29 says the red team tests the blue team’s response. OM-5.5.50 requires an exercise program (attack simulations, war games, table top). Neither mentions purple teaming or replay.

Red team results go to CBB within one month with a plan to fix weaknesses. Penetration test reports must record mitigation steps. Vulnerabilities must be fixed on a risk-based timeline (OM-5.5.27). No fixed deadline and no retest rule.

“Where licensees have been required to conduct a red teaming exercise the results of such an exercise must be provided to CBB within one month of the completion of the exercise together with a comprehensive plan to address any observed weaknesses.”

OM-5.5.30; OM-5.5.61; OM-5.5.27

CBB receives every penetration test report within two months of the test month, and red team results within one month. CBB can order red teaming. CBB does not lead tests or accredit testers.

“must be provided to CBB within two months following the end of the month where the testing took place, i.e. for a June test, the report must be submitted at the latest by 31st August and for a December test, by 28th February.”

OM-5.5.61; OM-5.5.29; OM-5.5.30

OM-5.5.44 lists incidents ‘detected and responded via automation’ as a metric. Nothing on automated or AI-driven testing, or on testing AI systems.

Rulebook requirement using ‘must’. In Volume 3, failure to keep adequate systems and controls breaches a licensing condition (RM-B.1.8).

“All licensees must perform penetration testing of their systems, applications, and network devices to verify the robustness of the security controls in place at least once a year.”

Vol. 3 and Vol. 4 RM-9.1.29; Vol. 3 RM-B.1.8

Volume 3: Bahraini and overseas insurance firms and brokers, and insurance exchange operators; not insurance consultants, managers or appointed representatives (RM-B.1.6). Volume 4: Category 1 and Category 2 investment firms only; Category 3 firms are exempt from Module RM except RM-7 and RM-8 (RM-B.1.2).

“the contents of this Module apply to Bahraini insurance firms and Bahraini insurance brokers on a consolidated basis, and to overseas insurance firms and overseas insurance brokers with respect to their operations either booked in or undertaken from Bahrain.”

Vol. 3 RM-B.1.1, RM-B.1.5, RM-B.1.6; Vol. 4 RM-B.1.1, RM-B.1.2

At least once a year, conducted in June, report to CBB before September 30. No red team clause.

“The tests referred to in Paragraph RM-9.1.29 must be conducted each year in June and the report on such testing must be submitted to the CBB before 30th September.”

RM-9.1.29; RM-9.1.31

Same wording as Volume 1: threat intelligence ‘should’ update incident scenario tests; subscription to a threat intelligence service ‘should’ be taken (RM-9.1.21). Not tied to penetration test design.

“Licensees should regularly use threat intelligence to update the scenarios so that they remain current and relevant.”

RM-9.1.38; RM-9.1.21

Certified, qualified testers; independent testers rotated at least every two years. No named scheme.

“(c) Be conducted by qualified and experienced security professionals who are certified in providing penetration testing services; (d) Be performed by internal and external independent third parties who are rotated out at least every two years”

RM-9.1.29(c), (d)

Same ‘internal and external independent third parties’ wording as Volume 1, with two-year rotation. ‘Internal’ is not defined.

“(d) Be performed by internal and external independent third parties who are rotated out at least every two years”

RM-9.1.29(d)

Only as an example of staff training. No red team clause.

“The licensee must ensure that all employees receive adequate training on a regular basis, in relation to cyber security and the threats they could encounter, such as through testing employee reactions to simulated cyber-attack scenarios.”

RM-9.1.56

Physical access appears only as an attack vector to consider in threat assessment (RM-9.1.23(b)). No physical testing provision.

Vulnerability assessments must cover connections with third parties. CBB may also require additional third-party security reviews (RM-9.1.30).

“The vulnerability assessments must be comprehensive and cover internal technology, external technology, and connections with third parties.”

RM-9.1.26; RM-9.1.27; RM-9.1.30

Appendix A mentions industrial control system configuration baselines only.

No testing provision names payment systems, SWIFT or card infrastructure.

Cloud appears as a threat vector (RM-9.1.23(b)) and in outsourcing rules. No testing provision.

Volume 3 applies on a consolidated basis, including branches and subsidiaries outside Bahrain (RM-B.1.4). Volume 4 requires the same or equivalent provisions at branches outside Bahrain (RM-B.2.1). Nothing on recognition of foreign tests.

“Bahraini investment firm licensees must ensure that, as a minimum, the same or equivalent provisions of this Module apply to their branches, whether located inside or outside the Kingdom of Bahrain”

Vol. 3 RM-B.1.1, RM-B.1.4; Vol. 4 RM-B.2.1

RM-9.1.51 requires an exercise program (attack simulations, war games, table top). No purple teaming or replay.

Reports must list passed and failed tests and mitigation steps. Vulnerability remediation processes required (RM-9.1.28). No deadline, no retest rule.

“The penetration testing reports must include the vulnerabilities identified and a full list of 'passed' tests and 'failed' tests together with the steps taken to mitigate the risks identified.”

RM-9.1.31; RM-9.1.28; RM-9.1.61

Reports go to CBB before September 30 each year. CBB may require additional third-party security reviews.

“CBB may require additional third-party security reviews to be performed as needed.”

RM-9.1.31; RM-9.1.30

Only an incident metric on automation (RM-9.1.45 list). Nothing on automated or AI-driven testing.

Mandatory for public and private CNI entities; other entities are encouraged to follow it. The document still carries a ‘Draft v 0.2’ label.

“Following the document's controls is mandatory for the private and public entities being part of the Kingdom's CNI.”

Introduction, p. 4

Public and private entities in the CNI sectors. NCSC lists them as Gas, Electricity and Oil; Financial Services; ICT; Healthcare; Government Services; Critical Industry; Transportation.

“This document's controls target all private and public entities of all the critical sectors in the Kingdom's Critical National Infrastructure (CNI).”

Introduction, p. 4; NCSC CNI Cybersecurity Controls web page

Penetration testing annually; vulnerability assessment at least every three months (Control 3.3.1) and before new systems go live (Control 3.3.2).

“After vulnerability assessment, penetration testing must be performed annually and conducted either manually or automatically using software applications.”

Control 3.3.4; Control 3.3.1

No provision on threat intelligence.

No tester qualification, certification or independence rule. Senior management must approve the test scope.

Control 3.3.4 says the entity should plan ‘whether external or internal’ testing, which describes the test perspective, not who tests.

Simulated phishing is given as an example way to assess the awareness program.

“For example, the entity may conduct social engineering tests for employees through simulated and organized phishing attacks.”

Control 2.2.2

Subdomain 3.5 sets physical controls for IT/OT assets but no testing. The penetration test scope ‘involves the systems, locations, techniques, and tools’, which does not state physical intrusion testing.

Third-party services must be monitored, audited and reviewed (Control 5.1.3). No testing of third parties.

Domain 6 (OT and IoT) requires a network scan for running services, open ports and protocols. This is a scan, not a penetration test.

“The entity must perform a network scan to identify running services, open ports, and supported protocols.”

Control 6.6

No provision on payment systems.

Subdomain 5.2 covers cloud risk, access, encryption and logging. No testing.

No provision on cross-border matters.

No provision.

Weaknesses must be prioritized under a remediation plan. No deadline or retest rule.

“The identified weaknesses must be prioritized, and a remediation plan must be developed to treat the weaknesses.”

Control 3.3.5; Control 3.3.3

External audit is coordinated with NCSC and the sector regulator. Test results are not sent to NCSC.

“The external audit should be performed with the coordination between the NCSC and the sector regulator.”

Control 7.4

Penetration tests may be run manually or automatically; vulnerability scanning tools may be used (Control 3.3.1). Nothing on AI.

“conducted either manually or automatically using software applications”

Control 3.3.4; Control 3.3.1

Subject entities must apply the standards immediately on notification by NCSC, on a schedule NCSC may agree per entity or sector. Translation by Bendings.

“تلتزم الجهات الخاضعة بتطبيق المعايير فور إخطارها بها من المركز”

Decision 36/2026, Art. 4

All government or private entities in the critical sectors named in the National Cyber Security Strategy; NCSC may add others. Translation by Bendings.

“تسري أحكام هذا القرار على جميع الجهات العاملة ضمن القطاعات الحيوية المحددة بموجب الاستراتيجية الوطنية للأمن السيبراني”

Decision 36/2026, Art. 1 (definition of ‘entity’); Art. 2

The public decision requires an annual cyber risk assessment (Art. 8), not a test. Any testing frequency would sit in the restricted Annex 1.

“وتعد هذه المعايير وثيقة غير قابلة للنشر، ويقتصر تداولها على الجهات الخاضعة والجهات المعنية بتنفيذ هذا القرار”

Decision 36/2026, Art. 3; Art. 8; Art. 10

Annex 1 is restricted to subject entities.

“وتعد هذه المعايير وثيقة غير قابلة للنشر”

Decision 36/2026, Art. 3; Art. 10

Annex 1 is restricted to subject entities.

“وتعد هذه المعايير وثيقة غير قابلة للنشر”

Decision 36/2026, Art. 3; Art. 10

Annex 1 is restricted to subject entities.

“وتعد هذه المعايير وثيقة غير قابلة للنشر”

Decision 36/2026, Art. 3; Art. 10

Annex 1 is restricted to subject entities.

“وتعد هذه المعايير وثيقة غير قابلة للنشر”

Decision 36/2026, Art. 3; Art. 10

Annex 1 is restricted to subject entities.

“وتعد هذه المعايير وثيقة غير قابلة للنشر”

Decision 36/2026, Art. 3; Art. 10

Annex 1 is restricted to subject entities.

“وتعد هذه المعايير وثيقة غير قابلة للنشر”

Decision 36/2026, Art. 3; Art. 10

Annex 1 is restricted to subject entities.

“وتعد هذه المعايير وثيقة غير قابلة للنشر”

Decision 36/2026, Art. 3; Art. 10

Annex 1 is restricted to subject entities.

“وتعد هذه المعايير وثيقة غير قابلة للنشر”

Decision 36/2026, Art. 3; Art. 10

Annex 1 is restricted to subject entities.

“وتعد هذه المعايير وثيقة غير قابلة للنشر”

Decision 36/2026, Art. 3; Art. 10

Annex 1 is restricted to subject entities.

“وتعد هذه المعايير وثيقة غير قابلة للنشر”

Decision 36/2026, Art. 3; Art. 10

Annex 1 is restricted to subject entities.

“وتعد هذه المعايير وثيقة غير قابلة للنشر”

Decision 36/2026, Art. 3; Art. 10

The public decision requires internal plans to treat risks found in the annual risk assessment (Art. 8). Test remediation rules, if any, sit in Annex 1.

“وتعد هذه المعايير وثيقة غير قابلة للنشر”

Decision 36/2026, Art. 3; Art. 8; Art. 10

Entities must submit to NCSC assessment and audit under the maturity program and share annual risk assessment results with NCSC, in coordination with the sector regulator. Translation by Bendings.

“وتوفير المعلومات اللازمة للتقييم والتدقيق والمتابعة، والخضوع للتقييم والتدقيق”

Decision 36/2026, Art. 6; Art. 8

Annex 1 is restricted to subject entities.

“وتعد هذه المعايير وثيقة غير قابلة للنشر”

Decision 36/2026, Art. 3; Art. 10

Module GR is a CBB Directive under Article 38 of the CBB Law. The testing paragraphs use “must”. Module OB is a Directive on the same basis (OB-A.1.3).

“This Module contains the Central Bank of Bahrain ('CBB') Directive (as amended from time to time) regarding general requirements applicable to ancillary service provider licensees, and is issued under the powers available to the CBB under Article 38”

GR-A.1.2; GR-12.2.3; OB-A.1.3

GR-12.2 applies to ancillary service provider licensees that offer services through digital channels. Payment service providers, account information service providers and payment initiation service providers carry the strictest cycle. Module OB adds API tests for AISPs and PISPs.

“This Section applies to ancillary service provider licensees that provide services through digital channels.”

GR-12.2.1; GR-12.2.3; OB-A.1.1

PSPs, AISPs and PISPs test at least twice a year, in June and December. Other digital licensees test once a year, in June. AISPs and PISPs also get a third-party API vulnerability assessment and penetration test every 6 months (OB-1.1.10) and an external review of systems and controls at least every 3 years (OB-1.1.11).

“PSPs, AISPs, and PISPs 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”

GR-12.2.3; GR-12.2.4; OB-1.1.10; OB-1.1.11

Tests must simulate real world attacks, but no rule ties test scenarios to threat intelligence. Threat intelligence “should” update incident scenario tests, and licensees “should” subscribe to a threat intelligence service (GR-12.2.25).

“Licensees should regularly use threat intelligence to update the scenarios so that they remain current and relevant.”

GR-12.2.39; GR-12.2.25; GR-12.2.3

Certified, qualified and experienced testers. External, independent testers changed at least every two years. No scheme named. OB-1.1.10 requires a third-party specialist for API tests.

“(c) Be conducted by qualified and experienced security professionals who are certified in providing penetration testing services; (d) Be performed by external, independent third parties which must be changed at least every two years”

GR-12.2.3(c), (d); OB-1.1.10

The test must be run by external, independent third parties. Unlike the bank and insurance rules (OM-5.5.28(d), RM-9.1.29(d)), the text does not name internal testers.

“(d) Be performed by external, independent third parties which must be changed at least every two years”

GR-12.2.3(d); OB-1.1.11

GR-12.2.57 gives testing employee reactions to simulated cyber-attack scenarios as a way to train staff, the same text that makes the CBB bank, insurance, investment, crypto-asset, stablecoin and money changer rows permitted. For AISPs and PISPs, the six-monthly API tests must also consider the risk of social engineering (OB-1.1.10), a controls test that names no method. Not required: OB-1.1.10 asks the tests to consider the risk, while CBUAE Art. 13(17) requires the test scope to cover social engineering.

“The licensee must ensure that all employees receive adequate training on a regular basis, in relation to cyber security and the threats they could encounter, such as through testing employee reactions to simulated cyber-attack scenarios.”

GR-12.2.57; OB-1.1.10 (Module OB, https://cbben.thomsonreuters.com/entiresection/506901)

Physical access appears only as an attack vector to consider in threat assessments (GR-12.2.27(b)). No physical testing provision.

Vulnerability assessments must cover connections with third parties, defined as API or other connections with fintechs, technology providers and outsourcing providers (GR-12.2.31). CBB may require additional third-party security reviews (GR-12.2.32). The penetration test rule itself does not name third parties. No pooled tests.

“The vulnerability assessments must be comprehensive and cover internal technology, external technology, and connections with third parties.”

GR-12.2.30; GR-12.2.31; GR-12.2.32

Appendix A lists a baseline configuration for information technology and industrial control systems as a control. No testing provision covers OT.

The twice-yearly test duty is placed on payment service providers and payment initiation providers by name, so the tested systems are payment systems. Module OB adds tests of the open banking APIs used to initiate payments. SWIFT and card schemes are not named.

“AISPs and PISPs must appoint a third party specialist to conduct vulnerability assessments against cyber-attacks and penetration testing on the specific API security standards every 6 months.”

GR-12.2.3; OB-1.1.10 (Module OB, https://cbben.thomsonreuters.com/entiresection/506901)

Cloud appears only as an attack vector to consider in threat assessments (GR-12.2.27(b)). No testing provision covers cloud or SaaS.

Overseas licensees must be overseen by their regional or head office under a cyber security risk framework. Nothing on multi-jurisdiction tests, recognition of foreign tests or tester location.

“Overseas licensees must be governed under a framework of cyber security risk management policies which ensure that an adequate level of oversight is exercised by the regional office or head office.”

GR-12.2.10

GR-12.2.52 requires an exercise program (attack simulations, war games, table top). No purple teaming or replay.

Penetration test reports must record the steps taken to mitigate each risk (GR-12.2.4). AISPs and PISPs must send CBB an action plan with each API test report. Vulnerabilities must be fixed on a risk-based timeline (GR-12.2.2). No fixed deadline and no retest rule.

“The specialist's report must be submitted to the CBB, along with the licensee's related action plan to resolve any issues identified.”

OB-1.1.10; GR-12.2.4; GR-12.2.2

Reports go to CBB before September 30 for June tests and before March 31 for December tests. CBB may require additional third-party security reviews (GR-12.2.32). CBB does not lead tests or accredit testers.

“Reports on penetration testing 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.”

GR-12.2.4; GR-12.2.32; OB-1.1.10

GR-12.2.46 lists incidents ‘detected and responded via automation’ as a metric. Nothing on automated or AI-driven testing, or on testing AI systems.

Module CRA is a CBB Directive under Article 38 of the CBB Law. The testing paragraph uses “must”. CBB may grant written exemptions from specific technology governance and cyber security requirements where a licensee shows its business does not need them (CRA-5.1.3).

“This Module contains the CBB's Directive (as amended from time-to-time) relating to licensees providing regulated crypto-asset services (henceforth referred to as licensees) as defined in the Rulebook and is issued under the powers available to the CBB under Article 38 of the CBB Law.”

CRA-A.1.3; CRA-5.8.13G; CRA-5.1.3

Licensees trading, dealing, advising, managing portfolios or holding custody in crypto-assets, and crypto-asset exchanges. Digital token issuers under Chapter CRA-15 are outside Chapters CRA-1 to CRA-14.

“Chapters CRA-1 to CRA-14 apply to Category 1, 2, 3 and 4 licensees offering regulated crypto-asset services.”

CRA-A.1.1; CRA-B.1.5

Vulnerability assessment and penetration testing at least twice a year, with 6 months between external tests (CRA-5.8.13I). Vulnerability assessments “preferably” monthly for internal and weekly for external systems (CRA-5.8.13D).

“All licensees must perform vulnerability assessment and penetration testing of their systems, applications, and network devices to verify the robustness of the security controls in place at least twice a year.”

CRA-5.8.13G; CRA-5.8.13I; CRA-5.8.13D

Tests must simulate real world attacks, but no rule ties test scenarios to threat intelligence. Threat intelligence “should” update incident scenario tests, and a threat intelligence subscription “should” be taken (CRA-5.8.11C).

“Licensees should regularly use threat intelligence to update the scenarios so that they remain current and relevant.”

CRA-5.8.14G; CRA-5.8.11C

Certified, qualified and experienced testers. The twice-yearly test must be run by external, independent third parties rotated out at least every two years. No scheme named.

“(c) Be conducted by qualified and experienced security professionals who are certified in providing penetration testing services;”

CRA-5.8.13G(c), (e)

In-house staff with adequate expertise must also test at periodic intervals, but the twice-yearly test must be external. Internal testing adds to the external test and cannot replace it.

“(d) Be performed internally at periodic intervals by employees having adequate expertise and competency in such testing; (e) Be performed, twice a year, by external independent third parties who are rotated out at least every two years; and”

CRA-5.8.13G(d), (e)

Only as an example of staff training. No red team clause.

“The licensee must ensure that all employees receive adequate training on a regular basis, in relation to cyber security and the threats they could encounter, such as through testing employee reactions to simulated cyber-attack scenarios.”

CRA-5.8.31

Physical access appears only as an attack vector to consider in threat assessments (CRA-5.8.13A(b)). The security plan must cover physical facilities (CRA-5.1.2(d)). No physical testing provision.

Vulnerability assessments must cover connections with third parties, defined as API or other connections with fintechs, technology providers and outsourcing providers. CBB may require additional third-party security reviews (CRA-5.8.13H). No pooled tests.

“The vulnerability assessments must be comprehensive and cover internal technology, external technology, and connections with third parties.”

CRA-5.8.13D; CRA-5.8.13H

No provision on OT or industrial control systems.

IT systems including trading and settlement systems must be “fully tested” for capacity and orderly trading under stress (CRA-5.1.4). That is a resilience test, not a security test. The security testing paragraphs do not name payment, settlement, card or SWIFT systems.

The security plan must cover cloud based services (CRA-5.1.2(d)) and cloud is an attack vector to consider (CRA-5.8.13A(b)). No testing provision covers cloud or SaaS.

No provision on multi-jurisdiction tests, foreign testers or test data location. Physical copies of seeds and private keys must be kept in Bahrain (CRA-5.4.11(c)) and outsourcing outside Bahrain needs CBB approval (CRA-6.6.7). Neither is a testing rule.

No purple teaming, replay or red team provision.

Test reports must record the steps taken to mitigate each risk and be kept for five years. Vulnerabilities must be fixed on a risk-based timeline (CRA-5.8.13F). No fixed deadline and no retest rule.

“The vulnerability assessment and penetration testing reports must include the vulnerabilities identified and a full list of ‘passed’ tests and ‘failed’ tests together with the steps taken to mitigate the risks identified.”

CRA-5.8.13I; CRA-5.8.13F; CRA-5.8.36

Each external test report goes to CBB within two months of the test month. CBB may require additional third-party security reviews. CBB does not lead tests or accredit testers.

“the report on such testing must be provided to CBB within two months following the end of the month where the testing took place.”

CRA-5.8.13I; CRA-5.8.13H

The only automation text is an incident metric, ‘Volume of incidents detected and responded via automation’ (CRA-5.8.14N). Nothing on automated or AI-driven testing, or on testing AI systems.

Module SIO is a CBB Directive under Article 38 of the CBB Law. The testing paragraph uses “must”.

“This Module contains the CBB’s Directive (as amended from time-to-time) relating to issuance and offering of stablecoins and is issued under the powers available to the CBB under Article 38 of the CBB Law.”

SIO-A.1.3; SIO-9.6.30

Issuers of single-currency stablecoins backed by BHD, USD or other approved fiat reserves (SIO-1.2.1). The issuer must report use of its stablecoin as a medium of exchange in Bahrain (SIO-8.1.1(d)).

“This Module sets out the requirements for stablecoin issuers undertaking regulated stablecoin offering service.”

SIO-1.1.1; SIO-1.2.1

Vulnerability assessment and penetration testing at least twice a year, with 6 months between external tests (SIO-9.6.32). Vulnerability assessments “preferably” monthly for internal and weekly for external systems (SIO-9.6.27).

“Stablecoin issuers must perform vulnerability assessment and penetration testing of their systems, applications, and network devices to verify the robustness of the security controls in place at least twice a year.”

SIO-9.6.30; SIO-9.6.32; SIO-9.6.27

Tests must simulate real world attacks, but no rule ties test scenarios to threat intelligence. Threat intelligence “should” update incident scenario tests, and a threat intelligence subscription “should” be taken (SIO-9.6.20).

“Stablecoin issuers should regularly use threat intelligence to update the scenarios so that they remain current and relevant.”

SIO-9.6.39; SIO-9.6.20

Certified, qualified and experienced testers. The twice-yearly test must be run by external, independent third parties rotated out at least every two years. No scheme named.

“(c) Be conducted by qualified and experienced security professionals who are certified in providing penetration testing services;”

SIO-9.6.30(c), (e)

In-house staff with adequate expertise must also test at periodic intervals, but the twice-yearly test must be external. Internal testing adds to the external test and cannot replace it.

“(d) Be performed internally at periodic intervals by employees having adequate expertise and competency in such testing; (e) Be performed, twice a year, by external independent third parties who are rotated out at least every two years; and”

SIO-9.6.30(d), (e)

Only as an example of staff training. No red team clause.

“Stablecoin issuer must ensure that all employees receive adequate training on a regular basis, in relation to cyber security and the threats they could encounter, such as through testing employee reactions to simulated cyber-attack scenarios.”

SIO-9.6.59

Physical access appears only as an attack vector to consider in threat assessments (SIO-9.6.24(b)). The security plan must cover physical facilities (SIO-9.1.2). No physical testing provision.

Vulnerability assessments must cover connections with third parties, defined as API or other connections with fintechs, technology providers and outsourcing providers. CBB may require additional third-party security reviews (SIO-9.6.31). No pooled tests.

“The vulnerability assessments must be comprehensive and cover internal technology, external technology, and connections with third parties.”

SIO-9.6.27; SIO-9.6.31

No provision on OT or industrial control systems.

The module applies only to stablecoin issuers, and approved stablecoins serve as a medium of exchange in Bahrain, which issuers must report (SIO-8.1.1(d)). The twice-yearly penetration test (SIO-9.6) therefore covers the systems that issue, redeem and transfer a payment instrument. Coded as the OCC GENIUS rule and the CBK e-money rule. The testing paragraphs do not name payment, card or SWIFT systems.

“an estimate of the average number and average aggregate value of transaction per day during the quarter that are associated to its use as a medium of exchange within Bahrain.”

SIO-1.1.1; SIO-8.1.1(d); SIO-9.6

The security plan must cover cloud based services (SIO-9.1.2) and cloud is an attack vector to consider (SIO-9.6.24(b)). No testing provision covers cloud or SaaS.

Access to seeds and private keys for approved stablecoins is restricted to senior managers residing in Bahrain (SIO-9.4.3(c)), a residency limit on people with access to systems in scope. Outsourcing outside Bahrain needs CBB approval (SIO-5.10.7), which R1 does not count on its own. Nothing on multi-jurisdiction tests, recognition of tests run abroad or foreign testers.

“Access to seed and private key relating to approved stablecoins is tightly restricted among senior management personnel residing in Bahrain”

SIO-9.4.3(c); SIO-5.10.7 considered

No purple teaming, replay or red team provision.

Test reports must record the steps taken to mitigate each risk and be kept for five years. Vulnerabilities must be fixed on a risk-based timeline (SIO-9.6.29). No fixed deadline and no retest rule.

“The vulnerability assessment and penetration testing reports must include the vulnerabilities identified and a full list of ‘passed’ tests and ‘failed’ tests together with the steps taken to mitigate the risks identified.”

SIO-9.6.32; SIO-9.6.29; SIO-9.6.64

Each external test report goes to CBB within two months of the test month. CBB may require additional third-party security reviews. CBB does not lead tests or accredit testers.

“the report on such testing must be provided to CBB within two months following the end of the month where the testing took place.”

SIO-9.6.32; SIO-9.6.31

The only automation text is an incident metric, ‘Volume of incidents detected and responded via automation’ (SIO-9.6.46). Nothing on automated or AI-driven testing, or on testing AI systems.

Module RM is a CBB Directive under Article 38 of the CBB Law. The testing paragraph uses “must”.

“This Module contains the Central Bank of Bahrain's ('CBB') Directive (as amended from time to time) regarding Risk Management requirements applicable to licensees, and is issued under the powers available to the CBB under Article 38”

RM-A.1.3; RM-3.1.29

All money changers licensed in Bahrain. Their regulated services include currency transfer to and from Bahrain (Volume 5 Type 1, AU-1.1.8(b), https://cbben.thomsonreuters.com/node/500675).

“The content of this Module applies to all Money Changer licensees authorised in the Kingdom, thereafter referred to in this Module as licensees.”

RM-B.1.1; AU-1.1.8

Once a year for all licensees, twice a year for licensees with digital channels. RM-3.1.31 then says tests are held each June and December, citing RM-3.1.59, which looks like a cross-reference slip for RM-3.1.29.

“All licensees must perform penetration testing of their systems, applications, and network devices to verify the robustness of the security controls in place at least once a year. However, licensees that provide services through digital channels must perform penetrating testing at least twice a year.”

RM-3.1.29; RM-3.1.31

Same text as the bank and insurance rules. Threat intelligence “should” update incident scenario tests, and a threat intelligence subscription “should” be taken (RM-3.1.21).

“Licensees should regularly use threat intelligence to update the scenarios so that they remain current and relevant.”

RM-3.1.38; RM-3.1.21

Certified, qualified testers; independent testers changed at least every two years. No scheme named.

“(c) Be conducted by qualified and experienced security professionals who are certified in providing penetration testing services; (d) Be performed by internal and external independent third parties which should be changed at least every two years”

RM-3.1.29(c), (d)

Same ‘internal and external independent third parties’ wording as Volume 1, with two-year rotation. ‘Internal’ is not defined.

“(d) Be performed by internal and external independent third parties which should be changed at least every two years”

RM-3.1.29(d)

Only as an example of staff training. No red team clause.

“The licensee must ensure that all employees receive adequate training on a regular basis, in relation to cyber security and the threats they could encounter, such as through testing employee reactions to simulated cyber-attack scenarios.”

RM-3.1.56

Physical access appears only as an attack vector to consider in threat assessments (RM-3.1.23(b)). No physical testing provision.

Vulnerability assessments must cover connections with third parties. CBB may require additional third-party security reviews (RM-3.1.30). RM-3.1.27, which defines third-party connections, refers to ‘RM-3.1.25’; it appears to mean RM-3.1.26, as with Vol. 3 RM-9.1.27. No pooled tests.

“The vulnerability assessments must be comprehensive and cover internal technology, external technology, and connections with third parties.”

RM-3.1.26; RM-3.1.27; RM-3.1.30

Appendix A lists industrial control system configuration baselines only. No testing provision covers OT.

The test covers all systems. Money changers may transfer currency to and from Bahrain (AU-1.1.8(b)), but the testing paragraphs do not name remittance, payment, card or SWIFT systems.

Cloud appears as an attack vector (RM-3.1.23(b)) and in the outsourcing rules (Chapter RM-2). No testing provision.

Overseas licensees must be overseen by their regional or head office under a cyber security risk framework, the same text as OM-5.5.6. Outsourcing outside Bahrain needs CBB approval (RM-2.1.7). Nothing on multi-jurisdiction tests, recognition of foreign tests or tester location.

“Overseas licensees must be governed under a framework of cyber security risk management policies which ensure that an adequate level of oversight is exercised by the regional office or head office.”

RM-3.1.6; RM-2.1.7

No purple teaming, replay or red team provision.

Reports must record the steps taken to mitigate each risk. Vulnerability remediation processes required (RM-3.1.28). No deadline, no retest rule.

“The penetration testing reports must include the vulnerabilities identified and a full list of ‘passed’ tests and ‘failed’ tests together with the steps taken to mitigate the risks identified.”

RM-3.1.31; RM-3.1.28; RM-3.1.61

Reports go to CBB within three months of the test month. CBB may require additional third-party security reviews. CBB does not lead tests or accredit testers.

“must be provided to CBB within three months following the end of the month where the testing took place, i.e. for a June test, the report must be submitted at the latest by 30th September and for a December test, by 31st March.”

RM-3.1.61; RM-3.1.31; RM-3.1.30

The only automation text is an incident metric, ‘Volume of incidents detected and responded via automation’ (RM-3.1.45). Nothing on automated or AI-driven testing.

Module OM is a CBB Directive under Article 38 of the CBB Law. The testing paragraphs use “must”.

“This Module contains the CBB's Directive (as amended from time to time) relating to operational risk management and is issued under the powers available to the CBB under Article 38 of the Central Bank of Bahrain and Financial Institutions Law 2006 ('CBB Law').”

OM-A.1.3; OM-5.2.1

Module OM applies to all financing company licensees (OM-B.1.1). The test duty covers those providing internet financial services, a term the module does not define.

“Licensees providing internet financial services must regularly test their systems against security breaches and verify the robustness of the security controls in place.”

OM-B.1.1; OM-5.2.1; BR-1.6.1

Penetration tests each June and December, the same cycle as the bank rules (OM-5.5.61).

“The penetration testing referred to in Paragraph OM-5.2.1, must be conducted each year in June and December.”

OM-5.2.2; BR-1.6.2

Threat scenarios appear only in business continuity planning (OM-4.3, OM-4.8.9). Nothing ties tests to threat intelligence.

Tests must be run by security professionals “such as ethical hackers” who provide penetration testing services. No certification, accreditation, independence or rotation rule, unlike Volume 1 OM-5.5.28(c) and (d).

“These tests must be conducted by security professionals, such as ethical hackers, that provide penetration testing services and a vulnerability assessment of the system.”

OM-5.2.1

Silent on whether the security professionals may be the licensee’s own staff. “That provide penetration testing services” suggests an outside provider but does not exclude in-house testers.

Staff get annual security training on branch security (OM-5.1.16), and customers get fraud warnings (OM-3.1.8). No social engineering test.

Section OM-5.1 prescribes physical security for branches (steel doors, intrusion alarms, CCTV, strong rooms) but no test of it. The OM-5.2 test covers systems.

The penetration test duty does not mention third parties. Outsourcing agreements must give CBB and auditors access to the provider’s records (OM-2.1.7(iv)), assessments may use provider certifications, audit reports or pooled audits (OM-2.1.8), and annual continuity tests must include vendors’ recovery services.

“(c) Important recovery services provided by vendors or counterparties must form part of the testing scope;”

OM-4.8.2(c); OM-2.1.7(iv); OM-2.1.8

No provision.

All licensees must hold PCI-DSS certification and are audited by PCI authorised companies (OM-5.1.19, OM-5.1.19A). The OM-5.2 test names no payment, card or SWIFT system. Coded as the CBB bank row.

Cloud services appear only as an outsourcing example (OM-2.1.2) and in the CBB notification rules (OM-2.1.7(i), (ii)). No testing provision.

Outsourcing to a third party outside Bahrain needs prior CBB approval, cloud data services excepted (OM-2.1.7(i)). For branches of foreign entities, CBB may treat third-party outsourcing arranged by the head office as intragroup, given a letter of comfort (OM-2.1.3), and the branch may outsource its risk management function to the head office with CBB approval (OM-2.1.6). These are outsourcing conditions, not testing rules, and the module has no rule on head-office oversight of overseas licensees’ cyber risk, unlike OM-5.5.6, GR-12.2.10 and RM-3.1.6. Coded as the crypto-asset row, whose outsourcing approval rule (CRA-6.6.7) is also not counted.

Workshops appear only as a risk self-assessment tool (OM-1.3.4(a)). No purple teaming or replay.

The report must be kept with the steps taken to mitigate the risks. Material gaps found in periodic control evaluations need immediate corrective action (OM-5.3.2). No deadline for test findings, no retest rule.

“The vulnerability assessment report, along with the steps taken to mitigate the risks must be maintained by the licensee for a 5-year period from the date of testing”

OM-5.2.3; OM-5.3.2

The vulnerability assessment report goes to CBB within two months of the test month (also BR-1.6.2). CBB does not lead tests or approve testers.

“must be provided to the CBB within two months following the end of the month where the testing took place, i.e. for the June test, the report must be submitted at the latest by 31st August and for the December test, by 28th February”

OM-5.2.3; BR-1.6.2

Automation appears only in a risk statement on loss patterns (OM-1.5.10). Nothing on automated or AI-driven testing.