SAMA Compliance Checklist - Gap Assessment & Audit Readiness Guide

Most SAMA compliance failures are not technical. They happen because governance is undocumented, evidence is incomplete, or institutions discover during supervisory review that controls they believed were at Level 3 cannot be demonstrated to a regulator's standard.

This SAMA compliance checklist is designed for CISOs, compliance managers, and risk leaders preparing for a SAMA gap assessment, annual self-assessment submission, or an onsite SAMA supervisory review. It covers all four control domains of the SAMA Cybersecurity Framework, maps the evidence auditors expect at Level 3, and flags the failure patterns that appear most consistently across SAMA-regulated institutions.

For organisations still building foundational understanding of what SAMA requires and who it applies to, the SAMA Cybersecurity Framework guide covers the full picture before this checklist becomes useful.

1. Scope & Applicability Confirmation
2. Domain 1 — Cybersecurity Leadership & Governance
3. Domain 2 — Cybersecurity Risk Management & Compliance
4. Domain 3 — Cybersecurity Operations & Technology
5. Domain 4 — Third-Party Cybersecurity
6. Level 3 Evidence: What SAMA Assessors Actually Check
7. Pre-Assessment Readiness Summary

How to use this checklist:

• ✅ Implemented and evidenced — control is in place and evidence is current
• 🟡 Partially in place — control exists but evidence is incomplete, outdated, or not board-approved
• ❌ Gap — not yet in place, not documented, or not at Level 3 maturity

Work through each section before your gap assessment. Every item marked 🟡 or ❌ represents a remediation task. The evidence tables show exactly what SAMA assessors request during supervisory reviews not what looks sufficient internally.

Scope & Applicability Confirmation

Confirm these foundations before working through the domain items. Getting scope wrong at this stage is the single most expensive mistake in a SAMA compliance programme. Over-scoping wastes implementation budget. Under-scoping creates audit findings that cannot be quickly remediated.

Entity Type and Sub-Domain Applicability

• Has your organisation confirmed its SAMA licence category bank, insurance company, financing company, payment service provider, or other regulated entity?
• If you are an insurance or reinsurance company, has the scoping team confirmed the sub-domain exclusions that apply? (Sub-domains 3.2.3, 3.3.12, and the non-MFA elements of 3.3.13 are excluded unless conditions are met see the sector-specific applicability guide)
• If you process cardholder data or use SWIFT messaging, has sub-domain 3.2.3 been confirmed as in-scope regardless of entity type?
• For sandbox-stage fintechs: has your SAMA engagement letter been reviewed to confirm which controls apply during the sandbox period?

Compliance Scope Definition

• Has the organisation formally defined the systems, services, data, and infrastructure within SAMA compliance scope?
• Is the scope document aligned to your regulated services and the information assets supporting them not your entire IT estate?
• Has senior management reviewed and formally approved the scope document?
• Has the scope been reviewed within the past 12 months, or after any significant infrastructure change, cloud migration, or new product launch?

Roadmap and Self-Assessment Status

• Has a gap assessment been completed to establish current maturity levels per control?
• Has a compliance roadmap been developed based on gap assessment findings?
• Has the Board of Directors formally approved the compliance roadmap?
• Has the roadmap been submitted to SAMA?
• Are quarterly progress reports being produced and submitted to SAMA as required?

Domain 1 — Cybersecurity Leadership & Governance

The governance domain is assessed first in every SAMA supervisory review. Weak governance findings here undermine every other domain SAMA expects cybersecurity to be a board-level accountability, not an IT department function. The most common Level 3 failure in this domain is not the absence of a policy, but the absence of documented board engagement with cybersecurity.

1.1 — Cybersecurity Governance

• Is there a formally constituted cybersecurity committee with documented membership and terms of reference?
• Does the cybersecurity committee include senior management representation, not just IT?
• Are cybersecurity committee meeting minutes maintained, with dates, attendees, and decisions recorded?
• Is the cybersecurity committee meeting at the frequency defined in its terms of reference (minimum quarterly)?
• Is there a designated CISO (or equivalent) with a formal mandate, defined authority, and reporting line to the Board or a Board committee?
• Is the CISO role filled by a qualified practitioner not an acting or interim designation without clear authority?

1.2 — Cybersecurity Strategy

• Is there a board-approved Cybersecurity Strategy aligned to the institution's business objectives and risk appetite?
• Does the strategy cover the planning horizon specified by SAMA typically three years minimum?
• Has the strategy been reviewed within the past 12 months or after significant business changes?
• Is there a documented process for reviewing and updating the strategy?
• Is there evidence the Board reviewed and approved the current version board minutes, sign-off page?

1.3 — Cybersecurity Policy

• Is there a board-approved Cybersecurity Policy in place?
• Does the policy define scope, objectives, roles and responsibilities, and compliance obligations?
• Is the policy version-controlled with visible review dates and approver signatures?
• Has the policy been reviewed within the past 12 months?
• Is the policy communicated to all relevant staff with evidence of distribution or acknowledgement?

1.4 — Cybersecurity Roles and Responsibilities

• Are cybersecurity roles and responsibilities formally documented across the organisation?
• Are responsibilities for specific control domains assigned to named individuals or functions not just "IT"?
• Is there a skills and training requirement defined for staff in cybersecurity roles?
• Are job descriptions for security-relevant roles updated to reflect current responsibilities?

Domain 1 critical gap: Institutions that treat board approval as a presentation rather than a resolution. At Level 3, SAMA expects documented evidence that the Board reviewed, discussed, and formally approved the cybersecurity strategy and policy not that a slide deck was shown at a board meeting. Board minutes must reflect the approval, not just that cybersecurity was discussed.

Domain 2 — Cybersecurity Risk Management & Compliance

Domain 2 is where institutions most frequently score at Level 1 or Level 2 despite believing they are at Level 3. The difference is almost always in the risk register — a document that exists but is not actively maintained, not connected to control decisions, and not reviewed on a defined cycle.

2.1 — Cybersecurity Risk Management

• Is there a documented risk management methodology covering context, risk criteria, assessment method, and treatment approach?
• Has the methodology been formally approved by senior management?
• Is a risk register in place covering all in-scope systems, services, and information assets?
• Does each risk entry include: threat source, vulnerability, likelihood, impact, risk level, treatment decision, owner, and target date?
• Has the risk register been reviewed and updated within the past 12 months?
• Has the register been updated after significant changes cloud adoption, new products, infrastructure changes, acquisitions?
• Is there a risk treatment plan with assigned owners, selected treatment options (accept, mitigate, transfer, avoid), and target completion dates?
• Are accepted risks formally documented with a named owner and written justification not just left unaddressed?
• Is there evidence that risk treatment actions have been completed or are actively tracked?

2.2 — Cybersecurity Compliance

• Is there a compliance monitoring process tracking adherence to SAMA CSF controls?
• Are compliance gaps formally logged and tracked to remediation?
• Is there a defined process for monitoring changes to SAMA requirements and circulars?
• Is there a mechanism for tracking regulatory changes and assessing their impact on existing controls?
• Is compliance reporting provided to senior management and the Board at defined intervals?

2.3 — Cybersecurity in Projects and Change Management

• Is there a process for assessing cybersecurity risk in new projects before they enter production?
• Are security requirements defined at project initiation — not addressed as an afterthought at go-live?
• Is there a change management process that includes a security review gate for changes affecting in-scope systems?
• Are emergency changes documented and reviewed after the fact — not simply executed without record?

2.4 — Human Resources Security

• Is there a documented pre-employment screening procedure covering staff with access to in-scope systems?
• Are background checks conducted consistently and records maintained?
• Do employment contracts include documented security obligations?
• Is there a security awareness training programme in place — not just annual policy acknowledgement?
• Are individual training completion records maintained named employee, date, content covered?
• Has all staff with access to in-scope systems completed awareness training within the past 12 months?
• Is there a formal offboarding procedure including access revocation with documented completion?

Domain 2 critical gap: Risk registers that are never linked to control decisions. At Level 3, the risk register should be driving the compliance programme — controls should be selected and prioritised based on risk assessment outputs, not implemented generically. If the assessor asks "why did you prioritise this control over that one?" and the answer is "because it was on the list," the organisation is demonstrating Level 2 thinking, not Level 3.

Domain 3 — Cybersecurity Operations & Technology

Domain 3 is the largest domain in the SAMA CSF it contains the majority of technical controls and is the area with the most sub-domain variation by entity type. This is also where penetration testing evidence is assessed. Work through each sub-domain systematically; each represents a distinct control area that SAMA assesses independently.

3.1 — Cybersecurity Architecture

• Is there a documented cybersecurity architecture covering the security design of in-scope systems and infrastructure?
• Does the architecture address network segmentation, DMZ design, and separation of regulated services from general IT?
• Has the architecture been reviewed within the past 12 months or after significant infrastructure changes?
• Is there a current, accurate network topology diagram maintained?

3.2 — Information Asset Management (includes 3.2.3 for banks and payment entities)

• Is there a complete and current asset inventory covering hardware, software, data assets, cloud services, and third-party hosted systems?
• Does each asset have a named owner and a classification level?
• Is there an information classification scheme minimum four tiers: public, internal, confidential, restricted?
• Have all data assets been classified and is classification reviewed when assets change?
• Is there a secure disposal procedure for physical media, decommissioned hardware, and cloud-hosted data?
• Are disposal records maintained with method, date, and authorising signature?
• (Banks and payment entities only) Is PCI-DSS compliance current if cardholder data is processed?
• (Banks and payment entities only) Is the SWIFT Customer Security Controls Framework implemented if SWIFT services are used?

Domain 3 critical gap — penetration testing scope. The most consistent finding across SAMA-regulated institutions is penetration testing that covers the public-facing web application but excludes APIs, internal network segments, mobile applications, and cloud infrastructure. SAMA expects testing to cover the full regulated service environment. A report scoped only to the customer-facing website, when the same institution runs a mobile banking app and cloud-hosted API infrastructure, will not satisfy the assessor.

For a detailed treatment of how SAMA evaluates penetration testing evidence and the most common scoping failures, see SAMA penetration testing: common mistakes by banks.

Domain 4 — Third-Party Cybersecurity

Third-party and outsourcing relationships are the most under-assessed area in SAMA compliance programmes. Institutions frequently implement strong internal controls while maintaining minimal visibility into the security posture of vendors, cloud providers, and outsourcing partners who process or access regulated data on their behalf.

4.1 — Third-Party Due Diligence and Onboarding

• Is there a supplier register covering all third parties with access to in-scope systems or data?
• Have suppliers been risk-classified by criticality at minimum: critical, significant, standard?
• Is there a documented due diligence process for onboarding new third parties — what is assessed before engagement?
• Has a security assessment been completed for each critical supplier questionnaire, certification review, onsite audit, or equivalent?
• Are assessment records current and accessible?

4.2 — Contractual Security Requirements

• Do contracts with critical suppliers include documented cybersecurity requirements — minimum standards, audit rights, incident notification obligations?
• Have existing contracts been reviewed for missing security clauses particularly cloud service provider agreements?
• Is there a standard security schedule or annex applied to new supplier contracts?
• For cloud service providers: has SAMA approval been obtained before deployment, as required by SAMA cloud guidance?
• Do cloud contracts include data residency requirements consistent with SAMA's expectations?

4.3 — Ongoing Monitoring and Performance

• Is there a process for monitoring critical supplier security performance at defined intervals?
• Are supplier security certifications (ISO 27001, SOC 2, PCI-DSS) tracked and reviewed at renewal?
• Is there a process for responding when a supplier's security posture degrades — certification lapse, breach notification, audit finding?
• Is there a defined procedure for terminating supplier access when engagements end including cloud environment offboarding?
• Are supplier offboarding records maintained showing access revocation confirmation?

Domain 4 critical gap — SAMA cloud approval. Cloud adoption without prior SAMA approval is among the most frequently identified compliance failures, particularly for fintech companies that deployed cloud infrastructure before obtaining SAMA licensing or during early operational phases. SAMA's cloud guidance requires formal approval before adoption. Retroactive approval is possible but creates a compliance gap during the period of unapproved operation that assessors will note.

Level 3 Evidence: What SAMA Assessors Actually Check

Understanding what Level 3 requires in writing is different from understanding what evidence satisfies a SAMA assessor during a supervisory review. The following distinctions separate institutions that achieve Level 3 assessments from those that believe they are at Level 3 but score Level 2 during review.

Level 3 requires implementation evidence, not policy evidence. Having a policy is a Level 2 control at best. Level 3 requires evidence that the policy is being followed consistently — configuration screenshots, review records, training completion records, access review outputs. The question assessors ask is not "do you have a policy?" but "can you show me it's working?"

Level 3 requires a defined cycle, not a one-time event. Controls that were implemented correctly twelve months ago but have not been reviewed since do not demonstrate Level 3. The maturity model requires controls to be operating continuously within a defined management cycle. Review frequency must be documented, and evidence of the most recent cycle must be available.

Level 3 requires Board accountability, not Board awareness. The governance domain requires the Board to be actively engaged approving strategy, receiving cybersecurity reports, endorsing the compliance roadmap. Presenting information to the Board as part of a general management update is not the same as Board approval with a formal resolution. Assessors request Board minutes and specifically look for cybersecurity agenda items with documented decisions.

Level 3 requires finding remediation, not finding identification. Penetration testing and internal audits produce findings. At Level 3, those findings must be tracked to closure. A penetration test report showing critical and high-severity findings that remain open twelve months later demonstrates that controls are not being managed which is a Level 2 characteristic. The remediation tracker and retest evidence are as important as the test report itself.

Pre-Assessment Readiness Summary

Use this summary table before engaging an external assessor or preparing your annual SAMA self-assessment submission. Each row represents a readiness gate if you cannot answer "yes" to all questions in a row, the domain is not ready for assessment.

The most important pre-assessment step is not this checklist it is an independent gap assessment that scores your current maturity against the SAMA CSF using the same evidence standards that SAMA assessors apply. Self-assessment against your own understanding of what Level 3 requires frequently produces a higher maturity score than an independent assessment finds, because the gap between "we have this control" and "we can demonstrate this control to Level 3 standards" is consistently underestimated without external benchmarking.

SecurityWall conducts SAMA gap assessments that score every applicable sub-domain against the maturity model, produce a Board-ready gap register, and develop a prioritised remediation roadmap structured for SAMA submission. Every engagement is conducted by certified practitioners with direct SAMA regulatory experience.

Related reading:

• SAMA Cybersecurity Framework: Complete Guide for Saudi Financial Institutions (2026)
• SAMA Penetration Testing: Common Mistakes by Banks and Fintechs
• SAMA Red Teaming in Saudi Arabia
• SAMA vs ISO 27001: Do You Need Both?
• SAMA Compliance for Insurance and Fintech Companies