SAMA vs NESA: A Dual-Compliance Playbook for GCC Financial Institutions

Key takeaways

• GCC banks now answer to SAMA, NCA, TDRA, SIA, CBUAE and the UAE Cybersecurity Council — six authorities, overlapping but incompatible control catalogues. Mobile is where the gaps surface fastest.
• SAMA Cyber Security Framework v1.0 (May 2017) is the working standard for Saudi banks, insurance companies and finance companies, with a 6-level maturity model. The UAE side is governed by UAE IA Regulation v1.1 (March 2020) administered by SIA / TDRA, plus CBUAE Notice 2025/3057 for client-side banking controls.
• The Rosetta Stone for unifying both is OWASP MASVS v2.1 — every SAMA mobile control and every NESA / UAE IAR mobile control maps to one or more MASVS control groups.
• This playbook gives you the mapping, the SAMA-specific traps for UAE-primary teams, the NESA-specific traps for KSA-primary teams, and a single-pipeline architecture that produces dual evidence.

If your bank operates in both Saudi Arabia and the UAE, your mobile security programme is being measured against six regulatory authorities with overlapping but incompatible control catalogues. The temptation is to run two separate programmes — one Saudi-facing, one UAE-facing — and accept the duplicated cost. The better answer is to run one programme with two evidence views.

This is the playbook for that programme.

Three drivers in 2025–2026.

The Saudi-UAE banking corridor is real and growing. Saudi banks expanded UAE retail and investment banking presence; UAE banks deepened Saudi commercial and corporate banking under Vision 2030 mandates. SAMA Open Banking (initiated 2022) and the UAE’s Open Finance Nebras hub (launched 2024) further accelerate cross-border product development.

Mobile is the cross-border surface. A bank with cross-border customers ships one mobile app — sometimes two regional variants on the same codebase. Either way, the app must satisfy both regulator sets simultaneously. There is no “Saudi build” and “UAE build” of the same release.

Audit timelines are converging. SAMA expects continuous evidence under its CSF maturity model. NESA / UAE IAR audits are tightening per the 2025 National Cybersecurity Strategy update. CBUAE’s 2025 Consumer Protection Notice (2025/3057) added client-side banking controls with enforcement deadlines through 2026. Running a single programme cuts the audit-prep duplication by 30–50%.

SAMA Cyber Security Framework v1.0, issued May 2017, mandatory for Saudi banks, insurance companies, finance companies, payment service providers, credit bureaus and regulatory sandbox participants. The framework has four domains and a 6-level maturity model (0 to 5). All domains are applicable for the banking sector.

NCA ECC (Essential Cybersecurity Controls) for any Saudi entity processing data subject to Saudi national security oversight. ECC-1:2018 is the current published baseline. CSCC (Critical Systems Cybersecurity Controls) and CCC (Cloud Cybersecurity Controls) layer on top for relevant systems.

Saudi Personal Data Protection Law (PDPL) for personal data processing — overlaps with both frameworks above on data security obligations.

UAE IA Regulation v1.1, March 2020, administered by SIA (formerly NESA) with operational oversight by TDRA. Mandatory for federal and local government, CII operators, and (since the 2025 strategy update) supply-chain participants serving these entities.

CBUAE Notice 2025/3057 on consumer protection in financial services. Adds client-side banking app controls including phase-out of SMS/email OTP after 31 March 2026, mandatory RAT detection, screen-share session-kill, geofencing of high-risk transactions.

New CBUAE Law (Federal Decree 6/2025) raises maximum administrative fines to AED 1 billion and brings enabling technology providers into the licensing perimeter.

UAE PDPL (Federal Decree-Law 45/2021) for personal data processing.

Dubai DESC (Dubai Electronic Security Centre) for entities operating in the Dubai emirate, with sector-specific cyber requirements layered on top of federal IAR.

Six authorities, four primary regulator catalogues per side. Without a unifying technical framework, the mobile team faces an impossible audit translation problem.

OWASP MASVS v2.1 has eight control groups: STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE, PRIVACY. These eight groups can be mapped to both SAMA CSF mobile-relevant controls and UAE IAR mobile-relevant controls without losing fidelity in either direction.

The mapping (condensed, mobile-relevant controls only):

MASVS v2.1 group	Maps to SAMA CSF	Maps to UAE IAR (IAS)	Maps to CBUAE 2025/3057
MASVS-STORAGE	3.3 Cyber Security Operations & Tech	T6 Info Sys Acquisition / Dev	Sensitive customer data handling
MASVS-CRYPTO	3.3, 3.4 Third-Party	T6, T4 Comms & Ops Mgmt	Strong crypto for transactions
MASVS-AUTH	3.3.7 Identity & Access Management	T5 Access Control	OTP/2FA evolution, biometric
MASVS-NETWORK	3.3.10 Network Security	T4 Comms & Ops	Secure channel
MASVS-PLATFORM	3.3.6 Application Security	T6, T7	Client-side hardening
MASVS-CODE	3.3.6 Application Security	T6	Secure SDLC
MASVS-RESILIENCE	3.3.13 Electronic Banking Services	T7	RAT detection, anti-tamper
MASVS-PRIVACY	3.3.7, plus PDPL alignment	T9 Compliance + UAE PDPL	Customer data protection

A single scan against MASVS v2.1 produces evidence applicable to both regulator catalogues. The translation is in the report mapping, not in the scan. This is what HEXMobileSuite is built around — see [link to /sama-compliance] and [link to /nesa-compliance] for the per-regulator mapping packs.

If your bank’s primary entity is UAE-incorporated and you’ve recently entered Saudi, six SAMA expectations consistently catch UAE-primary teams off guard.

1. Maturity model expectations are higher. SAMA’s 6-level maturity model expects most controls at Level 3 (“defined and operational”) or above for licensed banks. UAE IAR is binary (compliant / not compliant per control with priority tiers); SAMA wants you to demonstrate the maturity of the programme, not just the presence of controls. Documentation, KPIs and trending matter more in Saudi than in the UAE for the same control area.

2. Source code escrow / source code access is an explicit expectation. SAMA’s framework (and the 2024 RBI directions echo this for Indian non-bank PSOs) expects regulated entities to either obtain source code or have escrow for critical applications. UAE IAR is silent on this. UAE-primary teams entering Saudi often discover this requirement during procurement bake-offs.

3. PCI-DSS / SWIFT CSCF integration is non-optional. SAMA explicitly excludes sub-domain (3.2.3) on payment card industry compliance from its core framework — but redirects to PCI-DSS or SWIFT CSCF where the entity touches that data. The integration is your responsibility. UAE-primary teams who treat PCI-DSS as a separate exercise discover this is a SAMA evidence requirement.

4. Local data residency is more strictly enforced. While both jurisdictions have data residency regimes, SAMA’s enforcement on cross-border data transfer for personal banking data is more frequent and more documented. Cloud architecture decisions made for UAE deployment may need re-architecture for Saudi.

5. Vendor lock-in language matters. SAMA expects regulated entities to have demonstrable vendor exit plans for critical IT services. The UAE is moving in this direction but is less prescriptive. This affects your MAST vendor choice — vendor lock-in risk is a SAMA evaluation criterion.

6. Incident communication formality is higher. SAMA notification expectations come with prescribed formats and structured communication channels. UAE notification (under IAR and PDPL) is more flexible. UAE-primary teams used to less-prescribed reporting often produce SAMA-compliant content in a non-SAMA-compliant format.

The reverse direction has its own traps for Saudi-primary banks entering the UAE.

1. Multiple authority chains. SAMA is the single answer to most cybersecurity questions in Saudi banking. In the UAE, you answer to TDRA (operational oversight), SIA (information assurance), CBUAE (consumer protection in financial services), DESC if Dubai-based, the UAE Cyber Security Council strategically — six different stakeholders, each with their own focus.

2. CBUAE Notice 2025/3057 client-side controls. Saudi-primary teams sometimes assume they’ve covered banking client-side security under SAMA. CBUAE 2025/3057 has explicit additional client-side requirements for banking apps in the UAE: phase-out of SMS/email OTP by 31 March 2026, mandatory RAT detection, screen-share session-kill, geofencing controls. These are not in SAMA CSF.

3. The Information Assurance Standards (IAS) detail level. UAE IAS goes deeper into specific sub-control implementation than SAMA CSF in some areas (particularly cloud security and BYOD). Saudi-primary teams used to SAMA’s broader principle-based controls find UAE IAS requires more granular per-sub-control evidence.

4. The new CBUAE Law (Federal Decree 6/2025) brings enabling tech providers into the perimeter. SAMA’s framework has third-party expectations but doesn’t formally license technology providers. UAE Federal Decree 6/2025 (effective 2025) brings enabling technology providers serving licensed banks into the licensing perimeter, with maximum admin fines up to AED 1 billion. Saudi-primary teams discover during UAE vendor procurement that this changes the contracting reality.

5. Federal Decree-Law 34/2021 on cybercrime intersects. UAE has explicit criminal provisions for cyber-related failures of duty by responsible parties. SAMA enforcement is administrative. UAE-primary CISOs sometimes carry personal exposure that Saudi-primary CISOs may not be used to managing.

6. Public PDPL enforcement is at an earlier stage in UAE than in Saudi. Both PDPLs are in force. Enforcement maturity differs. UAE PDPL implementing regulations have been incrementally clarified; Saudi PDPL has had more concrete enforcement actions to date. Saudi-primary teams may underestimate UAE PDPL precisely because there’s less public enforcement to point at.

The architecture that works:

Layer 1 — One scanning engine, one rule library.

A single MAST platform scanning against MASVS v2.1 (and OWASP Mobile Top 10 2024 simultaneously). One CI/CD integration per engineering team. One scan rule version per release.

Layer 2 — Two evidence views.

The same scan output rendered into two report packs:

• SAMA CSF mapping pack (SAMA-relevant control IDs, maturity level annotations, PCI-DSS / SWIFT CSCF cross-references where relevant)
• UAE IAR / NESA + CBUAE mapping pack (IAS control IDs, CBUAE 2025/3057 client-side control coverage, UAE PDPL data flow annotations)

Layer 3 — Three audit cycles.

The same evidence pack supports three audit cycles:

• SAMA review (typically annual full + quarterly check-ins for higher-maturity entities)
• NESA / UAE IAR review (annual)
• Internal audit and Board reporting (quarterly)

Layer 4 — One incident response plan with parallel notification.

A single incident response runbook that triggers parallel notification to SAMA, CBUAE, TDRA / SIA, CERT-UAE / aeCERT, and any other relevant regulator depending on the incident scope.

This architecture is the working model in 2026 for several large GCC banks running cross-border operations. The savings vs running two separate programmes are real: typically 30–50% reduction in audit-prep effort, 40–60% reduction in tooling cost, and a meaningfully shorter time-to-evidence for novel audit questions.

The audit evidence each regulator expects, presented in parallel:

Evidence type	SAMA expects	NESA / UAE IAR expects
Per-release security scan	Yes, with maturity-level evidence	Yes, with IAS control mapping
SBOM	Increasingly expected; explicit in 2024 RBI directions for Indian alignment	Expected for T6 / T9
Cryptography inventory	Yes, with rotation evidence	Yes
SDK / supplier risk review	Yes, with vendor exit plan	Yes, less prescriptive on exit
Client-side anti-fraud controls	Yes (Electronic Banking Services 3.3.13)	Yes (CBUAE 2025/3057 explicit)
Incident response evidence	Yes, with prescribed formats	Yes, with timing per IAR
BCP / DR for mobile pipeline	Yes (operational resilience)	Yes (T8)
Source code access / escrow	Yes (explicit)	Implicit
Continuous monitoring of published version	Increasingly expected	Increasingly expected

The evidence formats differ. The underlying technical signal — produced by a continuous mobile testing platform — is the same.

A working calendar for a dual-jurisdiction GCC bank with mobile assets:

• Monthly: internal mobile security KPI review (scan coverage, finding age, remediation MTTR)
• Quarterly: cross-regulator evidence pack regeneration; Board / Risk Committee report; SAMA quarterly check-in (where applicable for higher-maturity entities); CBUAE supervision dialogue
• Semi-annually: full SAMA CSF maturity self-assessment; UAE IAR gap analysis; integrated PCI-DSS / SWIFT CSCF status update
• Annually: external SAMA audit; external NESA / UAE IAR audit; external PDPL audit (both jurisdictions); annual board attestation
• Event-driven: incident response and parallel notification; new CBUAE / SAMA / TDRA notice triage; new threat-intelligence-driven control review

The annual external audits should ideally be sequenced so the SAMA evidence pack and the NESA evidence pack are generated from the same underlying scan baseline — synchronised, not separate.

The platform is built specifically for this dual / multi-regulator pattern.

• MPTL rule engine — 124 rules mapped to MASVS v2.1 + Mobile Top 10 2024 simultaneously
• Regulator mapping packs — SAMA CSF, NCA ECC, UAE IAR / NESA, CBUAE 2025/3057, RBI ITG-RC&AP, CERT-In, DPDP Rules, PCI MPoC included on Pro and Enterprise tiers
• Dual-view reports — same scan, multiple regulator-specific PDF outputs, signed and dated per release
• Maturity-level annotations — for SAMA-specific reports, findings tagged with maturity-level implications
• CI/CD integrations — GitHub Actions, GitLab CI, Bitbucket Pipelines, Azure DevOps
• Continuous Play Store / App Store monitoring — catches post-release SDK changes that affect both regulator views
• Multi-tenancy — for GCC MSSPs serving multiple banks, white-label deployment with per-client tenancy

See [link to /sama-compliance] and [link to /nesa-compliance] for the regulator-specific mapping documentation.

If you operate a GCC bank with cross-border presence:

1. Audit the duplication. How many separate evidence cycles are you currently running for SAMA vs NESA vs CBUAE on mobile? If the answer is more than one, there is consolidation value.

2. Map your current controls to MASVS v2.1. Use the table earlier in this post as a starting point. Identify the controls where you have evidence in one jurisdiction but not the other.

3. Verify CBUAE 2025/3057 readiness. The 31 March 2026 SMS/email OTP phase-out has hard-deadline implications. RAT detection, screen-share session-kill and geofencing controls require client-side engineering work. Confirm where you are.

4. Run a dual-mapped scan. [link to /free-scan] — 30 minutes, signed PDF with both SAMA and NESA mapping packs. See what your current production app looks like in both views simultaneously.

5. Brief the audit committee. The strategic story is “one programme, two views, lower cost, faster audits.” Get this on the agenda before the next external review cycle starts.

The dual-jurisdiction GCC bank is a structurally complex compliance entity. The complexity is not going away. The teams that build a single technical pipeline that produces dual evidence will spend the next decade with smoother audits and lower running costs than the teams that maintain two parallel programmes.

---

HEXMobileSuite produces SAMA-mapped and NESA-mapped reports from the same scan baseline, signed and dated per release. Dual compliance pack included on Pro and Enterprise tiers. Try free at hexmobsuite.hiesencyber.com.