SAMA Cybersecurity Framework: Controls & Maturity

Important regulatory and source noteThis article is educational and is not legal, regulatory, or audit advice. Applicability and current expectations depend on the organization, regulated activity, current Saudi Central Bank Rulebook, circulars, supervisory directions, and other Saudi requirements. Penetration testing can support technical assurance, but it does not independently demonstrate SAMA compliance.

Executive Summary

The SAMA Cybersecurity Framework is a Saudi financial-sector cybersecurity framework built around governance, risk management, operations and technology, and third-party cybersecurity.
Its maturity model is designed to show how consistently controls are defined, implemented, measured, and improved - not merely whether a policy exists.
A defensible assessment combines documentation, ownership, technical implementation, operating records, exception handling, and evidence of remediation.
Penetration testing may help validate selected technical controls, but it does not prove governance, full asset coverage, continuous operation, or regulatory compliance.
Testing frequency should be derived from current official requirements, risk, asset criticality, material change, and contractual obligations; do not infer a universal schedule from maturity alone.
SAMA, NCA ECC, ISO/IEC 27001, NIST CSF, and PCI DSS can overlap, but they have different authorities, scopes, and assurance purposes.
Organizations should maintain a closed evidence loop: identify the requirement, implement the control, monitor it, validate it, remediate gaps, retest, and report residual risk.
The Saudi Central Bank Rulebook and official circulars are the authoritative sources; this guide provides practical interpretation for security, risk, compliance, and assurance teams.

Quick answer: What is the SAMA Cybersecurity Framework?

The SAMA Cybersecurity Framework is a cybersecurity governance and control framework for organizations within the relevant Saudi Central Bank supervisory scope. It organizes expectations across leadership and governance, risk management and compliance, operations and technology, and third-party cybersecurity. It also uses a maturity model to distinguish ad-hoc practices from structured, measurable, and adaptive control environments. Organizations should demonstrate more than written policies: they need assigned ownership, implemented controls, operating evidence, monitoring, exception handling, remediation, and improvement. Security testing can support this evidence by validating selected systems and controls, but a penetration test is only one point-in-time assurance activity. Confirm the current framework, applicability, maturity expectations, and any testing frequency directly from the Saudi Central Bank Rulebook and current supervisory communications.

What Is the SAMA Cybersecurity Framework?

The framework provides a structured way for regulated organizations to govern cybersecurity risk. It connects leadership decisions, policies, technical safeguards, monitoring, supplier oversight, and evidence of improvement. Its value is not in copying control language into a checklist. The value comes from showing how each applicable objective is owned, implemented, monitored, independently reviewed, and improved over time.

The term “SAMA” remains widely used in search and professional discussion, while the institution’s current English name is the Saudi Central Bank. This article uses “Saudi Central Bank” for the authority and “SAMA Cybersecurity Framework” for the commonly searched framework name. It avoids unverified authority labels.

For official wording, scope, and status, use the Saudi Central Bank Rulebook rather than third-party summaries. Official control text and circulars take precedence whenever this guide differs from the current regulatory source.

Who Does the Framework Apply To?

The framework is intended for member organizations and activities within the supervisory scope defined by the Saudi Central Bank and related official rules. It should not be presented as automatically applying to every company in Saudi Arabia, every fintech, every insurer, or every sandbox participant. Supervisory boundaries and sector responsibilities can change, and the framework’s original applicability list may not reflect every current institutional arrangement.

Context	Safe interpretation	Action before relying on the article
Organization directly supervised by the Saudi Central Bank	The framework may be relevant or mandatory, subject to the current Rulebook, license, circulars and supervisory directions.	Confirm the entity category, licensed activity, applicable controls and current maturity expectations.
Financial technology or payment activity	Applicability may depend on the licensed service, operating model and current Saudi Central Bank rules.	Review the current license conditions and relevant payment or data cybersecurity rules.
Supplier to a regulated institution	The supplier may face contractual and third-party security requirements without being directly regulated under the full framework.	Review contracts, data flows, access, outsourcing rules and customer assurance requirements.
Organization outside the Saudi Central Bank perimeter	The SAMA framework does not automatically apply; other Saudi national or sector requirements may be more relevant.	Confirm NCA and sector-specific applicability with qualified advisers.
Voluntary mapping	An organization may use SAMA controls as a benchmark, but voluntary alignment is not the same as regulatory compliance.	Label the mapping accurately and avoid claims of SAMA certification or approval.

Applicability noteApplicability should be confirmed against the organization’s current license, regulated activities, supervisory perimeter, and the latest Saudi Central Bank rules. Statements about insurance, reinsurance, payment services, financial market infrastructure, or sandbox activities require current regulatory confirmation.

SAMA Framework Structure: Domains, Subdomains and Controls

The published framework is organized around four major domains. Each domain contains more detailed objectives and control considerations. The summary below focuses on practical interpretation, evidence, and assurance rather than reproducing the framework text.

Domain	Purpose	Examples of evidence	Security-testing relevance
Cyber Security Leadership and Governance	Accountability, strategy, policy, roles, oversight and awareness.	Approved policies, committee records, role descriptions, management reporting.	Testing can inform governance, but cannot validate governance by itself.
Risk Management and Compliance	Risk identification, treatment, regulatory monitoring, assurance and exceptions.	Risk register, treatment plans, compliance mapping, audit records, approved exceptions.	Findings can feed risk decisions and treatment plans.
Cyber Security Operations and Technology	Asset, identity, system, network, application, data, monitoring, vulnerability and incident controls.	Inventories, configurations, access reviews, logs, scan results, test reports and incident records.	Many selected technical controls can be validated through appropriate testing.
Third Party Cyber Security	Supplier due diligence, contracting, access, outsourcing, cloud and ongoing assurance.	Supplier assessments, security clauses, assurance reports, access records and exit plans.	Testing may be relevant only where ownership and authorization permit it; governance evidence remains essential.

SAMA Cybersecurity Maturity Model

The framework uses six maturity levels, numbered 0 through 5. The levels are commonly summarized as progressing from non-existent and ad-hoc practices through repeatable and structured processes to measurable and adaptive control operation. Exact labels, criteria and target expectations must be checked against the current official framework and any later supervisory direction.

Level	Practical meaning	Typical evidence	Common mistake
0 - Non-existent	No consistent process or control is evident.	No approved process, ownership or reliable operating records.	Assuming low risk removes the need for a control decision.
1 - Ad-hoc	Activities depend on individuals and are inconsistent.	Informal actions, isolated documents, limited repeatability.	Treating one successful action as an established control.
2 - Repeatable	The activity occurs, but formalization and consistent evidence remain limited.	Recurring tasks, partial procedures, inconsistent records.	Confusing recurring effort with controlled operation.
3 - Structured and formalized	Processes, ownership and expected outputs are documented and implemented.	Approved standards, procedures, control owners and consistent execution records.	Believing a policy alone demonstrates maturity.
4 - Managed and measurable	Performance and effectiveness are measured, reviewed and used to drive improvement.	Metrics, trend analysis, exception monitoring, assurance results and improvement actions.	Reporting activity volume instead of control effectiveness.
5 - Adaptive	The control environment improves proactively as risk, technology and threats change.	Integrated threat and risk feedback, predictive indicators and evidence of sustained adaptation.	Claiming adaptation without measurable learning and change.

Figure 1. Maturity progression at a glance

0 Non-existent	1 Ad-hoc	2 Repeatable	3 Structured and formalized	4 Managed and measurable	5 Adaptive

Exact official labels and target expectations should be confirmed against the current Saudi Central Bank Rulebook and applicable supervisory directions.

Historical deadlines and target-maturity statements should be treated as historical unless a current official source confirms that they remain applicable to the specific entity.

How SAMA Cybersecurity Maturity Is Assessed

Maturity assessment is evidence-based. A defensible review should examine the design of the control, how it was implemented, whether it operated consistently, how exceptions were handled, and whether results drove remediation and improvement. The following workflow is a practical assessment model, not an official regulator procedure.

Confirm scope. Identify the regulated entity, business services, systems, data, suppliers and current official requirements.
Create the control inventory. Map applicable framework objectives to processes, systems, owners and evidence.
Assign ownership. Name accountable business and control owners rather than leaving the framework with the security team alone.
Gather design evidence. Collect policies, standards, procedures, architecture, risk decisions and committee approvals.
Sample operation. Review recent access decisions, alerts, incidents, vulnerability records, changes, exercises and supplier reviews.
Inspect technical implementation. Compare documented expectations with system configuration, logs and actual control behavior.
Use proportionate validation. Select configuration review, scanning, penetration testing, code review, tabletop exercise or other methods based on the control objective.
Record gaps and residual risk. Separate missing design, incomplete implementation and weak operating effectiveness.
Remediate and retest. Confirm that corrective action addresses the root cause and that closure evidence is reliable.
Report and maintain evidence. Provide management with risk, trend, exception and improvement information that can be revisited over time.

Policy, Implementation and Operating Effectiveness

Assurance layer	Question	Example evidence	Typical failure
Policy and design	Is the control objective defined, approved and assigned?	Policy, standard, risk decision, owner, architecture and approval.	The policy is missing, generic, outdated or disconnected from risk.
Implementation	Is the control deployed as designed across the intended scope?	Configuration, asset coverage, workflow, access model and implementation records.	The documented process exists but coverage is incomplete or inconsistent.
Operating effectiveness	Does the control work consistently and produce reliable evidence?	Logs, reviews, alerts, tickets, metrics, incidents and test results.	Evidence exists but no one reviews it, exceptions persist or failures recur.
Improvement	Do findings and measurements change decisions and control design?	Trend analysis, remediation, retesting, accepted residual risk and governance reporting.	Metrics are collected but do not drive action.

Figure 2. SAMA Control Assurance Chain

1 Requirement & owner	2 Documented design	3 Technical implementation	4 Operating evidence
5 Independent validation	6 Remediation	7 Retesting	8 Governance reporting

Use the chain to test whether a control exists, operates, is independently validated, and feeds measurable improvement. It is an editorial interpretation, not an official SAMA maturity model.

Evidence Organizations Should Preserve

Evidence should show what the organization intended, what it implemented, what actually happened, and how it responded when the control failed. Retention periods should come from current legal, regulatory, contractual and internal requirements; do not assume a universal one-year period.

Evidence category	Examples	What it supports	Limitation
Governance	Approved policies, committee minutes, role descriptions, strategy and risk acceptance.	Accountability, direction and oversight.	Does not prove technical operation.
Risk and assets	Risk register, service map, asset inventory, classification and data flows.	Scope, criticality and risk decisions.	Can become inaccurate without ownership and updates.
Identity and access	Joiner-mover-leaver records, privileged access reviews, authentication and exception records.	Access lifecycle and control operation.	A review can miss hidden or unmanaged identities.
Technical configuration	Secure baselines, configuration exports, architecture and change records.	Implementation and drift management.	Intended configuration may differ from production state.
Vulnerability management	Coverage records, scan results, triage, patching, exceptions and metrics.	Continuous identification and treatment.	Scanning does not establish exploitability or business logic risk.
Security testing	Scope, rules of engagement, report, validated evidence, limitations and retest results.	Point-in-time validation of selected controls and assets.	Does not prove continuous effectiveness or full asset coverage.
Monitoring and incidents	Log sources, alert reviews, incident records, exercises and lessons learned.	Detection and response operation.	Volume of logs does not equal effective monitoring.
Third-party assurance	Due diligence, contracts, assurance reports, access reviews and exit plans.	Supplier governance and oversight.	Provider evidence may be scoped or self-reported.
Continuity and recovery	Business impact analysis, backup evidence, restore tests and exercises.	Resilience and recovery capability.	A tabletop is not the same as a successful technical recovery.

Key SAMA Cybersecurity Control Areas

The control areas below focus on the objective, useful evidence, and proportionate validation methods without turning the framework into a generic cybersecurity checklist.

Control area	Practical focus	Useful evidence	Validation options
Governance and leadership	Accountability, strategy, policy, funding, risk acceptance and reporting.	Approvals, minutes, roles, dashboards and exception decisions.	Governance review, interviews, evidence sampling.
Risk and compliance	Risk identification, treatment, control mapping, assurance and regulatory change.	Risk register, mappings, audit results and treatment plans.	Gap assessment, control testing, internal audit.
Asset and data	Ownership, classification, dependencies, protection and disposal.	Inventories, data flows, encryption records and disposal evidence.	Inventory reconciliation, configuration review, data-flow validation.
Identity and access	Lifecycle, privilege, authentication, segregation, review and monitoring.	IAM records, access approvals, privileged reviews and logs.	Access review, configuration assessment, authorized identity-path testing.
Security operations and incidents	Logging, detection, triage, escalation, investigation and lessons learned.	Log coverage, alert records, incident reports and exercise outcomes.	Detection validation, tabletop or controlled red-team exercise.
Vulnerability and configuration	Coverage, prioritization, patching, hardening, exceptions and retesting.	Scan coverage, tickets, baselines, accepted risk and metrics.	Scanning, configuration review, penetration testing and retesting.
Application, API, mobile and cloud	Secure design, change, authentication, authorization, secrets, logging and provider responsibility.	Architecture, secure-development evidence, cloud configuration and test reports.	Code review, web/API/mobile testing, cloud security review.
Third parties	Due diligence, contracts, access, monitoring, incident duties and exit.	Assessments, contracts, assurance reports and access reviews.	Supplier review; testing only with explicit authorization.
Continuity and resilience	Critical services, recovery, backup, crisis management and exercises.	BIA, recovery plans, restore results and exercise records.	Restore test, failover test, tabletop and crisis exercise.

For technical context, DeepStrike’s penetration testing for compliance guide explains why testing evidence must remain subordinate to the actual control objective. The vulnerability assessment vs penetration testing comparison also helps teams select the appropriate assurance method instead of treating scanning and manual testing as interchangeable.

Does SAMA Require Penetration Testing?

Direct answerThe framework should not be interpreted as imposing a universal fixed annual penetration-testing schedule on every organization unless a current official source identifies the applicable entity, systems, scope, and frequency. Penetration testing may be one suitable validation method depending on current rules, risk, criticality, material change, and supervisory expectations.

Statement	Publish-safe interpretation	Evidence required before stronger wording
“SAMA requires annual penetration testing.”	Not safe as a universal statement. Frequency and scope may vary by entity, system, circular, license, risk and other obligations.	Current official provision naming the entity, assets, test type and frequency.
“Penetration testing supports SAMA readiness.”	Reasonable when testing is authorized, risk-based, appropriately scoped and mapped to relevant technical objectives.	Scope, authorization, methodology, report, limitations, remediation and retest evidence.
“A clean pentest proves compliance.”	Incorrect. A test covers selected assets at a point in time and cannot prove governance, continuous operation or full scope.	Broader control design, operating evidence, assurance and regulatory review.
“Scanning and penetration testing are interchangeable.”	Incorrect. Scanning provides broad detection of known issues; manual testing can validate exploitability, access paths and business logic within a defined scope.	A documented assurance plan explaining why each method was selected.
“Level 3 implies monthly scanning.”	Not supportable without a separate official or internal frequency requirement.	Current rule, circular, contract or approved risk-based standard.

How Penetration Testing Can Support SAMA Readiness

Penetration testing is most useful when the objective is explicit. It can show whether selected applications, APIs, cloud interfaces, networks or identity controls resist realistic misuse within an authorized scope. It should not be used as a substitute for control ownership, vulnerability management, configuration governance, monitoring, incident response, supplier oversight or business continuity.

Application and API validation. Assess authentication, authorization, session handling, data exposure, business logic and security boundaries within the agreed test scope.
Network and segmentation validation. Use internal, assumed-breach or explicitly scoped segmentation testing - not an external-only test - when the objective is to assess internal isolation or lateral movement risk.
Cloud security validation. Review identity, exposure, storage, network policy, logging and provider constraints using a scope permitted by the cloud provider and asset owner.
Identity risk validation. Assess selected authentication, privilege and access paths under strict rules of engagement without assuming that a technical test replaces formal access reviews.
Detection validation. Where authorized, a controlled exercise may help assess whether selected activities generate useful alerts and response actions.
Remediation validation. Retest confirmed findings after corrective action and preserve the result, remaining limitations and residual risk.
Evidence quality. Record affected assets, validated reproduction steps appropriate for the report audience, technical observations, business impact, remediation guidance and retest status. Avoid treating exploit scripts as a standard compliance deliverable.

Teams planning an engagement can use DeepStrike’s penetration testing methodology and penetration testing report guide to define scope, evidence, limitations and reporting before the test begins.

What Penetration Testing Does Not Prove

That the organization’s policies are complete, approved or consistently followed.
That all assets, suppliers, identities, data flows and environments were tested.
That the vulnerability-management or patch program is effective. The absence of high-severity findings does not independently prove this.
That controls will remain effective after code, infrastructure, identity or threat changes.
That incident response, business continuity or recovery objectives are effective unless those capabilities were separately exercised.
That the organization satisfies every SAMA control, current circular, legal obligation or supervisory expectation.
That the regulator has approved the organization, provider, report or maturity rating.

SAMA Security Testing and Evidence Matrix

Risk or control objective	Appropriate validation method	Evidence produced	Limitation
Known vulnerability coverage	Authenticated vulnerability scanning and asset reconciliation.	Coverage, findings, severity, age, exceptions and remediation status.	May miss business logic, chained weaknesses and unknown assets.
Application and API security	Manual web/API penetration testing, secure design review and code review where available.	Validated findings, affected functions, business impact, remediation and retest.	Point-in-time and limited to scope, roles and test constraints.
Internal segmentation	Internal or assumed-breach test, segmentation test, architecture and configuration review.	Observed reachability, control failures, permitted paths and limitations.	An external-only test usually cannot validate internal VLAN isolation.
Identity and privileged access	Access review, configuration review and authorized identity-path testing.	Excess access, control gaps, path evidence and remediation priorities.	Does not replace lifecycle and governance evidence.
Cloud posture	Cloud configuration review, architecture review and permitted testing of exposed services.	IAM, storage, network, logging and exposure findings.	Shared responsibility and provider rules limit scope.
Detection and incident readiness	Log-coverage review, tabletop exercise, controlled detection validation or red-team exercise.	Alert behavior, escalation, response timing and lessons learned.	A tabletop does not prove technical containment; a red team has safety constraints.
Business continuity	Backup restore, failover, disaster-recovery and crisis exercises.	Recovery outcome, timing, dependencies and gaps.	Separate from penetration testing.
Third-party security	Due diligence, contract review, assurance report review and authorized supplier testing.	Assurance scope, exceptions, access controls and obligations.	Evidence may be limited by supplier ownership and confidentiality.
Remediation effectiveness	Targeted retest, rescan, configuration validation and change review.	Closure evidence, remaining limitations and residual risk.	A passed retest covers the specific corrected issue, not the entire environment.

Scoping Security Testing for SAMA-Supportive Evidence

Define the assurance objective. Specify which business service, risk and control objective the engagement should evaluate.
Confirm ownership and authorization. Identify the asset owner, regulated entity, supplier permissions and production-safety constraints.
Build the asset and role scope. List applications, APIs, hosts, cloud accounts, mobile builds, identities, network zones and exclusions.
Select the validation method. Choose scanning, configuration review, code review, penetration testing, exercise or a combination based on the objective.
Agree rules of engagement. Document testing windows, prohibited actions, emergency contacts, critical finding escalation, data handling and evidence retention.
Plan evidence and mapping. State how findings will map to the relevant risk or control objective without implying that the report proves compliance.
Define remediation and retesting. Specify owners, severity handling, acceptance, target dates, retest conditions and closure evidence.
Document limitations. Record excluded systems, missing credentials, provider restrictions, time limits and assumptions so readers do not overinterpret the result.

For additional scope design, see DeepStrike’s internal vs external penetration testing guide and the Saudi market context in the penetration testing companies in Saudi Arabia guide. These pages serve different intents and should link back to this article with SAMA-specific anchors.

Remediation, Retesting and Closure Evidence

Stage	Required record	Primary owner	Common failure
Discovery	Finding, affected asset, evidence, risk context, scope and limitation.	Testing or assurance team.	Unclear ownership or incomplete affected-asset information.
Triage	Validated severity, business context, duplicate check and treatment decision.	Security and business risk owner.	Treating CVSS alone as the decision.
Remediation plan	Corrective action, root-cause response, owner, target date and dependencies.	System, application or process owner.	A workaround is recorded as a permanent fix.
Implementation	Change, code, configuration, architecture or compensating-control evidence.	Technology or process owner.	Change applied outside governance or only to one instance.
Retest	Targeted verification, scope, outcome and remaining limitations.	Independent testing or assurance function.	Closing on developer confirmation without independent validation.
Residual risk	Accepted remaining exposure, expiry, compensating controls and approval.	Accountable risk owner.	Open-ended acceptance without review.
Closure and reporting	Updated ticket, risk register, metrics and governance report.	Control owner and governance function.	Closure evidence never reaches management reporting.

Higher maturity is demonstrated through reliable feedback and improvement, not merely by producing more reports. The strongest evidence links the original weakness, corrective action, independent retest, remaining risk and governance decision.

SAMA vs NCA ECC

The Saudi Central Bank framework and the National Cybersecurity Authority controls are separate sources of requirements. They may overlap in governance, asset management, identity, vulnerability management, and incident response, but one should not be presented as automatically satisfying the other. Organizations should verify the current NCA publication, applicability, and sector-specific requirements before relying on a detailed control crosswalk.

Area	SAMA Cybersecurity Framework	NCA controls	Practical implication
Authority	Saudi Central Bank.	National Cybersecurity Authority.	Use the current official source from each authority.
Primary context	Cybersecurity expectations within the relevant Saudi Central Bank supervisory context.	National and sector cybersecurity requirements within the scope defined by the NCA and applicable Saudi arrangements.	Do not simplify NCA as applying identically to every organization or every licensed entity.
Structure	Domains, detailed control considerations and a maturity model.	Control requirements and related national or sector publications.	Build a crosswalk only after confirming current versions and applicability.
Assurance	Maturity, governance, implementation and operating evidence.	Evidence should match the applicable NCA control and implementation requirement.	A single evidence item may support both, but equivalence is not automatic.
Testing	Technical testing may support selected controls and risks.	Technical testing may also support selected NCA requirements where relevant.	Map the test to the objective; do not state that a pentest proves either framework.

Organizations should verify the current NCA publication and applicability through the National Cybersecurity Authority before relying on a version number or detailed mapping.

SAMA vs ISO 27001, NIST CSF and PCI DSS

Framework	Primary purpose	Relationship to SAMA	Important caveat
SAMA Cybersecurity Framework	Saudi financial-sector cybersecurity governance, controls and maturity within its applicable supervisory context.	The primary subject of this guide.	Use the current Saudi Central Bank Rulebook and circulars.
ISO/IEC 27001:2022	Requirements for an information security management system.	Can support governance, risk, control management and continuous improvement.	Certification scope and controls do not automatically satisfy SAMA-specific expectations.
NIST Cybersecurity Framework 2.0	A risk-management framework organized around Govern, Identify, Protect, Detect, Respond and Recover.	Can help organize cybersecurity outcomes and communicate risk.	It is not a substitute for Saudi regulatory requirements.
PCI DSS	Security requirements for account data environments within its applicability.	May create additional testing, segmentation and evidence obligations for relevant payment environments.	PCI DSS applies to its defined account-data scope, not the entire SAMA control environment.
NCA controls	Saudi national or sector cybersecurity requirements within their applicable scope.	Can overlap with SAMA in governance and technical control areas.	Current version and applicability require separate official verification.

Readers comparing assurance programs can review DeepStrike’s ISO 27001 penetration testing guide and PCI DSS penetration testing guide. Those articles should not be treated as authority for SAMA requirements; the links provide testing context only.

Practical SAMA Cybersecurity Framework Checklist and Roadmap

The roadmap below is a practical readiness checklist, not an official regulator checklist or a substitute for current Saudi Central Bank requirements.

Phase	Main activities	Output	Common risk
1. Confirm	Verify applicability, official sources, regulated activities, supervisory communications and stakeholders.	Approved scope and source register.	Starting with an outdated document or assumed entity list.
2. Baseline	Inventory services, systems, data, suppliers and current controls; assess evidence and maturity.	Gap and maturity baseline with evidence references.	Inflated scoring based on policy alone.
3. Prioritize	Rank gaps by business service, threat, exposure, regulatory importance and dependency.	Risk-based roadmap and owners.	Treating every control as equal or chasing a score without risk context.
4. Implement	Update governance, processes, architecture, access, monitoring, vulnerability, supplier and resilience controls.	Implemented controls and operating procedures.	Producing documents without changing system or process behavior.
5. Validate	Sample operating evidence and use proportionate technical or procedural assurance methods.	Assurance results, limitations and corrective actions.	Using one pentest as proof of the whole program.
6. Remediate	Address root causes, manage exceptions, implement changes and validate them.	Closed-loop remediation and retest evidence.	Closing findings without independent verification.
7. Govern	Report risk, maturity, exceptions, trends, overdue actions and residual exposure.	Management and board-level decision support.	Reporting activity counts without control-effectiveness insight.
8. Maintain	Refresh scope, evidence, mappings and assurance as services, technology, suppliers and threats change.	Current evidence repository and improvement cycle.	Treating compliance as a one-time project.

Common SAMA Implementation and Assessment Mistakes

Mistake	Why it creates risk	Better approach
Using an outdated framework or circular	Applicability, terminology and expectations may have changed.	Maintain an official source register and date every regulatory review.
Assuming the framework applies to every Saudi company	It creates inaccurate legal and commercial claims.	Confirm the current supervisory perimeter and licensed activity.
Confusing SAMA and NCA ECC	The authorities, scopes and control structures differ.	Create a verified crosswalk without assuming equivalence.
Treating maturity as a documentation score	Policies do not prove implementation or effectiveness.	Require ownership, operating evidence, testing and improvement.
Inventing a universal testing frequency	Maturity alone does not establish monthly scanning or annual pentesting.	Use current official requirements, risk, criticality, change and contracts.
Assuming zero high findings proves patch effectiveness	A test can be constrained by scope, access, time and technique.	Evaluate coverage, trends, remediation and continuous vulnerability evidence.
Testing only the external perimeter	Critical risk may sit in APIs, cloud IAM, mobile, internal identity or suppliers.	Scope by business service and attack path.
Using external testing to claim internal segmentation assurance	An external-only test usually lacks the internal foothold required.	Use internal, assumed-breach or explicit segmentation validation.
Closing issues without retesting	The organization cannot demonstrate that the corrective action worked.	Require targeted, independent closure evidence.
Publishing CMS notes or research tokens	It damages trust and reveals incomplete editorial work.	Keep source logs, QA and Windsor notes outside the article body.

Buyer Checklist for Security Testing and Assessment Support

Buyer question	Why it matters	Evidence to request
Does the provider distinguish compliance from technical testing?	Prevents regulator-approval and certification overclaims.	Proposal language, scope assumptions and sample reporting.
Can the provider scope critical business services and dependencies?	Testing should follow business risk, not a generic asset count.	Scope workshop output, asset assumptions and exclusions.
Are authorization and production safety documented?	Financial systems require careful coordination and escalation.	Rules of engagement, emergency contacts and prohibited actions.
Can the team assess web, API, mobile, cloud, network and identity risk where relevant?	Modern services cross multiple technology layers.	Verified service capability and named team qualifications.
Does the approach combine automation with manual validation?	Automated scanning alone can miss access, logic and chaining risk.	Methodology and sample finding detail.
Does the report state limitations and affected assets clearly?	Prevents overinterpretation of a clean result.	Sample scope, limitations, evidence and executive summary.
Are remediation and retesting defined?	A finding is not closed until corrective action is independently validated.	Retest terms, closure status and residual-risk treatment.
Can findings be mapped cautiously to control objectives?	Supports evidence management without turning the report into a compliance certificate.	Sample mapping with clear disclaimers.
Are data handling and confidentiality controlled?	Testing can expose sensitive financial or customer information.	NDA, retention, encryption, access and deletion terms.
Does the provider avoid SAMA approval or certification claims?	No testing vendor should imply regulator endorsement without official evidence.	Website and proposal review; explicit non-endorsement statement.

Frequently Asked Questions

What is the SAMA Cybersecurity Framework?

It is a cybersecurity governance, risk and control framework used within the relevant Saudi Central Bank supervisory context. It covers leadership, risk and compliance, operations and technology, third-party cybersecurity, and a maturity model. Organizations should rely on the current Saudi Central Bank Rulebook and circulars for authoritative wording and applicability.

Does it apply to every company in Saudi Arabia?

No. The framework should not be presented as universally applicable to every Saudi organization. Applicability depends on the entity, licensed activity, supervisory perimeter and current official rules. Organizations outside that scope may face NCA or other sector requirements instead.

What are the four main domains?

The published framework is commonly organized around Cyber Security Leadership and Governance, Risk Management and Compliance, Cyber Security Operations and Technology, and Third Party Cyber Security. The current official Rulebook should be checked before reproducing domain or control language.

What is the SAMA cybersecurity maturity model?

The framework uses levels 0 through 5 to distinguish absent or ad-hoc practices from repeatable, structured, measurable and adaptive operation. A mature control requires more than documentation; it needs consistent evidence, review, remediation and improvement. Exact official labels and targets require current-source verification.

How is maturity assessed?

A practical assessment reviews scope, ownership, policies, technical implementation, operating records, exceptions, monitoring, assurance results, remediation and governance reporting. It should distinguish control design from implementation and operating effectiveness.

Does SAMA require annual penetration testing?

This article does not make that universal claim. Any fixed frequency must be supported by a current official provision identifying the applicable entity, system, test type and schedule. Penetration testing may support selected control objectives, but frequency can also depend on risk, change and other obligations.

How can penetration testing support readiness?

An authorized test can validate selected applications, APIs, networks, cloud interfaces, identity paths or other technical controls. Its value depends on accurate scope, safe rules of engagement, evidence quality, remediation and retesting. It does not prove full compliance.

What is the difference between scanning and penetration testing?

Scanning provides broad, repeatable identification of known weaknesses and coverage gaps. Penetration testing uses manual analysis to validate exploitability, access paths and business logic within a defined scope. Mature assurance programs use each method for the right objective.

What is the difference between SAMA and NCA ECC?

They are separate sources of requirements issued by different Saudi authorities. They can overlap, but one does not automatically satisfy the other. The current NCA version and applicability must be verified before publishing detailed comparisons.

Is ISO 27001 certification enough?

No. ISO/IEC 27001 can provide a strong management-system foundation, but certification scope and controls do not automatically cover every SAMA-specific requirement, maturity expectation or supervisory direction.

What evidence supports an assessment?

Useful evidence includes approved governance records, risk and asset information, access reviews, technical configurations, monitoring and incident records, vulnerability and testing results, supplier assurance, remediation, retesting and management reporting.

How should findings be closed?

Assign an owner, document business risk and root cause, implement the corrective action, preserve change evidence, perform an appropriate retest, record remaining limitations, update residual risk and report closure through governance channels.

Conclusion

The SAMA Cybersecurity Framework should be approached as a control and evidence system, not a static checklist. Strong programs connect governance, risk, implementation, operating records, independent validation, remediation, retesting and management reporting. Penetration testing can provide valuable technical evidence for selected systems and risks, but it does not prove full compliance, continuous effectiveness or regulator approval.

DeepStrike can support authorized security validation across web applications, APIs, cloud environments, mobile applications, networks, and identity systems where those capabilities are confirmed and appropriately scoped. Testing results should be reviewed alongside governance, risk, compliance, internal audit, and current Saudi Central Bank requirements. For Saudi service context, see penetration testing in Riyadh and Saudi Arabia.

About the Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike specializing in advanced penetration testing and offensive security operations. He holds CISSP, OSCP, and OSWE certifications. His work focuses on application, API, cloud and identity security, remediation, and compliance-supportive security testing.

SAMA Cybersecurity Framework: Controls, Maturity & Testing