Introduction: The SAMA Cyber Security Framework
The SAMA Cyber Security Framework (SAMA CSF) is the mandatory cyber security baseline issued by the Saudi Central Bank (Saudi Arabian Monetary Authority, still commonly abbreviated as SAMA) for all financial institutions it regulates within the Kingdom of Saudi Arabia. First issued in May 2017 (Version 1.0), the framework was created in response to the rapid digitisation of Saudi Arabia's financial sector, the rise of sophisticated cyber threats targeting banks and payment systems, and the Kingdom's Vision 2030 ambition to build a resilient, cashless, digitally enabled economy. SAMA CSF establishes a common language, a minimum set of controls, and a repeatable maturity assessment methodology that every Member Organisation must adopt, measure against, and continuously improve.
Unlike a purely voluntary standard, SAMA CSF is enforced through SAMA's supervisory mandate. Non-compliance can trigger regulatory findings, remediation directives, financial penalties, restrictions on new product launches, and reputational consequences. Because SAMA is both the central bank and the prudential regulator, its cyber expectations carry the full weight of banking supervision. This guide provides an auditor-grade, control-by-control walkthrough of the framework, a master assessment checklist, an implementation roadmap, the maturity scoring model, and cross-mappings to other global standards, so that CISOs, risk officers, internal auditors, and assessors can prepare for a SAMA cyber maturity assessment with confidence.
Copyright and source note
SAMA CSF is a copyrighted publication of the Saudi Central Bank. This guide is an original, independent interpretation written for educational and readiness purposes by CyberSigma. It does not reproduce SAMA's copyrighted control text. Member Organisations must always obtain and comply with the authoritative framework document and any subsequent circulars, addenda, or superseding regulations issued directly by SAMA. Where control identifiers are referenced, they follow the framework's published numbering convention to aid navigation, not to reproduce protected content.
What is SAMA CSF?
SAMA CSF is a control-based, risk-driven cyber security framework structured around four main domains, further decomposed into subdomains and individual control considerations. It is deliberately aligned with, and draws upon, internationally recognised standards including ISO/IEC 27001 and 27002, the NIST Cybersecurity Framework, NIST SP 800-53, PCI DSS, and BASEL cyber resilience guidance, while tailoring requirements to the Saudi financial ecosystem. The framework applies a maturity model that scores each control area on a scale from 0 (Non-existent) to 5 (Adaptive), with SAMA setting a target maturity level (typically Level 3, 'Structured and Formalised', as the minimum expected baseline, with higher levels expected for critical controls).
The framework's stated objectives are to: create a shared approach to addressing cyber security across the sector; enable Member Organisations to effectively identify and address cyber risks; ensure an appropriate maturity level of cyber security controls; and continuously improve the sector's overall cyber resilience. Crucially, SAMA CSF treats cyber security as a board and senior-management accountability, not merely an IT function, and mandates that cyber risk be integrated into the enterprise risk management framework.
SAMA has since expanded its regulatory toolkit with adjacent frameworks such as the Business Continuity Management Framework, the Cyber Threat Intelligence Principles, the Counter-Fraud Framework, and the IT Governance Framework. SAMA CSF remains the anchor cyber security instrument, and Member Organisations are assessed against it periodically, typically on an annual self-assessment cycle supplemented by SAMA-led or independent third-party reviews.
Who must comply with SAMA CSF?
SAMA CSF applies to all 'Member Organisations' regulated and supervised by the Saudi Central Bank. The scope is deliberately broad and covers the full financial services value chain, including entities that support or process financial transactions on behalf of regulated firms.
| Category of entity | Scope of applicability under SAMA CSF |
|---|
| Banks (local and foreign branches) | All commercial, retail, corporate and Islamic banks licensed to operate in Saudi Arabia; full framework applicability. |
| Insurance and reinsurance companies | Insurers and reinsurers supervised by SAMA (following the transfer of insurance supervision to SAMA); full applicability. |
| Financing companies | Consumer finance, real estate finance, SME finance and leasing companies licensed under the Finance Companies Control Law. |
| Payment service providers | Licensed payment institutions, e-wallet providers, acquirers and payment aggregators operating under SAMA authorisation. |
| Money exchangers / exchange houses | Licensed currency exchange and remittance businesses. |
| Credit bureaus | Entities providing credit information services under SAMA supervision. |
| Fintechs and open-banking participants | Fintech firms operating in the SAMA regulatory sandbox or licensed for open-banking data and payment services. |
| Third parties and outsourced service providers | Vendors, cloud providers and outsourcers processing Member Organisation data are bound indirectly through contractual flow-down of SAMA CSF control requirements. |
- Applicability is entity-wide: it covers information assets, systems, people, processes and third parties, not just customer-facing banking systems.
- Foreign banks operating branches in the Kingdom must comply for their Saudi operations, even where a group standard exists.
- The board of directors and senior management of each Member Organisation are explicitly accountable for the cyber security programme's effectiveness.
- Outsourcing does not transfer accountability; the Member Organisation remains responsible for controls performed by service providers on its behalf.
Structure of SAMA CSF
SAMA CSF is organised as a hierarchy: four primary Domains, each broken down into Subdomains, and each subdomain containing one or more Control Considerations (the individual, testable control statements). Every control is assessed for maturity. The table below sets out the domain structure and the principal subdomains within each.
| Domain | Principal subdomains / control areas | Assessment focus |
|---|
| 1. Cyber Security Leadership and Governance | Cyber Security Governance; Cyber Security Strategy; Cyber Security Policy; Cyber Security Roles and Responsibilities; Cyber Security in Project Management; Cyber Security Awareness; Cyber Security Training | Board oversight, strategy, policy architecture, accountability, culture. |
| 2. Cyber Security Risk Management and Compliance | Cyber Security Risk Management; Regulatory Compliance; Compliance with (inter)national Industry Standards; Cyber Security Review; Cyber Security Audits | Risk identification, treatment, regulatory adherence, independent assurance. |
| 3. Cyber Security Operations and Technology | Human Resources; Physical Security; Asset Management; Cyber Security Architecture; Identity and Access Management; Application Security; Change Management; Infrastructure Security; Cryptography; Bring Your Own Device; Secure Disposal; Payment Systems; Electronic Banking; Cyber Security Event Management; Cyber Security Incident Management; Threat Management; Vulnerability Management | The largest domain: operational and technical safeguards across the estate. |
| 4. Third Party Cyber Security | Contract and Vendor Management; Outsourcing; Cloud Computing | Managing cyber risk arising from vendors, outsourcing and cloud. |
The framework uses a consistent numbering convention (for example, 3.3.x for Asset Management control considerations within the Operations and Technology domain). Each control is written as an expected outcome, against which the Member Organisation self-assesses a maturity level. The subdomains within Domain 3 are the most numerous because they cover the entire technology and operations landscape, from HR screening to payment-system and e-banking security.
Master assessment checklist
This is the core of the guide. Below, each subdomain is enumerated with the key items an assessor must verify and the typical evidence expected. Use this as a control-by-control workbook. For each control, record the observed maturity level (0-5), the target level, the gap, and remediation actions.
1.1 Cyber Security Governance
| What to verify | Typical evidence |
|---|
| A cyber security governance structure exists with defined board and senior-management oversight. | Governance charter, board/steering committee terms of reference, organisation chart. |
| A cyber security committee meets regularly and reviews risks and programme status. | Committee minutes, meeting cadence, attendance records, decision logs. |
| Cyber security is integrated into enterprise governance and risk frameworks. | ERM framework document showing cyber risk integration, risk appetite statement. |
| A CISO (or equivalent) is appointed with sufficient authority and independence. | Appointment letter, reporting line diagram, job description. |
1.2 Cyber Security Strategy
| What to verify | Typical evidence |
|---|
| A documented, board-approved cyber security strategy aligned to business objectives exists. | Approved strategy document, board approval record. |
| The strategy defines a target maturity state and improvement roadmap. | Roadmap, target maturity baselines, milestone tracker. |
| The strategy is reviewed and updated periodically and after major changes. | Version history, review minutes, change triggers. |
1.3 Cyber Security Policy
| What to verify | Typical evidence |
|---|
| A comprehensive, approved cyber security policy and supporting standards exist. | Policy library, approval and version control records. |
| Policies are communicated to staff and third parties and are enforced. | Distribution logs, acknowledgement records, enforcement examples. |
| Policies are reviewed at planned intervals (at least annually). | Review schedule, revision history. |
1.4 Cyber Security Roles and Responsibilities
| What to verify | Typical evidence |
|---|
| Roles, responsibilities and accountabilities for cyber security are defined and assigned. | RACI matrix, job descriptions, segregation-of-duties matrix. |
| Adequate resourcing and budget are allocated to the cyber function. | Budget allocation, headcount plan, resourcing approvals. |
| Segregation of duties prevents conflicts of interest in security operations. | SoD analysis, conflicting-role review. |
1.5 Cyber Security in Project Management
| What to verify | Typical evidence |
|---|
| Cyber security requirements are embedded in the project lifecycle and SDLC. | Project methodology, security gate checklists, sign-off records. |
| Security risk assessments are performed for new projects and changes. | Project risk assessments, security architecture reviews. |
| Go-live is gated on security sign-off. | Security acceptance criteria, release approval records. |
1.6 Cyber Security Awareness
| What to verify | Typical evidence |
|---|
| A cyber security awareness programme covers all staff and relevant third parties. | Awareness programme plan, coverage metrics. |
| Phishing simulations and targeted campaigns are conducted and measured. | Simulation results, click-rate trends, remedial actions. |
| Awareness effectiveness is measured and reported. | Awareness KPIs, management reporting. |
1.7 Cyber Security Training
| What to verify | Typical evidence |
|---|
| Role-specific technical and security training is provided (e.g., developers, SOC, admins). | Training curriculum, completion records, certifications. |
| Training needs are assessed and refreshed periodically. | Skills matrix, training needs analysis. |
| Specialist certifications are maintained for key roles. | Certification register (CISSP, CISM, GIAC, etc.). |
2.1 Cyber Security Risk Management
| What to verify | Typical evidence |
|---|
| A formal cyber risk management methodology (identification, analysis, treatment, monitoring) is in place. | Risk methodology document, risk register. |
| Risks are assessed against defined risk appetite and treated accordingly. | Risk appetite statement, treatment plans, residual-risk acceptance. |
| Key cyber risks are reported to senior management and the board. | Risk dashboards, board risk reports. |
| Risk assessments are refreshed periodically and on material change. | Assessment schedule, trigger-based reassessments. |
2.2 Regulatory Compliance
| What to verify | Typical evidence |
|---|
| A process tracks SAMA regulatory obligations and circulars. | Regulatory obligations register, circular tracking log. |
| Compliance status is monitored and gaps are remediated. | Compliance dashboard, remediation tracker. |
| Regulatory reporting and notifications are made on time. | Submission records, breach/incident notifications to SAMA. |
2.3 Compliance with International Industry Standards
| What to verify | Typical evidence |
|---|
| Applicable standards (ISO 27001, PCI DSS, etc.) are identified and adopted where relevant. | Standards applicability analysis, certificates (e.g., PCI AoC/ROC, ISO 27001 cert). |
| Certification and attestation currency is maintained. | Certificate validity dates, surveillance-audit records. |
2.4 Cyber Security Review
| What to verify | Typical evidence |
|---|
| Periodic self-assessment against SAMA CSF maturity model is performed. | Self-assessment results, maturity scorecards. |
| Review findings feed the improvement roadmap. | Gap analysis, corrective action plans. |
2.5 Cyber Security Audits
| What to verify | Typical evidence |
|---|
| Independent internal and external cyber security audits are conducted. | Audit charter, audit plan, audit reports. |
| Audit findings are tracked to closure with management accountability. | Finding-tracker, remediation evidence, follow-up audits. |
| Audit independence and competence are assured. | Auditor qualifications, independence declarations. |
3.1 Human Resources Security
| What to verify | Typical evidence |
|---|
| Pre-employment screening and background verification are performed for relevant roles. | Screening policy, background-check records. |
| Confidentiality and acceptable-use agreements are signed. | Signed NDAs and acceptable-use policies. |
| Joiner-mover-leaver processes revoke access promptly. | JML procedure, access-revocation logs, exit checklists. |
3.2 Physical Security
| What to verify | Typical evidence |
|---|
| Data centres and sensitive areas have layered physical access controls. | Access-control logs, badge system config, CCTV coverage. |
| Environmental controls (power, cooling, fire suppression) protect assets. | Environmental monitoring, maintenance records, UPS/generator tests. |
| Visitor and third-party physical access is governed and logged. | Visitor registers, escort policy. |
3.3 Asset Management
| What to verify | Typical evidence |
|---|
| A complete, current inventory of information assets exists with ownership. | Asset register/CMDB, ownership assignments. |
| Assets are classified and handled per classification. | Data classification scheme, labelling, handling standards. |
| Asset lifecycle (acquisition to disposal) is managed. | Lifecycle procedures, reconciliation reports. |
3.4 Cyber Security Architecture
| What to verify | Typical evidence |
|---|
| A defence-in-depth, segmented security architecture is defined and maintained. | Architecture diagrams, segmentation design, security patterns. |
| Security is designed into solutions (secure-by-design principles). | Architecture review board records, reference architectures. |
| Architecture is reviewed against evolving threats. | Architecture review cadence, threat-driven updates. |
3.5 Identity and Access Management
| What to verify | Typical evidence |
|---|
| Access is granted on least-privilege and need-to-know, with formal approval. | Access-request workflow, approval records, role definitions. |
| Privileged access is managed and monitored (PAM, session recording). | PAM configuration, privileged-session logs, vaulting evidence. |
| Multi-factor authentication is enforced for remote and privileged access. | MFA policy and configuration, coverage report. |
| Periodic access recertification is performed. | Recertification campaigns, attestation records, revocations. |
3.6 Application Security
| What to verify | Typical evidence |
|---|
| Secure development lifecycle with coding standards and security testing. | SDLC policy, secure-coding standards, SAST/DAST results. |
| Application security testing and code review before release. | Penetration test reports, code-review records, remediation logs. |
| Web/application layer protections (WAF, input validation) are in place. | WAF policy, config, OWASP-aligned control evidence. |
3.7 Change Management
| What to verify | Typical evidence |
|---|
| All changes follow a controlled, risk-assessed change process with approvals. | Change management policy, CAB minutes, change tickets. |
| Emergency changes are governed and retrospectively reviewed. | Emergency change procedure, post-implementation reviews. |
| Segregation between development, testing and production is enforced. | Environment separation evidence, deployment approvals. |
3.8 Infrastructure Security
| What to verify | Typical evidence |
|---|
| Systems are hardened to secure baselines and patched in a timely manner. | Hardening standards, baseline scans, patch compliance reports. |
| Network security controls (firewalls, IDS/IPS, segmentation) are configured and reviewed. | Firewall rule reviews, IDS/IPS logs, network diagrams. |
| Endpoint protection (EDR/anti-malware) is deployed and monitored. | EDR coverage report, malware alerts and response. |
| Email and web security gateways filter malicious content. | Gateway policy, blocked-threat statistics. |
3.9 Cryptography
| What to verify | Typical evidence |
|---|
| Approved cryptographic algorithms and key lengths are used for data at rest and in transit. | Cryptographic standard, TLS/encryption configuration. |
| Cryptographic key management (generation, storage, rotation, destruction) is controlled. | Key management policy, HSM records, key lifecycle logs. |
| Certificates are inventoried and renewed before expiry. | Certificate inventory, expiry-monitoring evidence. |
3.10 Bring Your Own Device (BYOD)
| What to verify | Typical evidence |
|---|
| BYOD usage is governed by policy with technical enforcement (MDM/containerisation). | BYOD policy, MDM enrolment and configuration. |
| Corporate data on personal devices can be remotely wiped and is segregated. | Remote-wipe capability, container config, wipe logs. |
3.11 Secure Disposal of Information Assets
| What to verify | Typical evidence |
|---|
| Media and assets are securely sanitised or destroyed before disposal or reuse. | Sanitisation procedure, destruction certificates. |
| Disposal of media is logged and verified. | Disposal register, chain-of-custody records. |
3.12 Payment Systems Security
| What to verify | Typical evidence |
|---|
| Payment systems (mada, SARIE, SWIFT, card systems) are protected to sector standards. | Payment-system architecture, SWIFT CSP attestation, PCI DSS compliance. |
| Transaction integrity, fraud monitoring and reconciliation controls operate. | Fraud-monitoring rules, reconciliation reports, exception handling. |
| Cardholder data is protected in line with PCI DSS. | PCI DSS ROC/AoC, network segmentation evidence. |
3.13 Electronic Banking Security
| What to verify | Typical evidence |
|---|
| Online, mobile and digital banking channels enforce strong customer authentication. | Authentication design, SCA/OTP configuration, session controls. |
| Anti-fraud, transaction-signing and anomaly detection protect e-banking. | Fraud-detection config, transaction-signing evidence, alert logs. |
| Customer-facing security (secure sessions, timeouts, alerts) is implemented. | Session-management config, customer notification records. |
3.14 Cyber Security Event Management
| What to verify | Typical evidence |
|---|
| Security logging and centralised monitoring (SIEM) capture relevant events. | SIEM use cases, log-source coverage, retention config. |
| Events are correlated, triaged and monitored 24x7 by a SOC. | SOC operating model, monitoring reports, alert triage records. |
| Log integrity and retention meet regulatory expectations. | Log protection controls, retention policy, tamper-evidence. |
3.15 Cyber Security Incident Management
| What to verify | Typical evidence |
|---|
| A documented incident response plan with defined roles and severity classification exists. | IR plan, playbooks, escalation matrix. |
| Incidents are detected, contained, eradicated, recovered and reported to SAMA when required. | Incident tickets, timelines, SAMA notification records. |
| Post-incident reviews capture lessons learned and drive improvement. | PIR reports, corrective actions, plan updates. |
| Incident response is tested through exercises and simulations. | Tabletop/red-team exercise reports. |
3.16 Threat Management
| What to verify | Typical evidence |
|---|
| Cyber threat intelligence is collected, analysed and operationalised. | CTI sources, threat feeds, intelligence reports. |
| Threat intelligence informs detection, hunting and controls. | Threat-hunting records, detection rule updates driven by CTI. |
| Sector threat sharing (e.g., with SAMA/BSF) is leveraged. | Participation in sharing arrangements, received advisories. |
3.17 Vulnerability Management
| What to verify | Typical evidence |
|---|
| Regular vulnerability scanning across the estate is performed. | Scan schedules, scan reports, coverage metrics. |
| Vulnerabilities are risk-rated and remediated within defined SLAs. | Remediation SLAs, patch/remediation evidence, exception approvals. |
| Penetration testing is conducted periodically and after major changes. | Penetration test reports, retest evidence. |
4.1 Contract and Vendor Management
| What to verify | Typical evidence |
|---|
| Third-party cyber risk is assessed before engagement and periodically thereafter. | Vendor risk assessments, due-diligence questionnaires. |
| Contracts include cyber security, audit-right and breach-notification clauses. | Executed contracts with security schedules, right-to-audit clauses. |
| Vendor performance and security posture are monitored throughout the lifecycle. | Vendor monitoring reports, SLA reviews, offboarding records. |
4.2 Outsourcing
| What to verify | Typical evidence |
|---|
| Outsourcing arrangements comply with SAMA outsourcing rules and require approvals where mandated. | Outsourcing register, SAMA approvals/notifications, board approvals. |
| Security controls at outsourced providers are assured through audits/attestations. | Provider audit reports (SOC 2, ISO 27001), assurance evidence. |
| Exit and continuity arrangements for outsourced services are defined. | Exit plans, data-return/destruction provisions, continuity tests. |
4.3 Cloud Computing
| What to verify | Typical evidence |
|---|
| Cloud adoption follows SAMA cloud guidance including data residency and materiality assessment. | Cloud policy, materiality/risk assessment, SAMA approval where required. |
| Shared-responsibility model is understood and control ownership documented. | Responsibility matrix, cloud security configuration baselines. |
| Cloud configurations are hardened, monitored and access-controlled. | CSPM findings, IAM configuration, encryption and logging evidence. |
| Data location, sovereignty and exit strategy are addressed. | Data-residency evidence, data-portability and exit plans. |
Scoping the assessment
Effective SAMA CSF scoping ensures the maturity assessment covers everything the framework requires without unbounded effort. Scoping must be entity-wide because SAMA CSF applies to all information assets and supporting processes of the Member Organisation.
- Define the organisational scope: all business lines, subsidiaries and Saudi operations of the Member Organisation.
- Identify all in-scope information assets: applications, systems, databases, network components, endpoints, and the data they process.
- Include people and process scope: governance bodies, HR security, awareness and training populations.
- Include payment and e-banking systems: mada, SARIE, SWIFT, ATM/POS networks, internet and mobile banking channels.
- Include third parties, outsourcers and cloud services that store, process or transmit Member Organisation data.
- Map data flows across the estate to ensure no in-scope pathway is missed.
- Do not carve out legacy or 'low-priority' systems; SAMA expects full coverage, though risk-based prioritisation of remediation is acceptable.
- Document scope boundaries, assumptions and any temporary exclusions with justification and target closure dates.
Implementation approach
A phased programme converts a SAMA CSF gap assessment into sustained, board-visible compliance. The following five phases move an organisation from initial assessment to continuous improvement.
Phase 1: Mobilise and assess (weeks 1-6)
- Activities: establish programme governance and sponsorship; confirm scope; conduct a baseline maturity self-assessment against all four domains; interview control owners; collect evidence.
- Deliverables: programme charter, scope definition, current-state maturity scorecard (0-5 per control), prioritised gap register.
Phase 2: Design and plan (weeks 5-10)
- Activities: define target maturity per control (aligned to SAMA expectation, minimum Level 3); design remediation initiatives; estimate effort, cost and resourcing; sequence a roadmap by risk and dependency.
- Deliverables: target operating model, remediation roadmap, business case and budget, RACI for delivery.
Phase 3: Remediate policy and governance (weeks 8-20)
- Activities: build or uplift the policy and standards library; formalise governance committees; establish risk management, awareness and training programmes; define incident and third-party processes.
- Deliverables: approved policy suite, governance charters, risk framework, awareness programme, incident response plan.
Phase 4: Remediate technical controls (weeks 12-36)
- Activities: implement IAM/PAM/MFA, hardening and patching, SIEM/SOC monitoring, vulnerability management, cryptography and key management, application security, and cloud/third-party controls.
- Deliverables: deployed technical controls, monitoring use cases, tested backups and recovery, penetration-test remediation.
Phase 5: Operate, assure and improve (ongoing)
- Activities: embed controls into BAU; run continuous monitoring and metrics; conduct internal audits and independent reviews; perform annual self-assessment; remediate residual gaps and mature high-priority controls beyond Level 3.
- Deliverables: KPI dashboards, internal audit reports, updated maturity scorecard, SAMA reporting pack, continuous improvement plan.
Maturity and capability model
SAMA CSF assesses each control against a six-level maturity model. SAMA generally expects Member Organisations to achieve at least Level 3 (Structured and Formalised) across the framework, with higher levels expected for critical controls. Scores below target represent gaps requiring remediation.
| Level | Name | Description | Typical assessment indicators |
|---|
| 0 | Non-existent | No control exists; the requirement is not addressed at all. | No policy, no process, no evidence; total absence of the control. |
| 1 | Ad-hoc | Controls exist but are inconsistent, undocumented and reactive. | Informal or one-off activity; heavy reliance on individuals; no documentation. |
| 2 | Repeatable but informal | Controls are performed with some consistency but are not formally documented or standardised. | Some repeatable practice; partial documentation; inconsistent application. |
| 3 | Structured and formalised | Controls are documented, approved, communicated and consistently applied (baseline SAMA expectation). | Approved policies/standards, defined processes, consistent execution, evidence available. |
| 4 | Managed and measurable | Controls are monitored, measured and reported using metrics and KPIs. | Metrics/KPIs in place, periodic measurement, management reporting, corrective action. |
| 5 | Adaptive | Controls are continuously improved, automated where possible, and adapt to the evolving threat landscape. | Continuous improvement, automation, threat-driven tuning, benchmarking, optimisation. |
Assessment and audit approach
A SAMA CSF assessment follows a structured, evidence-based methodology. Whether performed as a self-assessment, internal audit or independent third-party review, the following steps apply.
- Confirm scope and assemble the control catalogue mapping every SAMA CSF domain, subdomain and control consideration to owners.
- Plan the assessment: agree timelines, evidence-request lists, interview schedules and the maturity rating rubric.
- Conduct kick-off and control-owner interviews across governance, risk, operations, technology and third-party functions.
- Collect and review evidence for each control (policies, configurations, logs, reports, tickets, contracts).
- Perform technical validation where relevant (configuration reviews, scans, sample testing) to corroborate stated maturity.
- Rate each control on the 0-5 maturity scale, recording observed state, target state and the gap.
- Aggregate scores by subdomain and domain to produce a maturity heat-map and overall posture view.
- Document findings, root causes and prioritised, risk-based remediation recommendations.
- Validate findings with control owners and management, resolving factual disputes with evidence.
- Report to senior management and the board, and prepare the SAMA-facing self-assessment and remediation plan with target dates and accountable owners.
Evidence request list
Prepare the following evidence, organised by category, ahead of a SAMA CSF assessment to accelerate the review and reduce follow-up requests.
- Governance and strategy: board/committee charters and minutes, cyber security strategy, organisation charts, CISO appointment and reporting line.
- Policies and standards: full cyber security policy suite, standards, procedures, version history and approval records.
- Risk and compliance: risk methodology, cyber risk register, risk appetite statement, regulatory obligations register, compliance dashboards.
- Assurance: internal and external audit reports, prior self-assessments, penetration test and vulnerability scan reports, remediation trackers.
- Human resources: screening policy and records, NDAs/acceptable-use agreements, joiner-mover-leaver procedures and logs.
- Asset and data: asset inventory/CMDB, data classification scheme, handling and disposal procedures, destruction certificates.
- Identity and access: access-management workflow, PAM configuration, MFA coverage, recertification records, privileged-session logs.
- Infrastructure and application: hardening baselines, patch compliance, firewall/IDS/IPS configuration, EDR coverage, SDLC and secure-coding standards, SAST/DAST results.
- Cryptography: cryptographic standard, key-management policy, HSM/key lifecycle records, certificate inventory.
- Operations and monitoring: SIEM use cases and log-source coverage, SOC operating model, monitoring reports, incident response plan, incident tickets and PIRs.
- Payment and e-banking: payment-system architecture, SWIFT CSP attestation, PCI DSS ROC/AoC, fraud-monitoring configuration, e-banking authentication design.
- Third party and cloud: vendor risk assessments, contracts with security clauses, outsourcing register and SAMA approvals, cloud materiality assessments and provider attestations (SOC 2, ISO 27001).
Roles and responsibilities
| Role | Key cyber security responsibilities under SAMA CSF |
|---|
| Board of Directors | Ultimate accountability; approve strategy, policy and risk appetite; oversee programme effectiveness and receive periodic reporting. |
| Senior Management / Executive Committee | Own delivery of the programme; allocate resources and budget; ensure integration with enterprise risk; drive remediation. |
| Cyber Security Committee | Provide governance and oversight; review risks, incidents and programme status; make risk-treatment decisions. |
| Chief Information Security Officer (CISO) | Lead the cyber security function; define and execute strategy, policy and controls; report on posture; ensure independence from IT operations. |
| Chief Risk Officer / Risk Function | Integrate cyber risk into ERM; challenge risk assessments; monitor against appetite (second line of defence). |
| Internal Audit | Provide independent assurance over control design and effectiveness; report findings to the audit committee (third line of defence). |
| Compliance Function | Track SAMA obligations and circulars; ensure regulatory reporting and notifications; monitor compliance status. |
| IT / Operations Teams | Implement and operate technical controls; maintain systems securely; support monitoring and incident response (first line of defence). |
| Business / Asset Owners | Own their information assets and associated risks; approve access; ensure controls meet business needs. |
| Third-Party / Vendor Managers | Assess and monitor vendor cyber risk; ensure contractual controls and assurance are in place. |
KPIs to track
- Overall SAMA CSF maturity score and percentage of controls at or above target (Level 3+).
- Number and ageing of open control gaps versus remediation SLA.
- Patch compliance rate and mean time to patch critical vulnerabilities.
- Vulnerability remediation SLA adherence by severity.
- Mean time to detect (MTTD) and mean time to respond (MTTR) for security incidents.
- Number of security incidents by severity and trend over time.
- Phishing simulation click-rate and reporting-rate trends.
- Security awareness and role-based training completion rates.
- Privileged access recertification completion and exceptions.
- Percentage of third parties with current risk assessments and compliant contracts.
- MFA coverage across remote and privileged access.
- Audit and self-assessment findings closed on time versus overdue.
- SIEM log-source coverage and percentage of critical assets monitored.
- Backup success rate and recovery-test (RTO/RPO) achievement.
Readiness checklist
- Board-approved cyber security strategy, policy suite and risk appetite are in place and current.
- Cyber security governance committee is established and meets on a defined cadence with recorded decisions.
- A CISO with adequate authority, independence and resourcing is appointed.
- A complete asset inventory with classification and ownership is maintained.
- Cyber risk register is integrated into enterprise risk management and reported to the board.
- Identity and access management enforces least privilege, MFA and periodic recertification.
- Privileged access is vaulted, monitored and session-recorded via PAM.
- Systems are hardened to baselines and patched within defined SLAs.
- SIEM and 24x7 SOC monitoring cover critical assets with tested detection use cases.
- A tested incident response plan with SAMA notification procedures exists.
- Vulnerability scanning and periodic penetration testing are performed and remediated.
- Cryptography and key management follow approved standards with HSM protection.
- Payment systems and e-banking channels meet PCI DSS, SWIFT CSP and strong-authentication requirements.
- Third-party, outsourcing and cloud arrangements are risk-assessed, contracted and assured with SAMA approvals where required.
- Security awareness and role-based training programmes run with measured effectiveness.
- Internal and independent audits are conducted with findings tracked to closure.
- An annual SAMA CSF self-assessment and remediation roadmap are maintained.
Common gaps
- Governance on paper only: policies exist but committees do not meet or make evidenced decisions, keeping controls stuck at Level 2.
- Incomplete or stale asset inventory, undermining every downstream control that depends on knowing the estate.
- Weak privileged access management: shared admin accounts, no vaulting, missing session monitoring and stale privileged entitlements.
- MFA gaps for remote access, third-party access or privileged operations.
- Patch and vulnerability backlogs breaching SLAs, especially on legacy and payment-adjacent systems.
- Insufficient SIEM log-source coverage and alert tuning, producing blind spots or alert fatigue.
- Incident response plans that are untested, with unclear SAMA notification timelines and roles.
- Third-party and cloud risk under-managed: missing right-to-audit clauses, no data-residency assessment, unclear shared responsibility.
- Cryptographic key management informal, with keys outside HSMs and no rotation or certificate expiry monitoring.
- Self-assessment scores inflated relative to available evidence, leading to surprises during independent review.
- Cyber risk not genuinely integrated into enterprise risk management or reported to the board.
- Awareness measured by completion only, not by behavioural change such as phishing resilience.
SAMA CSF mapped to other frameworks
SAMA CSF draws on and aligns with several international standards. The following mapping helps organisations reuse existing control work and evidence across frameworks.
| SAMA CSF domain / area | ISO/IEC 27001:2022 (Annex A themes) | NIST CSF function | PCI DSS relevance | NIST SP 800-53 family |
|---|
| Leadership and Governance | Organizational controls (A.5), clauses 5-6 (leadership/planning) | Govern / Identify | Requirement 12 (policy and governance) | PM (Program Management), PL (Planning) |
| Risk Management and Compliance | Clause 6.1, A.5 organizational controls | Identify (Risk Assessment/Strategy) | Requirement 12.3 (risk assessment) | RA (Risk Assessment), CA (Assessment/Authorization) |
| Human Resources Security | People controls (A.6) | Protect (Awareness/Training) | Requirement 12.6, 7 (training, need-to-know) | PS (Personnel Security), AT (Awareness and Training) |
| Physical Security | Physical controls (A.7) | Protect | Requirement 9 (physical access) | PE (Physical and Environmental Protection) |
| Asset Management | A.5.9-5.14 (asset/information handling) | Identify (Asset Management) | Requirement 9.5, 3 (media/data handling) | CM (Configuration Management), MP (Media Protection) |
| Identity and Access Management | A.5.15-5.18, A.8.2-8.5 (access, privileged) | Protect (Identity Management/Access Control) | Requirements 7, 8 (access, authentication) | AC (Access Control), IA (Identification and Authentication) |
| Application and Change Management | A.8.25-8.32 (secure development, change) | Protect | Requirement 6 (secure development) | SA (System and Services Acquisition), SI (System Integrity) |
| Infrastructure and Cryptography | A.8.1-8.24 (technical controls, crypto) | Protect | Requirements 1-4 (network, encryption) | SC (System and Communications Protection) |
| Event, Incident and Threat Management | A.5.24-5.28, A.8.15-8.16 (logging, monitoring, IR) | Detect / Respond / Recover | Requirements 10, 12.10 (logging, incident response) | IR (Incident Response), AU (Audit and Accountability), SI |
| Vulnerability Management | A.8.8 (technical vulnerabilities) | Identify / Protect | Requirement 11 (testing) | RA-5, SI-2 (scanning, flaw remediation) |
| Third Party, Outsourcing and Cloud | A.5.19-5.23 (supplier relationships) | Identify (Supply Chain Risk) | Requirement 12.8 (service providers) | SR (Supply Chain Risk Management), SA-9 |
How CyberSigma helps with SAMA CSF
CyberSigma provides end-to-end SAMA CSF services for Member Organisations in the Kingdom: baseline maturity assessment against all four domains, control-by-control gap analysis, prioritised remediation roadmaps, and hands-on implementation of governance, risk, technical and third-party controls. As CERT-In empanelled auditors and PCI QSAs, our team brings deep expertise across ISO 27001, NIST CSF, PCI DSS and SWIFT CSP, enabling us to reuse evidence across frameworks and accelerate compliance. We support annual self-assessments, independent reviews, SOC and SIEM uplift, PAM and IAM deployment, penetration testing, incident-response readiness, and board-level reporting so your organisation not only meets SAMA's minimum Level 3 expectation but sustains a measurable, adaptive cyber security posture. Talk to CyberSigma to build your SAMA CSF readiness programme with confidence.
