Compliance guide · Saudi Arabia
SAMA Cyber Security Framework: a practical compliance guide
The SAMA Cyber Security Framework sets cybersecurity expectations for financial institutions regulated by the Saudi Central Bank (SAMA). This guide covers who it applies to, how its maturity model works, and how to prepare. It does not reproduce the framework; use the official SAMA rulebook for the requirement text.
What it is and who must comply
Regulator and edition
The framework is issued by SAMA. Version 1.0 is dated May 2017.
Who must comply
All member organisations regulated by SAMA:
- banks operating in Saudi Arabia;
- insurance and reinsurance companies operating in Saudi Arabia;
- financing companies operating in Saudi Arabia;
- credit bureaus operating in Saudi Arabia;
- financial market infrastructure.
Every domain applies to banks. For other member organisations, the framework excludes or qualifies a small number of subdomains; check the applicability section of the official text for your institution type.
How it is structured
The framework has four domains, numbered 3.1 to 3.4: leadership and governance, risk management and compliance, operations and technology, and third-party security. Each domain is split into subdomains, and each subdomain states a principle, an objective and numbered control considerations.
Maturity model and assessment
SAMA measures maturity on six levels, 0 to 5. To reach a level, an organisation must first meet every criterion of the levels below it. Member organisations should operate at level 3 or higher. Implementation is subject to periodic self-assessment by the member organisation, using a questionnaire; SAMA reviews and audits those self-assessments to determine compliance and maturity.
Where a control cannot be implemented, the framework describes compensating controls, internal risk acceptance and a formal waiver request to SAMA.
How to comply
- Confirm your institution type and note any subdomains the framework excludes or qualifies for it.
- Obtain the framework from the SAMA rulebook.
- Assess current maturity per subdomain on the 0-5 scale, with the reasoning for each score.
- Plan to reach level 3 everywhere it is not yet met: documented, approved, implemented and monitored.
- Assign owners and dates to each gap and track remediation.
- Collect evidence showing that each control is defined, approved, implemented and that compliance is monitored, which is what level 3 requires.
- Complete SAMA's self-assessment questionnaire from that evidence, and keep it ready for SAMA review and audit.
- Handle exceptions properly: compensating control, internal risk acceptance and, where needed, a waiver request.
Evidence checklist
- Board-approved cybersecurity strategy and governance structure, including committee terms and minutes
- Approved policies and procedures, with version history and review dates
- Cybersecurity risk assessments and treatment records
- Compliance monitoring reports
- Asset, identity and access management records, including periodic access reviews
- Vulnerability management, patching and penetration test records
- Security monitoring and incident management records
- Third-party security assessments and contract clauses
- Awareness programme content and completion records
- Approved waivers and risk acceptances
How it maps to ISO/IEC 27001:2022
Domain-level only. This table is Pravitrust's interpretation for planning evidence reuse; it is not a mapping published by the regulator or by ISO.
| SAMA CSF | ISO/IEC 27001:2022 |
|---|---|
| 3.1 Leadership and governance | Clauses 4-7 (context, leadership, planning, support); A.5.1 to A.5.4; A.6 people controls |
| 3.2 Risk management and compliance | Clauses 6.1, 8.2, 8.3, 9; A.5.31 to A.5.36 (legal requirements, compliance, independent review) |
| 3.3 Operations and technology | A.5 (asset, access, incidents), A.7 physical controls, A.8 technological controls |
| 3.4 Third-party security | A.5.19 to A.5.23 (supplier relationships and cloud services) |
How to choose software for SAMA CSF
These criteria are neutral: they apply to any tool you evaluate, including Pravitrust.
- Regulator mapping you can trace. The tool should hold the framework's own identifiers and structure, and show which version it carries. Ask how it is updated when the regulator issues a revision.
- Licence-known content. Ask where the control content came from and on what terms. A vendor that cannot answer has a problem you will inherit.
- Evidence reuse. One piece of evidence should be attachable to every control it supports, across frameworks, without uploading it twice.
- Arabic support. Check the user interface, reports and exports separately; support in one does not imply the others.
- Hosting location. Ask where data and backups are stored, and match that against your own data-residency obligations and any sector rules.
- Honest status. A control with no test or evidence should never display as compliant.
- Exit. Confirm you can export everything, including history, in an open format.
- Maturity scoring. The tool should record a 0-5 maturity score per subdomain with the evidence behind it, not only a pass/fail per control.
Where Pravitrust stands today
- Adopt a framework pack into your control library at the scope that applies to you, with the pack version recorded so later assessments stay tied to the revision you assessed against.
- Attach evidence to each control, with an expiry date and reminders when evidence goes stale.
- Show a control with no test result as untested, never as healthy.
- Keep an append-only, hash-chained audit trail of changes.
- Export registers to CSV or Excel.
Moving from ServiceNow or Archer
Pravitrust does not import data from ServiceNow, Archer or any other GRC platform today. An import and migration feature is in design and is not available yet; this page will say so when it ships.
What you can do today:
- Export your current register from the existing tool so you hold a complete copy, including history, before you change anything.
- Adopt the framework pack in Pravitrust at your scope.
- Record control status and attach evidence against each control. Evidence you already hold for ISO/IEC 27001 can be attached to the controls it supports.
- Run both systems in parallel until your next assessment cycle closes, then retire the old one.
Frequently asked questions
Who must comply with the SAMA Cyber Security Framework?
Organisations regulated by SAMA: banks, insurance and reinsurance companies, financing companies and credit bureaus operating in Saudi Arabia, and financial market infrastructure.
What maturity level is required?
The framework states that member organisations should operate at maturity level 3 or higher.
What does level 3 mean in practice?
Controls are defined, approved and implemented in a structured, formal way, and compliance with them is monitored.
How does SAMA assess compliance?
Member organisations carry out a periodic self-assessment using a questionnaire. SAMA reviews and audits these self-assessments.
Does every domain apply to insurers and financing companies?
Every domain applies to banks. For other member organisations, the framework excludes or qualifies specific subdomains; check the applicability section for your type of institution.
What if we cannot implement a control?
The framework describes compensating controls, internal risk acceptance and a formal waiver request to SAMA.