SAMA CSF Compliance: A Complete 2026 Guide for Saudi Banks
A practitioner's guide to SAMA CSF compliance in 2026 — scope, maturity model, governance, third-party depth, inspection expectations and how Saudi banks prepare.

The Saudi Arabian Monetary Authority Cyber Security Framework — universally referred to as SAMA CSF — is the single most load-bearing piece of cybersecurity regulation for any organisation supervised by the Saudi Central Bank. If you run a bank, insurer, finance company, payment service provider, money exchanger or credit bureau in Saudi Arabia, CSF is not optional, it is not a best practice and it is not a framework you can "align with". It is the yardstick SAMA measures you against, year after year, and your maturity rating has direct consequences for supervisory attention, product approvals and — in serious cases — enforcement.
This guide is a practitioner walkthrough of what CSF actually requires in 2026, where Saudi banks routinely lose points, and what a credible compliance programme looks like.
What SAMA CSF is, and why it exists
SAMA issued the Cyber Security Framework in 2017, drawing structural DNA from NIST CSF and ISO/IEC 27001 but layering Saudi-specific expectations on top. The framework is organised around four domains:
- Cyber Security Leadership and Governance
- Cyber Security Risk Management and Compliance
- Cyber Security Operations and Technology
- Third-Party Cyber Security
Each domain contains a set of subdomains and controls, and each control is assessed against a five-level maturity scale (non-existent, ad-hoc, repeatable, defined and managed, adaptive). Member organisations are expected to operate at a defined minimum maturity appropriate to their size, complexity and risk profile, and — critically — to show year-on-year improvement. Your second SAMA inspection is expected to look better than your first. Standing still is itself a finding.
The framework is deliberately principle-led rather than prescriptive. That is a trap for teams who try to implement CSF as a control checklist. SAMA's inspectors assess outcomes and evidence of real operation, not the mere existence of policies.
Scope: who has to comply
CSF applies to every organisation licensed or supervised by SAMA. In practice that means the full banking sector, the Saudi insurance and reinsurance market, finance companies, money exchangers, payment service providers (including the new wave of fintechs), credit information companies and the national payment infrastructure. Foreign bank branches operating in the Kingdom are in scope for their Saudi operations.
There is no employee or revenue threshold. A ten-person fintech licensed by SAMA carries the same framework obligation as a tier-one bank — but the expected maturity level and the depth of evidence are scaled to the organisation's size and risk. Smaller organisations should not assume they get a free pass; they should assume they are expected to be credible at a level appropriate to their licence.
The maturity model — where most programmes stumble
The single most misunderstood part of SAMA CSF is the maturity model. Teams arriving from ISO 27001 tend to treat CSF controls as binary — implemented or not implemented — and are surprised when the inspector rates a control at "repeatable" instead of "defined and managed".
The practical distinction matters. A bank that has a written incident response policy, a documented runbook and an on-call rota is at "defined" level. To reach "defined and managed", the same bank must also show that the runbook has been exercised in the last twelve months, that lessons learned were captured and fed back into the control, that key performance indicators are reported to management on a regular cadence, and that the evidence of all of this exists in a place an inspector can see without the team scrambling.
This is why Saudi banks that start their CSF journey on spreadsheets routinely struggle. The framework is winnable with spreadsheets — but the evidence, cadence, measurement and improvement loop are almost impossible to sustain without a unified platform.
Governance expectations that catch teams out
The Leadership and Governance domain of CSF is where first-time inspections produce the most findings. Three requirements are worth flagging specifically.
Board-level engagement is not a slide deck. SAMA expects the board to receive cyber security reports on a defined cadence, using metrics that are meaningful to a board audience, and for the board to demonstrably engage with the content. Minutes showing that cyber was "noted" are not sufficient. Inspectors look for evidence of challenge — questions asked, decisions made, budget approved, actions tracked.
The CISO must be independent of IT. This is one of the clearest prescriptive requirements in CSF. The CISO should report to the CEO, a Chief Risk Officer, or directly to a board committee — not to the CIO or Head of IT. Many Saudi banks that grew organically had their CISO sitting under the IT function; this has been a repeatable finding at first inspection and teams should address it before SAMA asks.
Roles and responsibilities must be documented and resourced. SAMA is explicit that cyber security roles should exist, be filled, and have defined accountability. A CSF self-assessment that lists a "Head of Threat Intelligence" role on paper but has nobody in the seat is worse than declaring the role as a gap and showing a plan to fill it.
Third-party cyber security — the deepest uplift
If ISO 27001 treats supplier security as a set of principle-led controls, SAMA CSF treats third-party cyber security as its own domain with a full lifecycle expectation: risk-based tiering at onboarding, mandatory contract clauses, ongoing monitoring, right-to-audit, incident notification obligations flowing down to suppliers, and the ability to demonstrate that the supplier operates at an appropriate cyber maturity. It also intersects with the SAMA Outsourcing Regulations, which add prior-approval requirements for material outsourcing arrangements.
In our experience working with Saudi banks, third-party depth is where roughly a third of the real CSF effort goes. The organisations that do it well maintain a single vendor inventory in their GRC platform, tagged by material/non-material, with controls inherited from the relevant CSF subdomains and evidence of monitoring attached to each vendor record.
Incident reporting — a Saudi-specific obligation
CSF requires member organisations to notify SAMA of significant cyber incidents within defined timeframes and through defined channels. ISO 27001 says nothing about regulator notification — this is a Saudi obligation layered on top, and it has operational implications: your incident response runbook must include an explicit decision point for SAMA notification, the criteria must be documented, and the handoff to the compliance/regulatory team must be rehearsed. Banks that discover this obligation during an actual incident are already behind.
A practical 2026 readiness roadmap
Based on the programmes we see running well in Riyadh and Dammam, a credible CSF readiness effort usually follows this arc:
Phase 1 — baseline and gap. Run a structured self-assessment against every CSF control, honest about current maturity. The output is not a score, it is a list of controls that need uplift, sequenced by risk.
Phase 2 — governance and policy uplift. Reposition the CISO if needed, formalise the board cyber report, rewrite the incident response runbook to include SAMA notification, and make sure the policy library has an owner and a review cadence.
Phase 3 — third-party and operations depth. Build the vendor lifecycle, instrument ongoing monitoring, tighten access management and privileged access, and make sure logging and monitoring produce evidence an inspector can read.
Phase 4 — evidence and measurement. Move every CSF control into a single platform where evidence is collected once and reported in CSF format. Start the improvement loop: KPIs, management reviews, actions tracked to closure.
Phase 5 — inspection rehearsal. Run a mock inspection using real inspector questions. Fix the things that surface.
Banks that start on a unified platform routinely complete this arc in six to nine months. Banks that start on spreadsheets take twelve to eighteen.
How GRC Vantage helps Saudi banks run CSF
GRC Vantage's compliance module ships with a pre-built SAMA CSF control library, mapped to ISO 27001, NCA ECC and NIST CSF so that evidence collected once satisfies every audience. The platform runs the CSF self-assessment, tracks maturity over time, produces the board cyber report from live data and manages the third-party lifecycle against CSF-tagged controls. It can be deployed inside Saudi Arabia to satisfy data residency expectations and is supported from our Riyadh and Dammam offices.
For the full picture of every framework SAMA issues — not just CSF — read our pillar guide on the SAMA framework family. If you are preparing for your next inspection, book a demo and we will walk through how Saudi banks use GRC Vantage to move from spreadsheet-based self-assessment to a live, defensible CSF programme.

The GRC Vantage team brings together compliance, risk, audit and business continuity practitioners based in Riyadh and Dammam. We help Saudi banks, government entities and regulated enterprises navigate the SAMA framework family, the NCA framework family, PDPL, ISO 27001 and ISO 22301.
Related articles
A factual comparison of SAMA CSF and NCA ECC — issuer, scope, structure, control counts, assessment methodology and how Saudi organisations run both frameworks together.
A step-by-step ISO 27001:2022 certification roadmap for Saudi organisations — scope, Annex A, Stage 1 and Stage 2 audits, and alignment with SAMA CSF and NCA ECC.
How SAMA CSF maps to ISO 27001 Annex A — what overlaps, what's Saudi-specific, and how to run one connected ISMS that satisfies both frameworks at once.