If your organisation holds a licence from the Saudi Arabia Monetary Authority, you are subject to the SAMA Cybersecurity Framework (CSF). And if your organisation publishes a mobile banking or payment application which, in 2026, means virtually every SAMA-licensed institution that application is within scope for quarterly compliance reporting.
This post breaks down the specific SAMA CSF requirements that apply to mobile applications, explains what maturity level auditors expect, and shows how to build a testing programme that satisfies quarterly reporting obligations without consuming your entire security team’s capacity.
Who Must Comply
The SAMA CSF applies to all institutions licensed and supervised by SAMA. This includes commercial banks, insurance companies, finance companies, payment service providers, fintech companies operating under SAMA’s regulatory sandbox or full licence, and any other entity that holds a SAMA licence or authorisation.
If your organisation operates in Saudi Arabia under a SAMA licence and offers mobile banking, mobile payments, mobile insurance, or any other customer-facing financial service through a mobile application, the CSF’s application security requirements apply directly to those applications.
For UAE-based organisations with Saudi operations or a Saudi banking subsidiary, this creates a dual compliance requirement: NESA for UAE operations and SAMA for Saudi operations. Both require evidence of mobile app security testing, and both accept OWASP MASVS v2.1 as the reference standard.
The Application Security Controls
The SAMA CSF organises its requirements into domains, each with specific controls and maturity levels. The controls most relevant to mobile application security sit within the application security domain, with supporting requirements in several adjacent domains.
Application security testing. SAMA requires that all applications handling financial data undergo security testing before deployment and on a regular cycle. For mobile banking applications, this means pre-release testing of every version that reaches the app stores, not just an annual assessment. The expectation is that security testing is integrated into the development lifecycle rather than conducted as a separate, infrequent activity.
Vulnerability management. Identified vulnerabilities must be classified by severity, tracked through remediation, and documented with evidence of resolution. SAMA reviewers expect to see a structured workflow not a spreadsheet of findings with no audit trail. The DREAD scoring model provides exactly the structured assessment and tracking workflow that this requirement demands.
Secure development practices. The CSF requires that applications are developed following secure coding standards, with security requirements defined at the design phase and validated through testing. For mobile applications, this means adherence to recognised mobile security standards OWASP MASVS being the most widely accepted reference.
Data protection. Mobile applications that process, store, or transmit financial data must implement encryption in transit and at rest, secure credential storage, and access controls that prevent unauthorised data exposure. These requirements map directly to the MASVS-STORAGE, MASVS-CRYPTO, and MASVS-NETWORK control categories.
Third-party risk management. The CSF requires that third-party components including SDKs and libraries embedded in mobile applications are assessed for security risk. This aligns with the supply chain security concerns addressed by OWASP Mobile Top 10 2024 and reinforces the need to scan the compiled application, not just the organisation’s own source code.
Maturity Levels: What SAMA Expects
The SAMA CSF uses a maturity model with five levels, from Level 1 (Initial) to Level 5 (Adaptive). SAMA expects all licensed institutions to achieve at least Level 3 (Defined) across all relevant control domains.
For mobile application security, Level 3 means several things in practice.
Documented processes. The organisation has a documented mobile app security testing process that specifies what is tested, when, by whom, and against what standard. The process is followed consistently, not applied ad hoc.
Standardised assessment methodology. Testing follows a recognised methodology OWASP MASVS v2.1 rather than relying on informal checklists or generic vulnerability scanning. Findings are classified using a consistent severity model.
Defined roles and responsibilities. It is clear who is responsible for conducting mobile app security testing, who reviews the findings, who authorises release decisions based on the findings, and who reports compliance status to SAMA.
Regular execution. Testing occurs on a defined schedule that aligns with SAMA’s quarterly reporting cycle. Evidence of testing from each quarter must be available for submission.
Achieving Level 3 is not aspirational it is the minimum. Institutions aiming for Level 4 (Managed) or Level 5 (Adaptive) need continuous testing, automated integration into development pipelines, and quantitative metrics on security posture trends over time.
Building a SAMA-Compliant Mobile Security Programme
A practical programme that satisfies SAMA quarterly reporting has four components.
Component 1: Quarterly baseline scans. At minimum, every mobile application in scope must be scanned once per quarter. This produces the compliance evidence required for the quarterly SAMA submission. HEXMobileSuite produces MASVS v2.1 mapped reports that provide the evidence format SAMA reviewers expect.
Component 2: Pre-release scans. Every new version of a mobile application should be scanned before it is published to the app stores. This ensures that new vulnerabilities are detected before they reach users and it demonstrates to SAMA that security testing is integrated into the release cycle, not conducted after the fact.
Component 3: DREAD risk assessment. Each finding must be classified and tracked through a structured review process. The DREAD scoring workflow in HEXMobileSuite provides the five-dimension risk assessment and the Confirmed/Inconclusive/Not Confirmed validation cycle that creates the audit trail SAMA reviewers require.
Component 4: Remediation evidence. For each finding that is remediated, the programme should document what was fixed, when, by whom, and produce a re-scan that confirms the remediation. This closes the loop between detection and resolution demonstrating not just that vulnerabilities were found, but that they were addressed.
How MASVS Maps to SAMA Controls
The mapping between OWASP MASVS v2.1 categories and SAMA CSF application security controls is relatively straightforward, which is why SAMA reviewers are comfortable with MASVS-based evidence.
MASVS-AUTH (authentication and session management) maps to SAMA’s access control and identity management requirements for mobile channels. MASVS-NETWORK (network communication security) maps to SAMA’s data-in-transit protection requirements. MASVS-STORAGE (secure data storage) maps to SAMA’s data-at-rest protection controls. MASVS-CRYPTO (cryptographic requirements) maps to SAMA’s encryption standards. MASVS-PLATFORM (platform interaction) and MASVS-CODE (code quality) map to SAMA’s secure development and application hardening requirements.
When HEXMobileSuite produces a compliance report with findings mapped to these MASVS categories, the SAMA reviewer can trace each finding to the relevant CSF control without requiring a separate mapping exercise. This saves time, reduces ambiguity, and produces cleaner compliance evidence.
The Dual Compliance Advantage
For organisations operating across both the UAE and Saudi Arabia which includes many of the largest banks and financial groups in the GCC the ability to satisfy both NESA and SAMA requirements from a single testing programme is a significant operational advantage.
Both frameworks accept OWASP MASVS v2.1 as a valid reference standard. Both require documented findings with severity classification. Both expect remediation tracking. And both are increasingly looking for evidence of continuous or periodic testing rather than annual point-in-time assessments.
A single HEXMobileSuite deployment can serve both compliance obligations. Scan the same applications, produce the same findings, generate reports for each framework. One platform, one workflow, dual compliance coverage.
Getting Started
If your organisation has a SAMA reporting obligation and has not yet implemented a structured mobile app security testing programme, the most practical first step is to scan your current mobile applications and establish a baseline.
HEXMobileSuite offers a free tier that allows you to scan your first application immediately no procurement cycle, no enterprise sales engagement, no commitment. See the findings, see the report format, and assess whether the platform meets your SAMA compliance evidence requirements.
For organisations with larger application portfolios, contact [email protected] to discuss enterprise plans, quarterly reporting workflows, and dedicated compliance support.
Your next SAMA quarterly report is due. Is your mobile banking app ready? Scan now: hexmobsuite.hiesencyber.com
Hiesen Cyber Security | Hoisting Digital Fortresses Through the Storm hiesencyber.com