SAMA Cyber Security Framework — the requirements people miss
Published 31 July 2026
Most summaries of the SAMA Cyber Security Framework describe its shape: four domains, 32 subdomains, a maturity model, target level 3. All true, and none of it tells you where member organisations actually fail their assessment.
The framework is principle-based, and the detail sits in the control considerations under each subdomain. Several of those are structural requirements about how your organisation is arranged — not what tooling you buy — and they are the ones that cannot be fixed the month before a SAMA review. This page works through them from the framework document itself.
Who this applies to
The framework applies to all member organisations regulated by SAMA: banks, insurance and reinsurance companies, financing companies and credit bureaus operating in Saudi Arabia, and the financial market infrastructure.
All domains apply to the banking sector. For other financial institutions the framework states specific exceptions, which are worth knowing because assessing yourself against controls you are excluded from wastes real effort:
- Subdomain 3.1.2 (alignment with the banking sector’s cyber security strategy) is mandatory when applicable.
- Subdomain 3.2.3 (compliance with international industry standards) is excluded — unless the organisation stores, processes or transmits cardholder data, or deals with SWIFT services, in which case PCI DSS and/or the SWIFT Customer Security Controls Framework should be implemented.
- Subdomain 3.3.12 (Payment Systems) is excluded.
The structural requirements that catch people out
These come from the control considerations under subdomain 3.1.1, Cyber Security Governance. They are organisational design requirements, and retrofitting them takes months.
The CISO must be a Saudi national. The framework states the member organisation should ensure the CISO has Saudi nationality and is sufficiently qualified. For international banks and insurers staffing regionally, this is a recruitment constraint, not a policy one.
The cyber security function must be independent of IT. Not “should collaborate with” — independent, with separate reporting lines, separate budgets, and separate staff evaluations, explicitly to avoid conflict of interest. If your CISO reports to the CIO, you do not meet this, and fixing it means changing an org chart.
It must report to the CEO or a control function head. The cyber security function should report directly to the CEO or managing director of the member organisation, or to the general manager of a control function.
The CISO must be full-time and at senior management level. A part-time or dual-hatted arrangement does not satisfy this.
The cyber security committee has a defined composition. It should be mandated by the board and headed by an independent senior manager from a control function. Representation should include senior managers from all relevant departments — the framework names the COO, CIO, compliance officer and heads of relevant business departments — plus the CISO. Internal audit may attend as an observer, which is a deliberate distinction: attending as observer preserves audit’s independence to later review the same programme.
The committee needs a charter and must meet at least quarterly. The charter should cover objectives, roles and responsibilities, the minimum number of meeting participants, and meeting frequency, with quarterly stated as the minimum.
Ultimate responsibility for cyber security rests with the board. The board can delegate to the committee or a senior manager, but not away.
What the maturity levels actually require
Compliance is measured against a six-level maturity model, and reaching levels 3, 4 or 5 requires first meeting all criteria of the preceding levels — you cannot skip.
| Level | Name | What it means in practice |
|---|---|---|
| 0 | Non-existent | No documentation; no awareness or attention to the control |
| 1 | Ad-hoc | Controls partially defined, executed inconsistently |
| 2 | Repeatable but informal | Standardised in practice but informal and unwritten; limited review or testing |
| 3 | Structured and formalized | Defined, approved, implemented; compliance monitored |
| 4 | Managed and measurable | Effectiveness periodically measured and evaluated; improvements documented |
| 5 | Adaptive | Continuous improvement; integrated with enterprise risk management |
Member organisations should operate at maturity level 3 or higher. That is the bar, and it is worth being precise about what level 3 demands: cyber security controls defined, approved and implemented in a structured and formalised way, with the implementation demonstrable, and compliance with the cyber security documentation monitored. The framework notes that this monitoring is preferably done using a governance, risk and compliance tool, and that key performance indicators should be defined, monitored and reported.
That sentence is the reason most member organisations end up buying GRC tooling: level 3 is not achievable on spreadsheets at scale, because you have to demonstrate ongoing monitoring rather than a point-in-time state.
Level 4 adds measurement. Effectiveness of controls must be periodically assessed and improved, with the measurement and evaluation documented. Key risk indicators should be defined — a KRI indicates the norm for effectiveness measurement and should define thresholds determining whether the actual result is below, on, or above the target, and is used for trend reporting and identifying improvements.
Level 5 adds continuous improvement. Controls subject to a continuous improvement plan, integrated with enterprise risk management practices, supported by automated real-time monitoring, with business process owners accountable for monitoring compliance and measuring effectiveness. Performance is evaluated using peer and sector data.
The documentation pyramid
The framework is explicit about what “cyber security documentation” means, and assessments check for all three layers:
- Policy — endorsed and mandated by the board, stating why cyber security matters, which information assets must be protected, and what principles and objectives apply.
- Standards — derived from the policy, defining what must be implemented: security and system parameters, segregation of duties, password rules, event monitoring, backup and recovery rules. These are the baselines.
- Procedures — the step-by-step tasks describing how controls are executed by staff, third parties or customers.
A programme with a policy and no standards fails this, however good the policy is.
How compliance is measured
Implementation is subject to a periodic self-assessment, performed by the member organisation using a questionnaire. Those self-assessments are then reviewed and audited by SAMA to determine the level of compliance and the organisation’s cyber security maturity level. The framework is also used to compare maturity across member organisations — so your result is not assessed in isolation.
Where a control consideration genuinely cannot be tailored or implemented, the framework’s own route is to apply compensating controls, pursue an internal risk acceptance, and request a formal waiver from SAMA. Silently not implementing it is not one of the options.
The relationship with NCA ECC
Most Saudi financial institutions are in scope for both the SAMA CSF and the NCA’s Essential Cybersecurity Controls, which are issued by different authorities with overlapping subject matter. They are not interchangeable: SAMA CSF is principle-based and maturity-assessed, while the ECC is control-based and assessed on implementation. A single control implementation can serve both, but the evidence each expects differs — SAMA wants demonstrated maturity over time, the NCA wants implementation against a specified control.
If you are running both, map them once to a shared control set rather than maintaining two libraries. That is the single biggest efficiency available to a Saudi bank’s compliance function, and it is what cross-framework mapping is for.
Next steps
Work through your position across all 32 subdomains with our free SAMA CSF maturity self-assessment, which uses SAMA’s own six-level model and shows your gap to the required level 3. For platforms that maintain SAMA control libraries and evidence continuously, see the compliance software comparison and our GRC platform rankings.
Source
Saudi Arabian Monetary Authority, Cyber Security Framework, Version 1.0. Structure, maturity model and control considerations are taken from that document. This page summarises them in plain English and adds our own commentary on where organisations typically fall short — for compliance purposes, work from the official framework.
Part of our SAMA CSF framework hub, which covers the structure, scope and assessment mechanism alongside every resource we publish on it.