Banks in the GCC face the region's most prescriptive penetration testing mandates. In Bahrain, the CBB requires testing twice a year (June and December), with reports due 30 September and 31 March. In Saudi Arabia, SAMA requires annual testing of customer and internet-facing services under control 3.2.4, plus FEER red teaming every three years. Systems classified as critical national infrastructure also fall under the NCA ECC. We scope one engagement to satisfy every regulator you answer to, test the systems that actually carry your risk — internet and mobile banking, payment APIs, card systems and the internal network — and deliver a report mapped to each control reference, so it serves as audit evidence rather than just a technical document.
// 01 Why banks need specialist penetration testing
Banks are the highest-value target in any economy, and in the GCC they operate under regulators who treat penetration testing as a named, deadline-bound obligation rather than good practice. The combination is demanding: a bank must test high-complexity systems — internet banking, mobile apps, payment rails, card processing, legacy core systems — without disrupting services, then report the results to a supervisor on a fixed schedule, in a format that proves not just what was found but that it was fixed.
That is a different exercise from a generic security test. It requires testers who recognise financial-sector attack paths, an engagement scoped around release calendars and change freezes, and reporting written for two audiences at once: the engineers who fix the findings and the regulator who reviews the closure. Getting any of those wrong turns a passed test into a supervisory problem.
// 02 What GCC regulators require of banks
Each regulator expresses the requirement differently, and a bank operating across the GCC may answer to more than one. The verified essentials:
| Regulator | Frequency | Key reference | Reporting |
|---|---|---|---|
| CBB (Bahrain) | Twice a year (Jun & Dec) | OM-5.5 / GR-12.2 | 30 September & 31 March |
| SAMA (Saudi Arabia) | Annual + FEER every 3 yrs | Control 3.2.4 / FEER | To SAMA; maturity level 3+ |
| NCA ECC (Saudi CNI) | Periodically (CSCC: 6-monthly) | Control 2-11 / CSCC 2-10 | NCA compliance tool |
| PCI DSS (card data) | Annual + after significant change | Requirement 11.4 | To QSA / acquirer |
The efficiency play, and the one we build every banking engagement around, is convergence: a single well-scoped test of customer and internet-facing services can satisfy SAMA 3.2.4 and ECC 2-11 together, while a payment-focused scope aligns with PCI DSS 11.4. Our requirements finder lays out exactly what each framework demands, and we map one evidence set across all of them.
// 03 What we test in a banking engagement
Scope follows the systems that carry a bank's real risk and the ones regulators name. A typical engagement spans the customer-facing channels, the payment core, and the internal estate an attacker would traverse to reach it.
Digital banking & APIs
Internet and mobile banking applications and the APIs behind them — authentication, authorisation, transaction integrity and business-logic abuse.
Payment & card systems
Payment APIs, card processing, tokenisation and the cardholder data environment tested to PCI DSS expectations.
Internal network & AD
Lateral movement, Active Directory attack paths and segmentation between corporate IT and payment infrastructure.
Third-party integrations
The fintech, aggregator and vendor connections that widen the attack surface and often carry excessive standing privilege.
// 04 What we most often find in banking engagements
Across GCC financial-sector testing, the highest-impact issues recur in a handful of predictable places — and they are precisely the ones automated scanners miss.
Broken object-level authorisation in banking APIs
The back-end authenticates the user but fails to verify the requested account or transaction belongs to them — letting one customer act on another's account. Every request returns a valid response, so scanners never flag it.
Corporate network reachable from payment infrastructure
Segmentation built correctly, then eroded by years of firewall exceptions for monitoring, backup and vendor access that were never withdrawn.
Transaction and limit-bypass logic flaws
Race conditions and workflow gaps that let an attacker exceed limits, replay transfers or manipulate multi-step flows the application assumed were linear.
Production data in test environments
Unmasked customer records in UAT — a finding in its own right, and separately a data-protection exposure under the region's PDPL regimes.
// 05 Regulator-ready reporting — not just a technical PDF
The deliverable is where banking engagements are won or lost. A raw technical report is written for engineers; a supervisor needs a document that demonstrates control. We produce both from one test: the technical detail your teams need to remediate, and a regulator-facing layer that maps every finding to the specific control reference — CBB module, SAMA 3.2.4, ECC 2-11 or PCI 11.4 — states passed and failed tests explicitly, and evidences mitigation.
Because retesting is included in our engagements, the final report can show closure rather than just a list of open risks — which for a CBB submission (where the report must list mitigation steps) or a SAMA review (where measured effectiveness distinguishes maturity levels) is the difference between a report and passed supervision. We deliver on-site read-outs in Arabic or English, structured for both your board and your assessor.
// 06 Frequently asked questions
How often must a GCC bank conduct penetration testing?
Bahrain (CBB): twice a year, June and December. Saudi Arabia (SAMA): annual for customer and internet-facing services, plus FEER red teaming every three years. Critical-infrastructure systems also fall under NCA ECC, with a six-month interval under the CSCC.
What systems should a bank test?
Internet and mobile banking and their APIs, core banking and payment infrastructure, card and ATM systems, the internal network and Active Directory, and third-party integrations.
Can one test satisfy both SAMA and NCA ECC?
Often yes — they run in parallel, and one test of customer and internet-facing services can evidence SAMA 3.2.4 and ECC 2-11 if scoped and reported to both references.
What makes bank testing different?
High-value targets, fixed regulatory deadlines, complex payment and legacy systems, and low disruption tolerance — requiring change-freeze-aware scoping, regulator-ready reporting and financial-sector expertise.
// 07 References
- CBB Rulebook cyber-security modules (OM-5.5 / GR-12.2) — see our CBB penetration testing guide.
- SAMA Cyber Security Framework control 3.2.4 and the FEER Framework — see our SAMA guide.
- NCA Essential Cybersecurity Controls control 2-11 and CSCC 2-10 — see our NCA ECC guide.
- PCI DSS v4.0 Requirement 11.4 — see our PCI DSS framework guide.