SAMA Penetration Testing Requirements
If the Saudi Central Bank supervises you, penetration testing is an annual recurring obligation rather than a project. The framework is specific about two things that decide whether your evidence survives review: the testing must be independent, and the scope must reach the systems your customers can touch.
The requirement, stated plainly
Institutions supervised by the Saudi Central Bank are expected to conduct independent external penetration tests at minimum annually, with scope covering externally facing systems, web applications and network infrastructure.
Three words in that sentence carry the weight, and each one is a place where evidence commonly fails review:
- Independent - not performed by the team that builds or operates the systems under test.
- Annually, at minimum - the yearly cycle is a floor, and material change to internet-facing systems is a separate trigger.
- Penetration test - not a vulnerability scan with a different cover page. Assessors have become good at telling them apart.
Where SAMA evidence actually fails
Four failure modes account for most of what gets challenged, and all four are cheaper to avoid than to remediate.
A scan submitted as a penetration test
The tell is structural: every finding is a CVE with a vendor-supplied description, nothing is chained, and there is no narrative explaining what an attacker could achieve. A penetration test demonstrates impact - this exposed service yields a credential, that credential reaches this internal system, which holds this data. If your report is a sorted list of versions, it is a scan. The distinction in full.
Independence that doesn't hold
Testing performed by the engineering team, by the managed service provider who also runs the infrastructure, or by a vendor assessing its own product. Each of these fails the independence requirement no matter how competent the testing was.
Scope that misses the customer-facing layer
Mobile banking backends, partner APIs, the new fintech integration launched after the scope was signed. Internet-facing systems and web applications are named explicitly in the framework, so a gap here is a direct miss rather than a judgement call.
No retest
A report with twelve high-severity findings and no evidence that any of them were closed is, from a reviewer's perspective, documentation of an unresolved problem. The remediation and retest cycle is what converts a test into compliance evidence.
What the engagement covers
The regulatory baseline, every year:
- External network testing - the full internet-facing estate: online banking, payment interfaces, VPN and remote access, mail infrastructure, and the hosts that were published for a project and never withdrawn.
- Web application and API testing - authentication and session handling, authorisation and access control between customers, business logic in transaction flows, injection, and the APIs behind mobile apps. In a financial institution the business-logic findings are usually the ones that matter most and the ones automation never finds.
Recommended alongside it, and included by most institutions on an annual or alternating cycle:
- Internal network testing - what a foothold actually reaches, and whether the segmentation between corporate and payment environments holds.
- Active Directory - ADCS abuse, Kerberoasting, delegation and ACL paths to Domain Admin. This is how a modest foothold becomes a bank-wide compromise, and it is invisible to external testing.
- Cloud - Entra ID and Azure RBAC escalation, exposed storage and identity misconfiguration, where workloads have moved.
- Assumed breach - starting from a foothold rather than the perimeter, which answers the question a board actually asks: how far could someone get?
Where you also handle card data, PCI DSS Requirement 11.4 applies in parallel and overlaps substantially - scoped together it is one engagement, not two.
The deliverable
A report built for the way financial institutions actually consume it: an executive summary your board and your regulator can read without translation, a technical body with reproduction steps, evidence and CVSS ratings for your engineers, and explicit mapping from each finding to the framework control it bears on, so your compliance team doesn't have to construct that mapping themselves.
Then the parts that turn a report into evidence: remediation support while you fix things, a retest of the closed findings, and an attestation letter stating that the test was performed, by whom, against what scope and on what dates. All included. A sample report shows the format.
Who performs it
You deal with the tester directly - no account manager, no junior running tooling under a senior's name on the invoice, no three-week wait between testing and report. For a regulatory deadline that directness is usually what makes the date.
Credentials, since this gets asked in financial-sector procurement: OSCP+, eCPPT, eWPT, eCIR, plus AZ-500, SC-200 and SC-300 for the Microsoft and Azure portion - all verifiable through the OffSec credential wallet. Before moving into offensive work full time I was a detection engineer and CTI analyst, which is a useful background in this sector specifically: the report tells you not only how an attack path works but what it would have looked like in your SIEM, and whether your monitoring would have caught it.
I work remotely from Amman on GMT+3, the same hours and working week as Riyadh, in Arabic or English.
Getting started
Tell me your licence type, what's in scope, and when the test needs to be complete. You'll get a fixed-price quote and a start date back. If your annual cycle is approaching and you want to see your current external exposure first, the free perimeter scan takes a few minutes.
Related: penetration testing in Saudi Arabia for how SAMA sits alongside NCA ECC, ECC control 2-11 if you also carry a government obligation, and the compliance overview for everything else. Get in touch - Arabic welcome.
SAMA questions
Member organisations supervised by the Saudi Central Bank: banks, insurance and reinsurance companies, finance companies, credit bureaux, and payment service providers including fintechs operating under SAMA licence or in its regulatory sandbox. If your licence comes from SAMA, the framework applies to you. Fintechs are frequently surprised by this - the obligation arrives with the licence, at a stage when the security programme is often still forming.
Independent external penetration testing at minimum annually. 'At minimum' does real work in that sentence: material change to internet-facing systems is generally expected to trigger testing regardless of where you are in the annual cycle, and an institution that launched a new customer-facing platform six months after its annual test and didn't test it will have a difficult conversation. Treat the annual test as the floor and significant change as a separate trigger.
The testing cannot be performed by the people who build or operate the systems under test. An internal security function that reports separately from engineering gets closer, but the cleanest and most commonly accepted answer is an external party with no role in building or running the environment. This is the requirement institutions most often get wrong, and they discover it at review rather than at scoping - which is the expensive order.
The explicitly named scope is internet-facing systems, web applications and network infrastructure. Most institutions go further, and for good reason: a test that proves an attacker can reach the perimeter but never asks what happens next answers half the question. The pattern that works well is a full external and web application assessment annually as the regulatory baseline, with internal network and Active Directory testing included at least in alternate years or whenever the estate changes materially.
Yes, and it's the usual case. You typically already have the framework mapping, a GRC function and an internal audit relationship; what you need is the testing and evidence that slots into it. I scope against the control you need to satisfy, map findings back to it in the report, and deliver the retest and attestation your compliance team needs to file. I'm not a GRC consultancy and I won't try to sell you a framework programme - the testing is the part I do.
Annual SAMA test due?
Independent, scoped to the framework, with the retest and attestation your compliance team files.