SAMA Cybersecurity Framework: Compliance Guide for Saudi Financial Institutions (2026)

Most financial institutions in Saudi Arabia know they need to comply with SAMA. Fewer understand what compliance actually requires, how maturity is measured, how long it takes, and critically how it differs from other frameworks like ISO 27001 or NESA.

This guide answers those questions directly. It covers what the SAMA Cybersecurity Framework is, which entities it applies to, what the six maturity levels mean in practice, how a gap assessment works, and what reaching Level 3 actually looks like for a bank, insurance company, or fintech licensed in the Kingdom.

If you operate under SAMA supervision and are trying to understand where you stand or how to build a credible compliance roadmap, this is the guide to start with.

1. What Is the SAMA Cybersecurity Framework?
2. Who Does It Apply To?
3. The Four Control Domains
4. The Six Maturity Levels Explained
5. What Does a SAMA Gap Assessment Look Like?
6. How Long Does SAMA Compliance Take?
7. SAMA vs ISO 27001: Do You Need Both?
8. SAMA vs NESA: Which Applies to You?
9. How Penetration Testing and Red Teaming Fit In
10. Reaching Level 3: A Practical Roadmap
11. Common Compliance Failures — and How to Avoid Them
12. How SecurityWall Supports SAMA Compliance

What Is the SAMA Cybersecurity Framework?

The SAMA Cybersecurity Framework (CSF) was published by the Saudi Arabian Monetary Authority in May 2017. It exists for one purpose: to ensure that financial institutions regulated by SAMA can identify, manage, and withstand cybersecurity threats in a way that is measurable, consistent, and comparable across the sector.

The framework is not optional. It is mandatory for all SAMA-regulated entities, and compliance is enforced through periodic supervisory reviews, self-assessments, and onsite SAMA inspection visits. Non-compliance carries enforcement consequences that can include operational restrictions, fines, and reputational damage.

The framework draws from established international standards including NIST, ISO 27001, PCI-DSS, BASEL, and ISF and adapts them to the specific risk context of the Saudi financial sector. It does not replace those standards. It sits alongside them, often requiring similar controls with a Saudi regulatory overlay.

It is structured around four primary control domains, a six-level maturity model, and a mandatory minimum maturity threshold of Level 3 for all Member Organizations.

Who Does It Apply To?

The SAMA CSF applies to all entities regulated by the Saudi Central Bank. This includes:

• Commercial banks operating in Saudi Arabia, including foreign branches
• Insurance and reinsurance companies
• Financing companies (consumer finance, mortgage, leasing)
• Credit bureaus
• Financial market infrastructures — payment systems, clearinghouses, securities depositories
• BNPL - Buy Now Pay Later Apps, and Financing software firms
• Fintech companies under SAMA oversight
• Technology service providers that directly support SAMA-regulated entities

The last category is frequently overlooked by smaller technology firms. If your platform processes transactions, stores financial data, or provides infrastructure for a SAMA-regulated bank or fintech you may fall within scope even without direct SAMA licensing.

For entities operating in both Saudi Arabia and the UAE, the UAE has a parallel framework: NESA (National Electronic Security Authority), which applies to critical infrastructure sectors including financial services. If you operate in both jurisdictions, you may need to demonstrate compliance with both. We address the overlap in the SAMA vs NESA section below.

The Four Control Domains

The SAMA CSF organizes its requirements into four core domains. Each domain contains sub-domains, which contain individual controls. Controls are assessed against the maturity model, which scores them on a scale of 0 to 5.

Domain 1: Cyber Security Leadership and Governance

This domain addresses board-level and executive accountability for cybersecurity. Requirements include establishing a cybersecurity committee, defining a CISO role, publishing a cybersecurity strategy aligned to the institution's risk appetite, and ensuring the board receives regular cybersecurity reporting.

At Level 3, institutions are expected to have formal, approved documentation — not just informal awareness. The board must be accountable, not just informed.

Domain 2: Cyber Security Risk Management and Compliance

This domain covers the processes used to identify, assess, and manage cybersecurity risk. It includes requirements for risk classification, third-party risk management, compliance monitoring, and regulatory reporting.

Third-party risk is particularly significant here. SAMA expects institutions to extend their cybersecurity requirements to vendors, outsourcing partners, and cloud service providers. SAMA approval is required before using cloud services, and regular security audits of cloud providers are expected at Level 3 and above.

Domain 3: Cyber Security Operations and Technology

This is the broadest domain and covers the technical controls that protect systems, data, and services. Sub-domains include:

• Asset management and classification
• Identity and access management
• Vulnerability management
• Incident detection and response
• Network security and segmentation
• Cryptography and data protection
• Secure development and change management
• Business continuity and disaster recovery

Penetration testing sits within this domain. SAMA expects institutions to conduct regular, structured penetration testing as evidence that technical controls are functioning not just documented. This is distinct from a vulnerability scan. The distinction matters during supervisory reviews. For a detailed look at how SAMA evaluates penetration testing evidence, see our guide on SAMA penetration testing: common mistakes by banks.

Domain 4: Third-Party Cybersecurity

Reflecting the increasing use of outsourcing and cloud infrastructure in Saudi financial services, this domain specifically governs relationships with external service providers. Requirements include due diligence before onboarding, contractual security obligations, regular assessments of third-party security posture, and incident notification requirements.

The Six Maturity Levels Explained

The SAMA maturity model is the mechanism by which the framework is assessed and enforced. Every control in the framework is scored against one of six maturity levels:

Level 3 is the regulatory minimum. SAMA's published circulars require all Member Organizations to achieve Level 3 as a baseline. SAMA has also communicated expectations for specific sub-domains particularly around banks to reach Level 4 in areas such as threat intelligence, access control, and incident response.

Progression is sequential. You cannot claim Level 3 on a control without first meeting Levels 1 and 2. SAMA assessors specifically look for this evidence chain during reviews.

What Level 3 Actually Requires

Achieving Level 3 is not just about having policies. At Level 3, SAMA expects:

• A formal, board-approved cybersecurity policy
• Cybersecurity standards and procedures that operationalize the policy
• Defined roles and responsibilities, including a designated CISO
• Evidence that controls are being implemented consistently (not just documented)
• Compliance monitoring active tracking of whether controls are being followed
• Regular self-assessments against the framework

Many institutions have documentation that appears comprehensive but fails Level 3 review because there is no evidence of consistent implementation or monitoring. The controls must be working, not just written.

What Does a SAMA Gap Assessment Look Like?

A gap assessment is the mandatory first step in any SAMA compliance journey. SAMA's circulars explicitly require institutions to conduct an "in-depth and accurate assessment of the current status of cybersecurity" before developing a compliance roadmap.

In practice, a gap assessment for the SAMA CSF involves:

Phase 1: Scoping and context mapping The assessment team maps the institution's business lines, systems, and services to determine which SAMA sub-domains are applicable. Some sub-domains have carve-outs for non-banking entities insurance companies and financing firms have slightly different applicability profiles than commercial banks.

Phase 2: Control assessment against the maturity model Each applicable control is reviewed against the six maturity levels. Evidence is collected: policies, procedures, screenshots, interview responses, configuration records, audit logs. The goal is to establish the current maturity level of each control with supporting evidence not to document what the institution intends to do.

Phase 3: Gap identification and scoring Controls assessed below Level 3 are flagged as gaps. The assessment produces a quantified view of how many controls are at Level 0–2 versus Level 3+, and which domains carry the most significant remediation burden.

Phase 4: Roadmap development Based on the gap findings, a prioritized remediation roadmap is developed. The roadmap must address all Level 3 gaps, sequence implementation realistically, assign ownership, and be approved by the Board of Directors.

SAMA requires that this roadmap be submitted to the Board for approval and then sent to SAMA directly. It also requires quarterly progress reports until full compliance is achieved.

The timeline for a gap assessment varies by institution size and complexity. For a mid-sized bank or insurance company, expect four to eight weeks of active assessment work. For a smaller fintech, a focused assessment can be completed in two to four weeks.

How Long Does SAMA Compliance Take?

This is one of the most common questions from fintech startups and new licensees operating in Saudi Arabia. The answer depends on your starting maturity and the gap depth, but there are realistic reference points.

For a new fintech with minimal pre-existing controls starting at Level 0 or Level 1 across most domains reaching Level 3 typically takes nine to eighteen months of active implementation. This includes policy development, technical control implementation, training, and the evidence accumulation required to support a Level 3 claim.

For a financial institution with ISO 27001 or SOC 2 certification already in place significant overlap exists between those frameworks and SAMA requirements. These institutions can often reach Level 3 in four to nine months by mapping existing controls to SAMA sub-domains and filling the gaps rather than rebuilding from scratch.

For a bank undergoing its first SAMA supervisory review if you have already been operating under SAMA supervision but have not formally assessed your maturity, expect a gap assessment to reveal significant variance across domains. Remediation timelines of twelve to twenty-four months are common for large institutions with legacy systems and complex governance structures.

The most expensive mistake institutions make is beginning implementation without a gap assessment. Institutions that skip straight to buying tools or writing policies frequently discover during their first SAMA review that their effort was misdirected controls that appeared strong were not at Level 3, while major gaps existed in areas they had not prioritized.

SAMA vs ISO 27001: Do You Need Both?

Yes in most cases. But understanding why clarifies what each framework is actually doing.

ISO 27001 is an internationally recognized information security management system (ISMS) standard. Certification requires an external audit by an accredited certification body. ISO 27001 is voluntary unless required by contracts, procurement requirements, or specific regulatory mandates.

SAMA CSF is a mandatory regulatory framework specific to the Saudi financial sector. SAMA is the assessor, not a third-party certification body. There is no ISO 27001-style certificate issued by SAMA compliance is demonstrated through self-assessments and supervisory reviews.

The overlap is real and significant. Many of SAMA's technical controls align closely with ISO 27001 Annex A controls. If you hold an active ISO 27001 certification, you have already done substantial work that maps to SAMA requirements. The gap is typically in the Saudi-specific governance requirements board accountability, CISO designation, SAMA-specific reporting, and the third-party risk requirements that reflect SAMA's supervisory authority.

The practical recommendation for Saudi financial institutions: pursue SAMA compliance as the primary regulatory requirement, and use ISO 27001 as a complementary certification that demonstrates international credibility and strengthens your evidence base for SAMA reviews. The two are not competitors they are complementary.

SAMA vs NESA: Which Applies to You?

SAMA applies to financial institutions in Saudi Arabia. NESA (the National Electronic Security Authority framework) applies to critical information infrastructure in the UAE. If you operate in only one jurisdiction, the answer is straightforward.

If you operate in both Saudi Arabia and the UAE a common profile for regional banks, insurance groups, and fintech platforms you face dual obligations. SAMA applies to your Saudi operations; NESA applies to your UAE operations. The two frameworks have structural similarities but are administered by different regulators and assessed on different cycles.

The controls overlap substantially. An institution that has implemented SAMA-aligned controls will find many of the same domains covered by NESA. The main differences are:

• Governance and reporting: Different escalation paths, different supervisory contacts, different self-assessment formats
• Third-party and cloud requirements: SAMA requires SAMA approval for cloud services; NESA has its own classification and approval process for UAE-hosted data
• Assessment cycles: SAMA and NESA operate on separate review timelines; compliance evidence must be maintained for both

For a deeper introduction to NESA requirements and how an assessment works in the UAE, see our NESA compliance guide and the NESA audit and assessment process overview.

The key principle for dual-jurisdiction institutions: build your compliance program with both frameworks in mind from the beginning. Retrofitting a SAMA-only program for NESA later is significantly more costly than designing for both from day one.

How Penetration Testing and Red Teaming Fit In

Penetration testing is not optional under SAMA it is explicitly expected as evidence that technical controls are functioning. SAMA assessors specifically evaluate whether testing was scoped appropriately, performed by qualified practitioners, and produced evidence that stands up to regulatory scrutiny.

The most common failure mode is institutions treating penetration testing as a checkbox running a generic scan, receiving a report, and filing it without any remediation follow-through. SAMA reviewers are experienced enough to identify this pattern. The evidence they want to see is not just a report it is evidence that findings were addressed and controls were verified as functioning after remediation.

For a detailed treatment of how SAMA evaluates penetration testing evidence and where most institutions go wrong, see our dedicated guide on SAMA penetration testing common mistakes.

At higher maturity levels particularly for institutions working toward Level 4 and above red teaming becomes relevant. Red team exercises simulate end-to-end adversary behavior, testing not just whether controls are in place but whether they would detect and contain a real attacker. SAMA has increasingly incorporated red team exercises into its supervisory framework for Tier-1 banks and systemically important institutions.

The distinction between penetration testing and red teaming is important in the SAMA context. Penetration testing satisfies baseline control effectiveness evidence requirements. Red teaming addresses detection and response capabilities the question of whether your security operations team would catch an attacker who has already bypassed perimeter controls. Both are valuable; they are not interchangeable.

For institutions working toward mature SAMA posture particularly those seeking Level 4 compliance or preparing for supervisory engagement our guide on SAMA red teaming for Saudi banks and fintechs covers how adversary simulation fits the SAMA supervisory framework.

For institutions running cloud infrastructure, cloud environments require specific scoping in penetration testing engagements. AWS, Azure, and GCP infrastructure have attack surfaces that standard application testing does not cover. See our cloud penetration testing guide for a detailed overview of what cloud-scoped testing covers and what SAMA requires.

Reaching Level 3: A Practical Roadmap

Common Compliance Failures — and How to Avoid Them

After supporting SAMA-regulated entities through compliance assessments and remediation programs, the failure patterns that appear most consistently are:

Treating documentation as compliance. Having a policy does not mean the control is implemented. SAMA assessors verify evidence of consistent implementation, not just the existence of a policy document. If you cannot produce implementation evidence, the control will be scored below Level 3.

Scoping penetration testing too narrowly. Institutions frequently test their public-facing web application and call it complete. SAMA-aligned testing should cover the full regulated service environment including APIs, internal networks, mobile applications, and cloud infrastructure. Gaps in scope become gaps in compliance evidence.

Underestimating third-party requirements. The third-party domain is often the most underdeveloped area in new compliance programs. SAMA expects security requirements to flow through vendor contracts, security assessments to be conducted regularly, and cloud service adoption to receive explicit SAMA approval. Many institutions discover late that multiple cloud services in use have never been formally assessed or disclosed.

Ignoring the board accountability requirements. SAMA's governance requirements are substantive. The board must be actively engaged with cybersecurity — receiving reports, approving policy, and overseeing the CISO function. Institutions where cybersecurity is entirely delegated below executive level without board visibility will fail this domain regardless of their technical controls.

Delaying the gap assessment. Institutions that begin implementing controls without a gap assessment frequently over-invest in areas that are already at Level 3 and under-invest in the areas with the largest gaps. The gap assessment is not bureaucracy it is the prerequisite for efficient remediation.

How SecurityWall Supports SAMA Compliance

SecurityWall has supported SAMA-regulated financial institutions including banks, insurance companies, and licensed fintech firms through gap assessments, remediation programs, and supervisory preparation.

Our SAMA compliance work is structured around the same principles that inform our penetration testing practice: regulatory outcomes, not just technical deliverables.

For SAMA gap assessments, we assess every applicable sub-domain against the maturity model, produce a scored gap register, and develop a prioritized roadmap structured for Board approval and SAMA submission. We have a direct understanding of how SAMA assessors evaluate evidence which means we help institutions build a compliance posture that stands up to regulatory scrutiny, not just internal review.

For penetration testing aligned to SAMA requirements, our engagements are scoped to the full regulated service environment, conducted by certified practitioners, and structured to produce evidence that satisfies SAMA's expectations for control effectiveness demonstration. Our team holds OSCP, OSWE, CISSP, CREST, CRT, CISM, and GPEN credentials.

For institutions working toward Level 4 and red team readiness, we offer adversarial simulation engagements specifically calibrated to the SAMA supervisory framework testing detection and response capabilities in addition to prevention controls.

Explore our SAMA compliance services →

Related Reading

• SAMA Penetration Testing: Common Mistakes by Banks — How SAMA evaluates penetration testing evidence and where most institutions go wrong
• SAMA Red Teaming in Saudi Arabia — Adversary simulation for Tier-1 banks and fintechs under SAMA supervision
• What Is NESA Compliance in the UAE? — The UAE's parallel regulatory framework for critical infrastructure
• NESA Compliance Checklist — Step-by-step readiness guide for UAE organisations
• NESA Audit and Assessment Process — What to expect from a NESA regulatory review
• Assumed Breach Testing — How assumed breach testing supports Level 4 SAMA maturity
• Cloud Penetration Testing: AWS, Azure & GCP — Cloud-scoped testing for SAMA-regulated institutions
• Cybersecurity in 2026: WEF Warnings — The threat landscape context for SAMA's resilience-first direction

SecurityWall provides SAMA compliance gap assessments, penetration testing, and red team services for financial institutions across Saudi Arabia and the UAE. Our team holds active offensive security and governance certifications including OSCP, OSWE, CISSP, CREST, CRT, and CISM.