Saudi Arabia's financial regulator requires the institutions it supervises to implement a cybersecurity framework and report their maturity against it. Unlike a certification you pass, SAMA CSF scores how well established each control is, which means documentation and evidence matter as much as technology. This explains the structure, the maturity levels, and where infrastructure decisions actually bite.
SAMA CSF: the Cyber Security Framework issued by the Saudi Central Bank, which regulated financial institutions in the Kingdom are required to implement and to report their maturity against. It is a maturity model rather than a pass-or-fail certification, which changes how you approach it.
Accuracy note. Regulatory text changes and supervisory expectations move with it. This explains the framework's structure and what it asks of infrastructure, which is stable. Confirm the current requirements, thresholds and reporting cycle against SAMA's published text and your own supervisory correspondence. This is not legal advice.
Who Has to Comply
The framework applies to organisations SAMA regulates, which it calls Member Organizations. In practice that means banks, insurance and reinsurance companies, finance companies, credit bureaus, financial market infrastructures and payment service providers operating in the Kingdom.
If you are a technology supplier to one of those, you are not directly regulated, and you will still be asked to evidence controls, because the framework holds the Member Organization responsible for the cyber security of its third parties. That is the route by which SAMA CSF reaches hosting providers, software vendors and managed service firms.
The Four Domains
The framework is organised into four domains, and knowing which one a given requirement sits in tells you who in the organisation owns it.
| Domain | What it covers | Typical owner |
|---|---|---|
| Cyber Security Leadership and Governance | Strategy, governance structure, roles, policy, awareness, budget | Board and executive |
| Cyber Security Risk Management and Compliance | Risk methodology, regulatory compliance, audit, review cycles | Risk and compliance |
| Cyber Security Operations and Technology | Identity, access, network, cryptography, logging, monitoring, resilience, secure development | Technology and security operations |
| Third Party Cyber Security | Outsourcing, cloud, vendor due diligence and ongoing oversight | Procurement with security |
For anyone selecting or running infrastructure, the third and fourth domains are where the work lands. The first two are organisational and cannot be bought.
The Maturity Model
This is the part that distinguishes SAMA CSF from a checklist framework. Rather than asking whether a control exists, it asks how well established it is, on a scale from nothing to continuously improving.
| Level | Name | What it means in practice |
|---|---|---|
| 0 | Non-existent | No control at all |
| 1 | Ad-hoc | Something happens, inconsistently, depending on who is present |
| 2 | Repeatable but informal | Done consistently, but undocumented and dependent on individuals |
| 3 | Structured and formalized | Documented, approved, communicated and implemented |
| 4 | Managed and measurable | Measured, with metrics reported and acted upon |
| 5 | Adaptive | Continuously improved against threat intelligence and industry practice |
Member Organizations are expected to reach the structured and formalised level as a minimum across the framework, with higher maturity where risk warrants. Confirm the current expectation for your institution and its risk profile with your supervisor rather than assuming a single number applies to everything.
The practical consequence is the one people underestimate: the gap between level 2 and level 3 is documentation, approval and evidence, not technology. Organisations with genuinely good security frequently assess at level 2 because nobody wrote it down, approved it, or can produce a record showing it operated. That is a writing and governance problem, and it is the most common reason a maturity assessment disappoints.
How Assessment Works
Maturity is self-assessed against the framework and reported to SAMA on a periodic basis, and SAMA supervises the results. That means two things.
First, the assessment is only as good as the evidence behind it. Scoring yourself at level 3 without a policy document, an approval record and operational evidence is a finding waiting to happen.
Second, the trajectory matters as much as the score. A programme that shows measured improvement between cycles is a different supervisory conversation from one that reports the same gaps repeatedly.
What It Shares With Other Frameworks
SAMA CSF was written with reference to established standards, so most control objectives will look familiar to anyone who has implemented ISO 27001, the NIST Cybersecurity Framework or PCI DSS. That overlap is worth exploiting deliberately.
An existing ISO 27001 information security management system supplies much of the governance, risk and documentation apparatus the first two domains ask for. PCI DSS work covers a good deal of the payment-specific operational controls. Neither substitutes for SAMA CSF, because the maturity model and the reporting obligation are specific to it, but building a single control set mapped to several frameworks is far cheaper than running parallel programmes.
The same logic connects it to the other Saudi frameworks. NCA ECC is the national baseline that applies more broadly, and financial institutions frequently find themselves in scope for both. Our explainer on NCA Essential Cybersecurity Controls covers that structure, and building one control set that satisfies both is the efficient path.
Where Infrastructure Actually Matters
Most of the operations and technology domain reduces to infrastructure decisions and the evidence they generate. Concretely, you need to be able to show, with records rather than assertions:
Identity and access. Who has privileged access, how it was approved, when it was last reviewed, and multi-factor authentication on administrative paths.
Cryptography. Data encrypted in transit and at rest, with a documented key management practice and stated algorithms.
Logging and monitoring. Security-relevant events collected, retained for a defined period, protected from tampering, and actually reviewed by someone.
Resilience. Backup, tested restoration, documented recovery objectives, and a continuity plan that has been exercised rather than written.
Vulnerability and patch management. A defined cycle, evidence that it runs, and a record of exceptions with justification.
Change management. Changes approved, recorded and reversible.
Each of those is ordinary good practice. What the framework adds is the requirement to evidence it on demand, which is why the operational discipline matters more than the tooling.
The Third Party Domain and Cloud
This is the domain that determines what you may host, where, and with whom, and it is the one most likely to constrain a technology decision late in a project.
Expect to perform due diligence on the provider, hold contractual terms covering security, audit rights, incident notification and data handling, and monitor the arrangement over its life rather than at onboarding only. Expect also that material outsourcing arrangements attract specific regulatory expectations, which may include notifying SAMA or obtaining no objection before proceeding.
Two points worth raising early with whoever owns the project. Confirm the current outsourcing and cloud rules applicable to your institution before committing to a platform, because discovering a notification requirement after signing is expensive. And establish whether the data in question carries a residency obligation, because that question has a different answer from the control questions and it narrows the options considerably. Our guide to Saudi PDPL and data residency covers that side.
A Realistic Sequence
Assess current maturity honestly, per control, with evidence attached. An inflated baseline produces a remediation plan that solves the wrong problems.
Then close documentation gaps before buying anything, because that is where most of the distance between level 2 and level 3 lies and it is the cheapest ground to gain.
Then remediate technical gaps in risk order, keeping the evidence as you go rather than reconstructing it before the next assessment. Then establish the measurement that level 4 requires, if your risk profile calls for it, which means metrics somebody reviews on a schedule.
Infrastructure That Produces Evidence
Choosing a platform does not deliver SAMA CSF compliance, and any provider suggesting otherwise is describing something the framework does not contain. Compliance is organisational. What infrastructure can do is satisfy the technical control objectives and generate the evidence an assessment needs.
MassiveGRID's control environment is ISO 27001 certified with SOC 2 Type II audit coverage, and the platform provides encryption at rest and in transit, role-based access with multi-factor authentication, audit logging, and resilience through Proxmox high-availability clustering with automatic failover over Ceph triple-replicated storage. Those map onto the operations and technology domain directly, and the certifications shorten third-party due diligence.
One point to settle early, because it shapes the shortlist rather than the configuration. MassiveGRID deploys into partner facilities operated by Equinix, Digital Realty, Sparkle and NTT, a published footprint of more than 700 datacenters across 85 metros, 30 countries and six continents, and infrastructure can be ordered in any of them, so a deployment can be placed in the market your data has to sit in. Saudi Arabia is not among the metros currently listed on the datacenter page, and partner footprints change, so where data carries an in-Kingdom residency obligation, confirm current availability directly and treat colocation or a private cloud in a local facility as the fallback.
See the SAMA CSF infrastructure alignment, or read the hosting and infrastructure checklist for the control-by-control view.